From owner-dnsop@lists.uoregon.edu Fri Apr 2 12:52:21 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20897 for ; Fri, 2 Apr 2004 12:52:20 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i32Fx6c7022488 for ; Fri, 2 Apr 2004 07:59:06 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i32Fx5Sg022479 for dnsop-outgoing; Fri, 2 Apr 2004 07:59:05 -0800 (PST) Message-ID: <406D6C9A.6070103@irisa.fr> Date: Fri, 02 Apr 2004 15:37:30 +0200 From: David Fort To: dnsop@lists.uoregon.edu Subject: [dnsop] KROd 1.0rc2 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: David Fort The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the second release candidate for KROd 1.0. KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be used to "DNSSECify" normal DNS zones. KROd is still an experimental product and as such shouldn't be used in production environment. More informations/downloads can be found here: http://idsa.irisa.fr/index.php?page=kro&lang=en -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 (0) 2 99 84 71 33 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 2 20:01:49 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16157 for ; Fri, 2 Apr 2004 20:01:48 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i32NLAg0017386 for ; Fri, 2 Apr 2004 15:21:10 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i32NLA5r017379 for dnsop-outgoing; Fri, 2 Apr 2004 15:21:10 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i32NL8Qu017028 for ; Fri, 2 Apr 2004 15:21:09 -0800 (PST) Received: from thangorodrim.hactrn.net (unknown [IPv6:2001:4f8:3:bb:2e0:98ff:fe89:f886]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id F2E8B233; Fri, 2 Apr 2004 18:20:59 -0500 (EST) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 6E85354; Fri, 2 Apr 2004 23:20:55 +0000 (GMT) Date: Fri, 02 Apr 2004 15:20:54 -0800 From: Rob Austein To: David.Kessens@nokia.com Cc: Bert Wijnen , dnsop@lists.uoregon.edu Subject: [dnsop] Please advance draft-ietf-dnsop-ipv6-transport-guidelines-02.txt User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 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: <20040402232055.6E85354@thangorodrim.hactrn.net> Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Rob Austein David, On behalf of the DNSOP WG, we'd like to request publication of draft-ietf-dnsop-ipv6-transport-guidelines-02.txt as a BCP. WG last call for this document completed in December with no expressed opposition to progressing this document, and a number of WG participants have expressed a belief that the subject discussed in this document is fairly important to operational stability of the DNS on a dual-protocol (IPv4 and IPv6) Internet. --Rob and Dave . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 5 14:14:41 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20851 for ; Mon, 5 Apr 2004 14:14:41 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i35GNqjb024088 for ; Mon, 5 Apr 2004 09:23:52 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i35GNq8T024087 for dnsop-outgoing; Mon, 5 Apr 2004 09:23:52 -0700 (PDT) Received: from smtp.irisa.fr (smtp.irisa.fr [131.254.130.26]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i35GNoGS024003 for ; Mon, 5 Apr 2004 09:23:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 96FFAFCD4; Mon, 5 Apr 2004 18:23:49 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.130.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15822-02; Mon, 5 Apr 2004 18:23:49 +0200 (CEST) Received: from irisa.fr (moulis.irisa.fr [131.254.70.6]) by smtp.irisa.fr (Postfix) with ESMTP id 1806DFCAD; Mon, 5 Apr 2004 18:23:49 +0200 (CEST) Message-ID: <40718814.8080204@irisa.fr> Date: Mon, 05 Apr 2004 18:23:48 +0200 From: David Fort User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040216 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: [dnsop] Re: KROd 1.0rc2 References: <406D6C9A.6070103@irisa.fr> <20040402221132.GF13109@vacation.karoshi.com.> In-Reply-To: <20040402221132.GF13109@vacation.karoshi.com.> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at irisa.fr Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: David Fort Content-Transfer-Encoding: 8bit bmanning@vacation.karoshi.com wrote: >On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote: > > >>KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be >> >> > > [...] >-rw-r--r-- 1 4779 29016 176701 Feb 16 12:49 KROd-1.0rc1.tar.gz >-rw-r----- 1 4779 29016 129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2 >226 Transfer complete. >ftp> get KROd-1.0rc2.tar.bz2 >local: KROd-1.0rc2.tar.bz2 remote: KROd-1.0rc2.tar.bz2 >227 Entering Passive Mode (131,254,254,10,112,150) >550 KROd-1.0rc2.tar.bz2: Permission denied. > > Corrected -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 (0) 2 99 84 71 33 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 6 12:50:49 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05329 for ; Tue, 6 Apr 2004 12:50:48 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i36EnW4N023463 for ; Tue, 6 Apr 2004 07:49:32 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i36EnW3C023460 for dnsop-outgoing; Tue, 6 Apr 2004 07:49:32 -0700 (PDT) Received: from tachyon.jinmei.org (kame207.kame.net [203.178.141.207]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i36EnU1S023435 for ; Tue, 6 Apr 2004 07:49:31 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:4819:64a9:7819:e195:d1b1]) by tachyon.jinmei.org (Postfix) with ESMTP id 4C3AB361E5; Tue, 6 Apr 2004 23:49:05 +0900 (JST) Date: Tue, 06 Apr 2004 23:49:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: <4.3.2.7.2.20040324164609.02981118@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Tue, 06 Apr 2004 23:05:31 +0900, >>>>> JINMEI Tatuya said: > Editorial comments: (Sorry, I missed one more comment in Appendix) 4. Appendix A. (Site-local Addressing Considerations for DNS) (last paragraph) ... Note that the experience private addresses in IPv4 has shown that the root servers get loaded for requests for private address lookups in any. s/experience private addresses/experience of private addresses/ ? (if "experience private addresses" was really the phrase intended, then "has shown" should be "have shown") JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 6 15:58:11 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21305 for ; Tue, 6 Apr 2004 15:58:10 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i36E5S5n006720 for ; Tue, 6 Apr 2004 07:05:28 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i36E5Sj4006711 for dnsop-outgoing; Tue, 6 Apr 2004 07:05:28 -0700 (PDT) Received: from tachyon.jinmei.org (kame207.kame.net [203.178.141.207]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i36E5RDj006513 for ; Tue, 6 Apr 2004 07:05:27 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:4819:64a9:7819:e195:d1b1]) by tachyon.jinmei.org (Postfix) with ESMTP id 4F6B0361E5; Tue, 6 Apr 2004 23:05:00 +0900 (JST) Date: Tue, 06 Apr 2004 23:05:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: <4.3.2.7.2.20040324164609.02981118@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Thu, 25 Mar 2004 17:18:33 +0200 (EET), >>>>> Pekka Savola said: > For up-to-date copies, see: > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html I'm going to make comments on the 05pre revision to avoid making duplicate comments. (I still must admit I may not have been careful about the last call thread and can make duplicates. Please just ignore duplicate ones if any). Overall, I think this documetn is accurate and very useful. Some relatively minor comments below: Substantial (or not-so-editorial) comments: 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records) In particular one should note that the use of A6 records, DNAME records in the reverse tree, or Bitlabels in the reverse tree is not recommended [2]. I think this is an overstatement about DNAME. The text looks meaning DNAME is not recommended *in any way* in the IPv6 reverse tree. For example, people would read this to mean it is discouraged to use DNAME to manage both ip6.arpa and ip6.int zones as described in http://www.isc.org/pubs/tn/isc-tn-2002-1.html But, in my understanding, the sense of the discussion in RFC3363 ([2]) is that DNAME in the reverse tree is deprecated for the reverse side of the A6 usage. That is, the usage for constructing multi-level, hierarchal reverse trees, particularly with bitstring labels. Perhaps I misunderstood the sense, in which case I hope someone will correct me. Even if I'm correct, this is probably a result of the ambiguous wording in RFC3363. But I believe this document could still be a bit clearer on the meaning of "not recommended". 2. Section 2.2 (Privacy (RFC3041) Address) Privacy addresses (RFC3041 [9]) use a random number as the interface ... "Privacy address" is not really correct as a technical term. RFC3041 calls this "temporary address". I guess the dns-issues draft wanted to make the intention of the address (i.e. privacy purposes), but I still think it should use the correct term with additional explanation. For example, how about saying "Temporary addresses (for privacy purposes defined in RFC3041 [9])"? 3. Section 4.4 (The Use of TTL for IPv4 and IPv6 RRs) example.com. 300 IN MX foo.example.com. foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 100 IN AAAA 2001:db8::1 ... ... So, in this particular case, there is a window of 200 seconds when incomplete information is returned from the cache. I don't see what's wrong with this. In this case, the lost information would be "additional" one (returned in the additional section) after all. If the client (probably an SMTP server in this case) needs the missing AAAA, it can ask for the missing RR(s) separately (otherwise, I'd call this a bug in the client). So, Therefore, when the same name refers to both A and AAAA records, these records should have the same TTL. I don't see a valid reason for this either. Moreover, I can even think of a case we want to use different TTLs for A and AAAA RRsets. For example, if I'm going to renumber an IPv6 address of a host while keeping IPv4 addresses on that host, I might want to use a shorter TTL for the AAAA RRset but a longer, stable TTL for the A RRset. 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments) (second paragraph) Consider the case where the query is so long or the number of the additional ("glue") records is so high that the response must either be truncated (leading to a retry with TCP) or some of the additional data removed from the reply. The "the query is so long" part is not really clear. I guess the authors tried to talk about the case where the query *name* is so long, which should be copied to the response and may make the response long too. However, the original text could also read to mean "the query *packet* is so long", and, in this case, the intention is unclear (since there are other possibilities that may make the query packet long, e.g., EDNS0 pseudo RR(s) and are not necessarily related to the length of the response). 5. Section 6 (Considerations about Forward DNS Updating) (second paragraph) Typically forward DNS updates are more manageable than doing them in the reverse DNS, because the updater can, typically, be assumed to "own" a certain DNS name -- and we can create a form of security association with the DNS name and the node allowed to update it to point to a new address. (this is a mostly editorial comment) I think "security association" is a misleading term here because it sounds like something related to IPsec (but it seems to me that the original intention was more generic). I guess the authors perhaps tried to express the intention by adding "a form of" before "security association", but the text could explicitly be clearer. 6. Section 7.5 (DDNS with Dynamic Prefix Delegation) (first paragraph) That is, whether the DNS server is managed by the same entity as the prefix delegator, at the site where the prefixes are delegated, or elsewhere (which is typically equivalent to the latter). (again, mostly editorial) the parenthesized part is not really clear. First, what's the antecedent of this part? I guess it is "the point where the DNS server is managed", but it could also read to specify "elsewhere". Secondly, what does "the latter" at the end of the sentence specify? I guess it's "the site where the prefixes are delegated", but again, it could also specify "elsewhere". ===================== Editorial comments: 1. Section 1.1 (Representing IPv6 Addresses in DNS Records) (first paragraph) PTR records in the nibble format under the ip6.arpa. -tree. Is the "dash" (-) character before "tree" intentional? Probably so, but I was not sure whether this is a typo or an intentional notation. In any case, I think we can even remove the dash (not a strong opinion, though). 2. Section 6.2 (Dynamic DNS) (third paragraph) for the hostname; the second must be configured explicitly unless one chooses to trust the IP address -based authentication (not a good idea); s/address -based/address-based/ ? (fourth paragraph) address; that way, the node can start lowering the DNS TTL if it seems like the address has not be renewed/refreshed in a while. Some discussion on how an administrator could manage the DNS TTL is included in [33]; s/has not be/has not been/ ? 3. Section 7.3 (DDNS with Stateless Address Autoconfiguration) (last paragraph) One way to automate this is looking up the DNS server authoritative (e.g., through SOA record) for the IP address being updated, but the security material (unless the IP address -based authorization is trusted) must also be established by some other means. s/address -based/address-based/ ? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 03:44:28 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21663 for ; Wed, 7 Apr 2004 03:44:27 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i376TCSQ022898 for ; Tue, 6 Apr 2004 23:29:12 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i376TCd0022894 for dnsop-outgoing; Tue, 6 Apr 2004 23:29:12 -0700 (PDT) Received: from smtp.irisa.fr (smtp.irisa.fr [131.254.130.26]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i376TBRR022805 for ; Tue, 6 Apr 2004 23:29:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 3E98BFA9D; Wed, 7 Apr 2004 08:29:10 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.130.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27387-07; Wed, 7 Apr 2004 08:29:09 +0200 (CEST) Received: from irisa.fr (medoc.irisa.fr [131.254.70.2]) by smtp.irisa.fr (Postfix) with ESMTP id B7D89FB70; Wed, 7 Apr 2004 08:29:09 +0200 (CEST) Message-ID: <40739FB5.2030106@irisa.fr> Date: Wed, 07 Apr 2004 08:29:09 +0200 From: Gilles Guette Organization: Irisa/Inria - Rennes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr, en MIME-Version: 1.0 To: dnsop@lists.uoregon.edu Subject: [dnsop] draft-ietf-dnsop-key-rollover-requirements-00 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.fr Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Gilles Guette Content-Transfer-Encoding: 7bit Hello, We have published work about the requirements for automated key rollover in DNSSEC in the draft draft-guette-dnsop-key-rollover-requirements-00 during the 58th IETF meeting (november 2003, Minneapolis). This draft has been adopted by the working group and has turned into draft-ietf-dnsop-key-rollover-requirements-00. It seems that this change hadn't been taken into account by the wg and Mohsen Souissi (AFNIC) pointed out this change at IETF Seoul dnsop session. This draft presents the communication between parent and child zones during an automated key rollover, the data exchanged and the security services needed. We (co-authors) would much appreciate your feedback and comments on this draft. Regards -- Gilles Guette Ph.D. Student IRISA/INRIA France Olivier Courtay Research Engineer IRISA France . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 04:36:26 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25409 for ; Wed, 7 Apr 2004 04:36:26 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3771qKI007483 for ; Wed, 7 Apr 2004 00:01:52 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3771q5g007477 for dnsop-outgoing; Wed, 7 Apr 2004 00:01:52 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3771oAu006689 for ; Wed, 7 Apr 2004 00:01:51 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3771Wi02230; Wed, 7 Apr 2004 10:01:34 +0300 Date: Wed, 7 Apr 2004 10:01:32 +0300 (EEST) From: Pekka Savola To: Peter Koch cc: dnsop@lists.uoregon.edu Subject: additional data [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <200403291551.i2TFpxT05197@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Note: I did not see a clear resolution to this thread, so I did not reflect it in the document. However, I'd be glad to make some changes if there was agreement on the wording. Please continue.. :) However, I made a few more editorial fixups from you Peter to the section: - clarified the difference of glue/additional data - added clarification on TC use The revised paragraph is below. 4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments In the previous section, we discussed the effect of impartial data returned from the caches when the TTLs are not kept the same. Now, we present another problem highlighted in the mixed IPv4/IPv6 environments. Consider the case where the query is so long or the number of the additional records (originated from "glue") is so high that the response must either be truncated (leading to a retry with TCP) or some of the additional data removed from the reply. However, note that if too much additional information that is not strictly necessary would be added, one should remove unnecessary information instead of setting TC bit for this "courtesy" information [17]. Further, resource record sets are never "broken up", so if a name has 4 A records and 5 AAAA records, you can either return all 9, all 4 A records, all 5 AAAA records or nothing. In the case of too much additional data, it might be tempting to not return the AAAA records if the transport for DNS query was IPv4, or not return the A records, if the transport was IPv6. However, this breaks the model of independence of DNS transport and resource records, as noted in Section 1.2. This temptation would have significant problems in multiple areas. Remember that often the end-node, which will be using the records, is not the same one as the node requesting them from the authorative DNS server (or even a caching resolver). So, whichever version the requestor ("the middleman") uses makes no difference to the ultimate user of the records. This might result in e.g., inappropriately returning A records to an IPv6-only node, going through a translation, or opening up another IP-level session (e.g., a PDP context [37]). The problem of too much additional data seems to be an operational one: the zone administrator entering too many records which will be returned either truncated or impartial to the users. A protocol fix for this is using EDNS0 [38] to signal the capacity for larger UDP packet sizes, pushing up the relevant threshold. The operational fix for this is having the DNS server implementations return a warning when the administrators create the zones which would result in too much additional data being returned. On Mon, 29 Mar 2004, Peter Koch wrote: > Eric A. Hall wrote: > > > Omitting all additional-data is not helpful. > > could you elaborate, please? My intent was to shift the choice from the > server, who can guess at best, to the client or the resolver acting on > behalf of it, respectively. > > Even the draft you cite > > > http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-01.txt says: > > suggests this: > > > | record sets are to be provided. Both resource record sets MAY be > > | omitted from the additional-data section if necessary or desired. > > > > In the case of other-application pointers (like MX addresses), it is far > > better to omit the additional-data than it is to provide and cache > > incomplete RRsets. > > Incomplete RRSets are no option anyway. > > -Peter > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 05:48:00 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02427 for ; Wed, 7 Apr 2004 05:48:00 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i378cku9015706 for ; Wed, 7 Apr 2004 01:38:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i378ckQe015697 for dnsop-outgoing; Wed, 7 Apr 2004 01:38:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i378cibW015292 for ; Wed, 7 Apr 2004 01:38:44 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i378cY903991; Wed, 7 Apr 2004 11:38:34 +0300 Date: Wed, 7 Apr 2004 11:38:34 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Thanks a lot for good comments. (I also took your additional message into account.) I think this causes us to re-think the TTL/impartial additional-data parts and how it's supposed to operate a bit -- so I'd welcome the others to look at this as well.. I've also updated the temporary copies at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html (There is no diff between these two pre-versions though.) Inline.. On Tue, 6 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records) > > In particular one should note that the use of A6 records, DNAME > records in the reverse tree, or Bitlabels in the reverse tree is not > recommended [2]. > > I think this is an overstatement about DNAME. The text looks meaning > DNAME is not recommended *in any way* in the IPv6 reverse tree. For > example, people would read this to mean it is discouraged to use DNAME > to manage both ip6.arpa and ip6.int zones as described in > http://www.isc.org/pubs/tn/isc-tn-2002-1.html [...] I'll take this discussion to a separate thread, as this may add some debate. > 2. Section 2.2 (Privacy (RFC3041) Address) > > Privacy addresses (RFC3041 [9]) use a random number as the interface > ... > > "Privacy address" is not really correct as a technical term. RFC3041 > calls this "temporary address". I guess the dns-issues draft wanted > to make the intention of the address (i.e. privacy purposes), but I > still think it should use the correct term with additional > explanation. For example, how about saying "Temporary addresses (for > privacy purposes defined in RFC3041 [9])"? Good point. Revised as follows: Temporary addresses defined in RFC3041 (sometimes called "privacy addresses") use a random number as the interface identifier. Publishing DNS records relating to such addresses would defeat the purpose of the mechanism and is not recommended. If absolutely necessary, a mapping could be made to some non-identifiable name, as described in . > 3. Section 4.4 (The Use of TTL for IPv4 and IPv6 RRs) > > example.com. 300 IN MX foo.example.com. > foo.example.com. 300 IN A 192.0.2.1 > foo.example.com. 100 IN AAAA 2001:db8::1 > ... > ... So, > in this particular case, there is a window of 200 seconds when > incomplete information is returned from the cache. > > I don't see what's wrong with this. In this case, the lost > information would be "additional" one (returned in the additional > section) after all. If the client (probably an SMTP server in this > case) needs the missing AAAA, it can ask for the missing RR(s) > separately (otherwise, I'd call this a bug in the client). You raise a good point. I seem to have been slightly confused here, thinking that the clients would do somekind of "ANY" or "give me everything you have about 'name'" queries. You can do "ANY" query, but that does not give you the right answer unless the caching resolvers on the path have also queried for both v4 and v6 records. So, practically, you have to perform explicit queries for both A and AAAA records. However, there is a case where you do not need explicit queries but where you could be led astray: querying for MX record, as the caches may give you nothing (this leads you to query both records explicitly), full results, or impartial results. Here I'm worried of impartial results. Or am I missing something and is there some kind of real application of "ANY" queries? Does anyone use them e.g. on DNS server or stub resolver implementations? Let me try to understand your bug example. Would you consider it a bug that a DNS cache would have cached both A and AAAA records with different TTLs, and when the first-to-expire expires, the DNS cache does not re-query the one that expired? Should it re-query that? I mean, if the cache would return records in an additional section (e.g., when queried for MX record), but would not return all of them (because some of them had expired), would you consider this a bug? (See below for text update.) > So, > > Therefore, when the same name refers to both A and AAAA records, > these records should have the same TTL. > > I don't see a valid reason for this either. Moreover, I can even > think of a case we want to use different TTLs for A and AAAA RRsets. > For example, if I'm going to renumber an IPv6 address of a host while > keeping IPv4 addresses on that host, I might want to use a shorter TTL > for the AAAA RRset but a longer, stable TTL for the A RRset. I think it should be reasonable to suggest that the TTL should be the same (because that simplifies the operations for those servers which have to handle the both) unless there are valid reasons (like the ones you cite) for handling them differently. As for the current wording I've adopted (this probably requires more tuning still): 4.4 The Use of TTL for IPv4 and IPv6 RRs The behaviour of DNS caching when different TTL values are used for different records of the same name requires explicit discussion. For example, let's consider a part of a zone: example.com. 300 IN MX foo.example.com. foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 100 IN AAAA 2001:db8::1 When a caching resolver asks for the MX record of example.com, it gets back "foo.example.com". It may also get back either one or both of the A and AAAA records in the additional section. So, there are three cases about returning records for the MX in the additional section: 1. We get back no A or AAAA records: this is the simplest case, because the we have to query which information is required explicitly, guaranteeing that we get all the information we're interested in. 2. We get back all the records: this is an optimization as there is no need to perform more queries, causing lower latency. However, it is impossible to guarantee that in fact we would always get back all the records; however, one could try to work in the direction to try to ensure it as far as possible. 3. We get impartial results: this is indistinguishable from the previous case, and problematic as described in the next section. So, we assume we get back both A and AAAA records of foo.example.com, or the resolver explicitly asks, in two separate queries, both A and AAAA records. After 100 seconds, the AAAA record is removed from the cache because its TTL expired. The cache must re-query the AAAA record when its TTL expires to avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. XXX: if this is not done, is it a bug? To simplify the situation, it is recommended to use the same TTL for all the records referring to the same name. However, there are some scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where a different strategy is preferable. More issues with caching and A/AAAA records is presented in the next section. > 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments) > > (second paragraph) > Consider the case where the query is so long or the number of the > additional ("glue") records is so high that the response must either > be truncated (leading to a retry with TCP) or some of the additional > data removed from the reply. > > The "the query is so long" part is not really clear. I guess the > authors tried to talk about the case where the query *name* is so > long, which should be copied to the response and may make the response > long too. However, the original text could also read to mean "the > query *packet* is so long", and, in this case, the intention is > unclear (since there are other possibilities that may make the query > packet long, e.g., EDNS0 pseudo RR(s) and are not necessarily related > to the length of the response). Yes, the intent was "query name", as the additional length of the packet for other reasons was also discussed a bit. Possibly this would call for more text? Consider the cases where the query name is so long, the number of he additional records (originated from "glue") is so high, or for other easons that the response must either be runcated (leading to a retry with TCP) or some of the additional data emoved from the reply. [...] I added "query name" there and "or for other reasons" -catchall, but if you have better ideas what to add here, I'm all ears :) > 5. Section 6 (Considerations about Forward DNS Updating) > > (second paragraph) > Typically forward DNS updates are more manageable than doing them in > the reverse DNS, because the updater can, typically, be assumed to > "own" a certain DNS name -- and we can create a form of security > association with the DNS name and the node allowed to update it to > point to a new address. > > (this is a mostly editorial comment) I think "security association" is > a misleading term here because it sounds like something related to > IPsec (but it seems to me that the original intention was more > generic). I guess the authors perhaps tried to express the intention > by adding "a form of" before "security association", but the text > could explicitly be clearer. Yes, this is the intent. I've changed "security association" to "security relationship" to make it clearer that the terms don't overlap :) > 6. Section 7.5 (DDNS with Dynamic Prefix Delegation) > > (first paragraph) > > That is, whether the DNS server is managed by > the same entity as the prefix delegator, at the site where the > prefixes are delegated, or elsewhere (which is typically equivalent > to the latter). > > (again, mostly editorial) the parenthesized part is not really clear. > First, what's the antecedent of this part? I guess it is "the point > where the DNS server is managed", but it could also read to specify > "elsewhere". > > Secondly, what does "the latter" at the end of the sentence specify? > I guess it's "the site where the prefixes are delegated", but again, > it could also specify "elsewhere". The wording "at the site where the prefixes are delegated" seems to be unclear. I've reworded it to "at the site where the prefixes are delegated to" to make it clearer. I've also tried to clarify the parentheses by spelling it out: 7.5 DDNS with Dynamic Prefix Delegation In cases where a prefix, instead of an address, is being used and updated, one should consider what is the location of the server where DDNS updates are made. That is, where the DNS server is located: 1. At the same organization as the prefix delegator. 2. At the site where the prefixes are delegated to. 3. Elsewhere, as specified by the delegated site; this is security-wise typically equivalent to the previous case. On one hand, securing the DDNS relationship for prefix delegation is simpler if DNS server and the prefix delegator are in the same administrative domain, and may be more difficult otherwise. On the other hand, if the DNS server resides where the prefixes are delegated to, it is easier to manage reverse DNS updates as they can be done within a single administrative entity. Similarly, then configuring the reverse DNS is typically simpler as well (e.g., if one wanted to insert a wildcard record). > ===================== > > Editorial comments: > > 1. Section 1.1 (Representing IPv6 Addresses in DNS Records) > > (first paragraph) > PTR records in the nibble format under the ip6.arpa. -tree. > > Is the "dash" (-) character before "tree" intentional? Probably so, > but I was not sure whether this is a typo or an intentional notation. > In any case, I think we can even remove the dash (not a strong > opinion, though). It was intentional notation, but removed as it doesn't seem necessary. > 2. Section 6.2 (Dynamic DNS) > > (third paragraph) > for the hostname; the second must be configured explicitly unless one > chooses to trust the IP address -based authentication (not a good > idea); > > s/address -based/address-based/ ? I like how it is at the moment because it's 'IP address'-based rather than just address-based. But I've changed this as you say (two places) as I think this is rather equivalent in any case. (Same for section 7.3.) > (fourth paragraph) > address; that way, the node can start lowering the DNS TTL if it > seems like the address has not be renewed/refreshed in a while. Some > discussion on how an administrator could manage the DNS TTL is > included in [33]; > > s/has not be/has not been/ ? Yep. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 07:24:12 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10407 for ; Wed, 7 Apr 2004 07:24:12 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i379ndiK024914 for ; Wed, 7 Apr 2004 02:49:39 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i379ndl5024909 for dnsop-outgoing; Wed, 7 Apr 2004 02:49:39 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i379nbWM024509 for ; Wed, 7 Apr 2004 02:49:38 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i379nIN05030; Wed, 7 Apr 2004 12:49:23 +0300 Date: Wed, 7 Apr 2004 12:49:18 +0300 (EEST) From: Pekka Savola To: Mark Andrews cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , , , , , , Subject: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <200404070050.i370o6qW042917@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola I'm particularly interested in hearing what kind of opinions the WG has on this particular problem.. On Wed, 7 Apr 2004, Mark Andrews wrote: > > Substantial (or not-so-editorial) comments: > > > > 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records) > > > > In particular one should note that the use of A6 records, DNAME > > records in the reverse tree, or Bitlabels in the reverse tree is not > > recommended [2]. > > > > I think this is an overstatement about DNAME. The text looks meaning > > DNAME is not recommended *in any way* in the IPv6 reverse tree. For > > example, people would read this to mean it is discouraged to use DNAME > > to manage both ip6.arpa and ip6.int zones as described in > > http://www.isc.org/pubs/tn/isc-tn-2002-1.html Yes. > > But, in my understanding, the sense of the discussion in RFC3363 ([2]) > > is that DNAME in the reverse tree is deprecated for the reverse side > > of the A6 usage. That is, the usage for constructing multi-level, > > hierarchal reverse trees, particularly with bitstring labels. Chaining was indeed one important argument in the discussions. I do not remember them in detail to be able to comment whether it was intentional to deprecate DNAME for all reverse usage or just with A6. IMHO, the document language: 4. DNAME in IPv6 Reverse Tree The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. [split by me] Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. The first part *seems* indicate that at least when writing the document, there was no justified use for DNAME in the reverse tree. However, this still does leave it open what's the case about non-fragmented, non-A6 reverses (the scenario which Jinmei said). And to that my feeling was that the implementation expense etc. of DNAME is not really worth it in the non-fragmented scenario, and that it might re-open problems we saw in A6 wrt. chaining. > We should just reissue RFC3363 with *all* references to DNAME > removed. It continually causes problems. [...] First, I think there should be consensus that DNAME is a good thing, and it's OK to use it everywhere. :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 08:36:03 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16997 for ; Wed, 7 Apr 2004 08:36:02 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37B5NOC009706 for ; Wed, 7 Apr 2004 04:05:23 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i37B5Na8009702 for dnsop-outgoing; Wed, 7 Apr 2004 04:05:23 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37B5LOP009281 for ; Wed, 7 Apr 2004 04:05:22 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i37B4srd024055; Wed, 7 Apr 2004 12:04:55 +0100 (BST) To: Masataka Ohta cc: Pekka Savola , Mark Andrews , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5?= =?ISO-2022-JP?B?YSAvIBskQj9ATEBDIzpIGyhC?= , dnsop@lists.uoregon.edu, randy@psg.com, alain.durand@Sun.COM, fink@es.net, ogud@ogud.com, hain@tndh.net Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: Message from Masataka Ohta of "Wed, 07 Apr 2004 19:38:15 +0900." <4073DA17.10701@necom830.hpcl.titech.ac.jp> Date: Wed, 07 Apr 2004 12:04:54 +0100 Message-ID: <24054.1081335894@gromit.rfc1035.com> From: Jim Reid Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Jim Reid >>>>> "Masataka" == Masataka Ohta writes: Masataka> I think DNAME and bit labels MUST be obsoleted for Masataka> obvious reasons that they are useless and harmful. I strongly disgaree with both your statement and the justification for it. Please demonstrate how DNAME and bit labels are "useless and harmful". DNAME has applications outside the reverse resolution of IPv6 addresses: for instance in migrating old-domain-name to new-domain-name. Bit labels are awful and very hard to use or understand, but that's not an excuse to kill them. [DNSSEC is also awful and hard to use or understand but nobody seems to want to kill that.] IMO the status quo for DNAME and bit labels is just fine. IIRC bit labels are now considered EXPERIMENTAL and so far a compelling case hasn't been made to change that status. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 08:44:01 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17121 for ; Wed, 7 Apr 2004 08:44:01 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37BKBpF028796 for ; Wed, 7 Apr 2004 04:20:11 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i37BKB97028791 for dnsop-outgoing; Wed, 7 Apr 2004 04:20:11 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by darkwing.uoregon.edu (8.12.11/8.12.11) with SMTP id i37BK99M028665 for ; Wed, 7 Apr 2004 04:20:09 -0700 (PDT) Received: (qmail 33322 invoked from network); 7 Apr 2004 11:30:32 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 Apr 2004 11:30:32 -0000 Message-ID: <4073E4A7.1010608@necom830.hpcl.titech.ac.jp> Date: Wed, 07 Apr 2004 20:23:19 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Jim Reid CC: Pekka Savola , Mark Andrews , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , dnsop@lists.uoregon.edu, randy@psg.com, alain.durand@Sun.COM, fink@es.net, ogud@ogud.com, hain@tndh.net Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] References: <24054.1081335894@gromit.rfc1035.com> In-Reply-To: <24054.1081335894@gromit.rfc1035.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Masataka Ohta Content-Transfer-Encoding: 7bit Jim Reid wrote: > [DNSSEC is also > awful and hard to use or understand but nobody seems to want to kill > that.] Huh? It is also obviously useless and obviously harmful. Masataka Ohta . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 08:49:16 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17424 for ; Wed, 7 Apr 2004 08:49:15 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37AZ7vU025733 for ; Wed, 7 Apr 2004 03:35:07 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i37AZ7oJ025721 for dnsop-outgoing; Wed, 7 Apr 2004 03:35:07 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by darkwing.uoregon.edu (8.12.11/8.12.11) with SMTP id i37AZ5xk025636 for ; Wed, 7 Apr 2004 03:35:06 -0700 (PDT) Received: (qmail 33140 invoked from network); 7 Apr 2004 10:45:27 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 Apr 2004 10:45:27 -0000 Message-ID: <4073DA17.10701@necom830.hpcl.titech.ac.jp> Date: Wed, 07 Apr 2004 19:38:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Mark Andrews , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5?= =?ISO-2022-JP?B?YSAvIBskQj9ATEBDIzpIGyhC?= , dnsop@lists.uoregon.edu, randy@psg.com, alain.durand@sun.com, fink@es.net, ogud@ogud.com, hain@tndh.net Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Masataka Ohta Content-Transfer-Encoding: 7bit Pekka Savola wrote: > I'm particularly interested in hearing what kind of opinions the WG > has on this particular problem.. I think DNAME and bit labels MUST be obsoleted for obvious reasons that they are useless and harmful. Masataka Ohta . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 09:04:23 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18284 for ; Wed, 7 Apr 2004 09:04:22 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37BZp19022488 for ; Wed, 7 Apr 2004 04:35:51 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i37BZpFK022482 for dnsop-outgoing; Wed, 7 Apr 2004 04:35:51 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by darkwing.uoregon.edu (8.12.11/8.12.11) with SMTP id i37BZovw022384 for ; Wed, 7 Apr 2004 04:35:50 -0700 (PDT) Received: (qmail 33400 invoked from network); 7 Apr 2004 11:46:13 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 Apr 2004 11:46:13 -0000 Message-ID: <4073E853.5070104@necom830.hpcl.titech.ac.jp> Date: Wed, 07 Apr 2004 20:38:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark Andrews CC: Pekka Savola , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAv?= =?ISO-2022-JP?B?IBskQj9ATEBDIzpIGyhC?= , dnsop@lists.uoregon.edu, randy@psg.com, alain.durand@sun.com, fink@es.net, ogud@ogud.com, hain@tndh.net Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] References: <200404071124.i37BO8qW049094@drugs.dv.isc.org> In-Reply-To: <200404071124.i37BO8qW049094@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Masataka Ohta Content-Transfer-Encoding: 7bit Mark Andrews wrote: > DNAME does NOTHING more that allow the server to synthesis > CNAMEs. Mass CNAME synthesis can, and thus MUST, be performed purely locally within a server as a minor zone file syntax change without any protocol changes. > When you also call for CNAMEs to be removed I will > believe you are being honest in wanting DNAMEs to be removed. See above. Masataka Ohta . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 09:14:20 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18453 for ; Wed, 7 Apr 2004 09:14:20 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37C9soC014874 for ; Wed, 7 Apr 2004 05:09:54 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i37C9sv5014869 for dnsop-outgoing; Wed, 7 Apr 2004 05:09:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37C9r97014521 for ; Wed, 7 Apr 2004 05:09:53 -0700 (PDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2004 05:10:29 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i37C9jGF014179 for ; Wed, 7 Apr 2004 05:09:46 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-8.cisco.com [10.86.242.8]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK56551; Wed, 7 Apr 2004 08:09:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20040407070511.01f4c810@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Apr 2004 08:09:41 -0400 To: dnsop@lists.uoregon.edu From: Ralph Droms Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Ralph Droms (Following up on http://darkwing.uoregon.edu/~llynch/dnsop/msg02710.html: Pekka, thanks for your response. I agree with your responses to any issues from the previous message that I haven't mentioned here.) Comments on draft-ietf-dnsop-ipv6-dns-issues-05pre.txt: I'm still having trouble understanding: 2.3 6to4 Addresses 6to4 [10] specifies an automatic tunneling mechanism which maps a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. Providing reverse DNS delegation path for such addresses is a challenge. Note that similar difficulties don't surface with the other automatic tunneling mechanisms. In particular, providing reverse DNS information for Teredo [11] hosts does not seem feasible; the IPv6 address is based on the IPv4 address and UDP port of the current NAT mapping which is likely to be relatively short-lived. The last sentence seems to contradict the preceding sentence. I don't think section 5.2 accurately reflects the current state of specifications and discussion about recursive DNS resolver configuration: 5.2 Recursive DNS Resolver Discovery Recursive IPv6 DNS resolver discovery is a subject of active debate as of this writing (March 2003): the main proposed mechanisms include the use of well-known addresses [24], the use of Router Advertisements to convey the information [25], and using DHCPv6 (or the stateless subset of it [26]) for DNS resolver configuration [27]. No consensus has been reached yet. Note that IPv6 DNS resolver discovery is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as IPv6. I think the current situation regarding recursive DNS resolver configuration would be more accurately reflected by the following paragraph: 5.2 Obtaining a list of DNS Recursive Resolvers A host can be configured with a list of DNS recursive resolvers through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. This option can be passed to a host through a subset of DHCPv6 [RFC3736]. Two alternative mechanisms are under consideration: the use of well-known addresses [21] and the use of Router Advertisements to convey the information [22]. I know this paragraph has been discussed before. It would be good to get other WG input to make sure the text reflects WG consensus on the subject. In section 6, would it be possible to add a reference to work on the problem of adding a name into a DNS zone for readers (such as myself!) who are unfamiliar with the problem area? Is there any guidance that this document can give regarding adding a new name to a zone? Comments on section 7.4: 7.4 DDNS with DHCP With DHCP, the reverse DNS name is typically already inserted to the DNS that reflects to the name (e.g., "dhcp-67.example.com"). All of these mappings are pre-configured, and require no updating. Are you referring to DHCPv4 or DHCPv6 here? It would be good to get input based on deployment experience to confirm that this strategy is "typically" used for DHCPv4. Of course, we have little deployment experience with DHCPv6 to know whether pre-configuration will be used for IPv6 PTR records. If a more explicit control is required, similar considerations as with SLAAC apply, except for the fact that typically one must update a reverse DNS record instead of inserting one (if a denser address assignment policy than with SLAAC is adopted) and updating a record seems like a slightly more difficult thing to secure. However, it is yet uncertain how DHCPv6 is going to be used for address assignment. Would the parenthetical phrase be more clearly stated as "(if an address assignment policy that reassigns disused addresses is adopted)" Note that when using DHCP, either the host or the DHCP server could perform the DNS updates; see the implications in Section 6.2. Is there a parallel between host updates of DHCPv6-assigned addresses and the discussion in section 7.3, as well? It might be worth mentioning that the DHCPv6 server can perform the PTR record cleanup if the DHCPv6 address assignment is used. Finally, in response to your comments on section 7.4: > > Section 7.4, second paragraph: What is a "denser address assignment > > policy"? As we have little or no experience with address assignment > > through DHCPv6, I think it is premature to anticipate how DHCPv6 will > > be used. I can imagine, for example, that DHCPv6 might be used to > > assign addresses that look just like SLAAC addresses - the advantage > > to the use of DHCPv6 being centralized registration and accounting for > > addresses and devices. > >Well -- looking at those that seem to want to use DHCPv6, their main >point appears to continue doing what they're doing with v4. The >logical conclusion of that is that using relatively dense allocations >(though not necessarily every address sequentially, until running out, >as with v4) is something they're familiar with and want to go on >doing. My experience has been that network admins that want to use DHCPv6 for address assignment are primarily interested in registering addresses and accounting for devices on the network, rather than wanting to do sequential address assignment from a pool of available addresses. Those admins would be happy with a DHCPv6 server that hands out an address constructed in the same way as a SLAAC address. - Ralph . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 09:48:36 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22320 for ; Wed, 7 Apr 2004 09:48:35 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37CKBnE021110 for ; Wed, 7 Apr 2004 05:20:11 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i37CKBRQ021108 for dnsop-outgoing; Wed, 7 Apr 2004 05:20:11 -0700 (PDT) Received: from tachyon.jinmei.org (kame207.kame.net [203.178.141.207]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37CK9MR021020 for ; Wed, 7 Apr 2004 05:20:10 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:edf9:7e7b:fdb7:f1f7]) by tachyon.jinmei.org (Postfix) with ESMTP id C935D351B0; Wed, 7 Apr 2004 21:19:41 +0900 (JST) Date: Wed, 07 Apr 2004 21:20:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In this response, I'm also referring to the latest version of http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt (the one whose MD5 hash value is 0f0dcc920186d1a01f923dd60aac168d). Easy ones first: >>>>> On Wed, 7 Apr 2004 11:38:34 +0300 (EEST), >>>>> Pekka Savola said: >> 2. Section 2.2 (Privacy (RFC3041) Address) (snip) > Good point. Revised as follows: > Temporary addresses defined in target="RFC3041">RFC3041 (sometimes called "privacy addresses") > use a random number as the interface identifier. Publishing DNS > records relating to such addresses would defeat the purpose of the > mechanism and is not recommended. If absolutely necessary, a mapping > could be made to some non-identifiable name, as described in target="RFC3041"/>. Forks for me. I'd also remove "RFC3041" from the section title: 2.2 Temporary Addresses but this is not a strong opinion. >> 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments) >> >> (second paragraph) (snip) > Yes, the intent was "query name", as the additional length of the > packet for other reasons was also discussed a bit. Possibly this > would call for more text? > Consider the cases where the query name is so long, the > number of he additional records (originated from "glue") is so high, > or for other easons that the response must either be runcated (leading > to a retry with TCP) or some of the additional data emoved from the > reply. [...] > I added "query name" there and "or for other reasons" -catchall, but > if you have better ideas what to add here, I'm all ears :) For me, adding "name" to "the query" is enough (in fact, I'm not sure what "other reasons" are referring to). But again, it's not a strong opinion and is up to you. >> 5. Section 6 (Considerations about Forward DNS Updating) >> >> (second paragraph) >> Typically forward DNS updates are more manageable than doing them in >> the reverse DNS, because the updater can, typically, be assumed to >> "own" a certain DNS name -- and we can create a form of security >> association with the DNS name and the node allowed to update it to >> point to a new address. >> >> (this is a mostly editorial comment) I think "security association" is >> a misleading term here because it sounds like something related to >> IPsec (but it seems to me that the original intention was more >> generic). I guess the authors perhaps tried to express the intention >> by adding "a form of" before "security association", but the text >> could explicitly be clearer. > Yes, this is the intent. I've changed "security association" to > "security relationship" to make it clearer that the terms don't > overlap :) Okay. >> 6. Section 7.5 (DDNS with Dynamic Prefix Delegation) (snip) > The wording "at the site where the prefixes are delegated" seems to be > unclear. I've reworded it to "at the site where the prefixes are > delegated to" to make it clearer. I've also tried to clarify the > parentheses by spelling it out: > 7.5 DDNS with Dynamic Prefix Delegation > In cases where a prefix, instead of an address, is being used and > updated, one should consider what is the location of the server where > DDNS updates are made. That is, where the DNS server is located: > 1. At the same organization as the prefix delegator. > 2. At the site where the prefixes are delegated to. > 3. Elsewhere, as specified by the delegated site; this is > security-wise typically equivalent to the previous case. > On one hand, securing the DDNS relationship for prefix delegation is > simpler if DNS server and the prefix delegator are in the same > administrative domain, and may be more difficult otherwise. > On the other hand, if the DNS server resides where the prefixes are > delegated to, it is easier to manage reverse DNS updates as they can > be done within a single administrative entity. Similarly, then > configuring the reverse DNS is typically simpler as well (e.g., if > one wanted to insert a wildcard record). The revised text basically looks okay except for one point: I'm not sure about the rationale of the latter part of case 3: "this is security-wise typically equivalent to the previous case." >> 2. Section 6.2 (Dynamic DNS) >> >> (third paragraph) >> for the hostname; the second must be configured explicitly unless one >> chooses to trust the IP address -based authentication (not a good >> idea); >> >> s/address -based/address-based/ ? > I like how it is at the moment because it's 'IP address'-based rather > than just address-based. But I've changed this as you say (two > places) as I think this is rather equivalent in any case. > (Same for section 7.3.) Ah, I see. My comment actually came from consistency with other parts ("address-based" without "IP"), which I thought was natural notation. If "address -based" was intentional, then I'm fine, though I personally prefer "address-based". And, since the latest text matches my preference, I'm just happy with it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 7 09:51:39 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22940 for ; Wed, 7 Apr 2004 09:51:39 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i37CTcnE023981 for ; Wed, 7 Apr 2004 05:29:38 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i37CTc3T023970 for dnsop-outgoing; Wed, 7 Apr 2004 05:29:38 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by darkwing.uoregon.edu (8.12.11/8.12.11) with SMTP id i37CTat7023881 for ; Wed, 7 Apr 2004 05:29:36 -0700 (PDT) Received: (qmail 33660 invoked from network); 7 Apr 2004 12:40:00 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 Apr 2004 12:40:00 -0000 Message-ID: <4073F4EE.4090204@necom830.hpcl.titech.ac.jp> Date: Wed, 07 Apr 2004 21:32:46 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark Andrews CC: Pekka Savola , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAv?= =?ISO-2022-JP?B?IBskQj9ATEBDIzpIGyhC?= , dnsop@lists.uoregon.edu, randy@psg.com, alain.durand@sun.com, fink@es.net, ogud@ogud.com, hain@tndh.net Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] References: <200404071207.i37C7gqW049251@drugs.dv.isc.org> In-Reply-To: <200404071207.i37C7gqW049251@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Masataka Ohta Content-Transfer-Encoding: 7bit Mark Andrews wrote: >>Mass CNAME synthesis can, and thus MUST, be performed purely >>locally within a server as a minor zone file syntax change >>without any protocol changes. > Well when you have a server that can load 18446744073709551616 > CNAME records require to replace 1 DNAME record at the /64 > level please let me know. A sane implementers simply load 1 instance of specific syntax as a directive to synthesis 18446744073709551616 or more possible CNAME records. During the transition period to obsolete DNAME, implementers are encouraged let DNS servers interprete "DNAME" as such a directive. Masataka Ohta . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 03:32:28 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16212 for ; Fri, 9 Apr 2004 03:32:25 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i395WUu6026116 for ; Thu, 8 Apr 2004 22:32:30 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i395WU1q026115 for dnsop-outgoing; Thu, 8 Apr 2004 22:32:30 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i395WOSJ025910 for ; Thu, 8 Apr 2004 22:32:28 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i395WC013287; Fri, 9 Apr 2004 08:32:12 +0300 Date: Fri, 9 Apr 2004 08:32:12 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Wed, 7 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Wed, 7 Apr 2004 11:38:34 +0300 (EEST), > >>>>> Pekka Savola said: > > >> 2. Section 2.2 (Privacy (RFC3041) Address) > > (snip) > > > Good point. Revised as follows: > > > Temporary addresses defined in > target="RFC3041">RFC3041 (sometimes called "privacy addresses") > > use a random number as the interface identifier. Publishing DNS > > records relating to such addresses would defeat the purpose of the > > mechanism and is not recommended. If absolutely necessary, a mapping > > could be made to some non-identifiable name, as described in > target="RFC3041"/>. > > Forks for me. I'd also remove "RFC3041" from the section title: > > 2.2 Temporary Addresses > > but this is not a strong opinion. I'd rather keep it in, to make it clearer to not confuse them with non-RFC3041 addresses which just happen to be temporary, but as RFC3041 is to be revised in any case, I think this may be better off from the title, so I've removed it. > >> 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments) > >> > >> (second paragraph) > > (snip) > > > Yes, the intent was "query name", as the additional length of the > > packet for other reasons was also discussed a bit. Possibly this > > would call for more text? > > > Consider the cases where the query name is so long, the > > number of he additional records (originated from "glue") is so high, > > or for other easons that the response must either be runcated (leading > > to a retry with TCP) or some of the additional data emoved from the > > reply. [...] > > > I added "query name" there and "or for other reasons" -catchall, but > > if you have better ideas what to add here, I'm all ears :) > > For me, adding "name" to "the query" is enough (in fact, I'm not sure > what "other reasons" are referring to). But again, it's not a strong > opinion and is up to you. Kept as is; "other reasons" may be due to e.g., the number of DNS record for the name that would have to be returned (in the *authorative* section) to be too large or inclusion of DNSSEC records for which either query name or additional records may not be appropriate. (However, as I don't know the details, I'm just being vague ;-). > >> 6. Section 7.5 (DDNS with Dynamic Prefix Delegation) > > (snip) > > > The wording "at the site where the prefixes are delegated" seems to be > > unclear. I've reworded it to "at the site where the prefixes are > > delegated to" to make it clearer. I've also tried to clarify the > > parentheses by spelling it out: > > > 7.5 DDNS with Dynamic Prefix Delegation > > > In cases where a prefix, instead of an address, is being used and > > updated, one should consider what is the location of the server where > > DDNS updates are made. That is, where the DNS server is located: > > > 1. At the same organization as the prefix delegator. > > > 2. At the site where the prefixes are delegated to. > > > 3. Elsewhere, as specified by the delegated site; this is > > security-wise typically equivalent to the previous case. > > > On one hand, securing the DDNS relationship for prefix delegation is > > simpler if DNS server and the prefix delegator are in the same > > administrative domain, and may be more difficult otherwise. > > > On the other hand, if the DNS server resides where the prefixes are > > delegated to, it is easier to manage reverse DNS updates as they can > > be done within a single administrative entity. Similarly, then > > configuring the reverse DNS is typically simpler as well (e.g., if > > one wanted to insert a wildcard record). > > The revised text basically looks okay except for one point: I'm not > sure about the rationale of the latter part of case 3: "this is > security-wise typically equivalent to the previous case." OK, let me try to clarify. If you delegate the DNS delegation for a prefix to someone else, that someone else must configure the DNS server to accept such a delegation. Because they don't just take delegations from strangers, we must assume that there is some form of relationship between the two. Such relationship should be easily extendable to be a security relationship as well. However, the difference which is not explicit is that as the DDNS packets cross the public Internet, there is probably higher need to secure the DDNS updates coming to the server (as rather, when the server is at the same site, you could just use IP address-based "authentication" if you call it that). I changed this to: Elsewhere; this implies a relationship betwen the site and where DNS server is located, and such a relationship should be rather straightforward to secure as well. How does this sound? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 04:30:18 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17888 for ; Fri, 9 Apr 2004 04:30:18 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i396QA5a011749 for ; Thu, 8 Apr 2004 23:26:10 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i396QATH011740 for dnsop-outgoing; Thu, 8 Apr 2004 23:26:10 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i396Q87M011383 for ; Thu, 8 Apr 2004 23:26:09 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i396Q3g13919 for ; Fri, 9 Apr 2004 09:26:03 +0300 Date: Fri, 9 Apr 2004 09:26:03 +0300 (EEST) From: Pekka Savola To: dnsop@lists.uoregon.edu Subject: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <4.3.2.7.2.20040407070511.01f4c810@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Hi, Ralph suggested changing section 5.2 on DNS resolver discovery to better reflect to what's out there (but not reflect that there is no consensus on the approach). I think the proposed wording is a bit biased toward using DHCP but not much. I'd slightly modify his proposal to: A host can be configured with a list of DNS recursive resolvers through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. This option can be passed to a host through a subset of DHCPv6 [RFC3736]. Two alternative mechanisms are under consideration: the use of well-known addresses [21] and the use of Router Advertisements to convey the information [22]. No consensus has been reached as of this writing (April 2004). What does the WG think about this -- That is, Do you have a problem with the above wording? If yes, I won't adopt it, but use the original unless there are other suggestions. If not, I'll use the rewording above, or something close to that. On Wed, 7 Apr 2004, Ralph Droms wrote: > I don't think section 5.2 accurately reflects the current state of > specifications and discussion about recursive DNS resolver configuration: > > 5.2 Recursive DNS Resolver Discovery > > Recursive IPv6 DNS resolver discovery is a subject of active > debate as of this writing (March 2003): the main proposed > mechanisms include the use of well-known addresses [24], the use > of Router Advertisements to convey the information [25], and > using DHCPv6 (or the stateless subset of it [26]) for DNS > resolver configuration [27]. No consensus has been reached yet. > > Note that IPv6 DNS resolver discovery is not required for > dual-stack nodes in dual-stack networks as IPv6 DNS records can > be queried over IPv4 as well as IPv6. > > I think the current situation regarding recursive DNS resolver configuration > would be more accurately reflected by the following paragraph: > > 5.2 Obtaining a list of DNS Recursive Resolvers > > A host can be configured with a list of DNS recursive resolvers > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > This option can be passed to a host through a subset of DHCPv6 > [RFC3736]. Two alternative mechanisms are under consideration: > the use of well-known addresses [21] and the use of Router > Advertisements to convey the information [22]. > > > I know this paragraph has been discussed before. It would be good to get > other WG input to make sure the text reflects WG consensus on the subject. > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 04:46:45 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18355 for ; Fri, 9 Apr 2004 04:46:44 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i396Xk4K003185 for ; Thu, 8 Apr 2004 23:33:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i396Xk6h003176 for dnsop-outgoing; Thu, 8 Apr 2004 23:33:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i396Xi6e002840 for ; Thu, 8 Apr 2004 23:33:45 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i396XR614004; Fri, 9 Apr 2004 09:33:27 +0300 Date: Fri, 9 Apr 2004 09:33:27 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: dnsop@lists.uoregon.edu, "Michael A. Patton" Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: <4.3.2.7.2.20040407070511.01f4c810@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Thanks for responding. Trying to clarify further... (Michael -- we discussed this last December: do you have pointers to the work on adding entirely new records (rather than updating) to the zones, as noted in section 6? Maybe some others know more of this than me...) I've updated the working copies in the same URL: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html Note to DNSOP WG: there has been some discussion on IPv6 WG what to say about DNS (forward/reverse) of the new "site-local replacement" described in draft-ietf-ipv6-unique-local-addr-03.txt. I've avoided adding text on this as it's a bit of moving target (in AD evaluation:WG followup at the moment), but if people have opinions about that, feel free to shoot them. (Note that Appendix A already lists considerations with site-local addresses, but the situation is slightly different with unique local addresses.) On Wed, 7 Apr 2004, Ralph Droms wrote: > Comments on draft-ietf-dnsop-ipv6-dns-issues-05pre.txt: > > I'm still having trouble understanding: > > 2.3 6to4 Addresses > > 6to4 [10] specifies an automatic tunneling mechanism which maps > a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. > Providing reverse DNS delegation path for such addresses is a > challenge. Note that similar difficulties don't surface with > the other automatic tunneling mechanisms. In particular, > providing reverse DNS information for Teredo [11] hosts does not > seem feasible; the IPv6 address is based on the IPv4 address and > UDP port of the current NAT mapping which is likely to be > relatively short-lived. > > The last sentence seems to contradict the preceding sentence. OK, let me try to reword this to: 6to4 specifies an automatic tunneling mechanism which maps a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. Providing reverse DNS delegation path for such addresses is a challenge. Note that it does not seem feasible to provide reverse DNS with the other automatic tunneling mechanism, Teredo; this is because the IPv6 address is based on the IPv4 address and UDP port of the current NAT mapping which is likely to be relatively short-lived. (note that I'm intentionally not mentioning iSATAP here as it derives the address from an advertised v6 prefix, so there is nothing new there.) Better? [[ note to those who may be watching: I also added a paragraph of discussion on draft-huston-6to4-reverse-dns-00.txt here ]] > I don't think section 5.2 accurately reflects the current state of > specifications and discussion about recursive DNS resolver configuration: > > 5.2 Recursive DNS Resolver Discovery > > Recursive IPv6 DNS resolver discovery is a subject of active > debate as of this writing (March 2003): the main proposed > mechanisms include the use of well-known addresses [24], the use > of Router Advertisements to convey the information [25], and > using DHCPv6 (or the stateless subset of it [26]) for DNS > resolver configuration [27]. No consensus has been reached yet. > > Note that IPv6 DNS resolver discovery is not required for > dual-stack nodes in dual-stack networks as IPv6 DNS records can > be queried over IPv4 as well as IPv6. > > I think the current situation regarding recursive DNS resolver configuration > would be more accurately reflected by the following paragraph: > > 5.2 Obtaining a list of DNS Recursive Resolvers > > A host can be configured with a list of DNS recursive resolvers > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > This option can be passed to a host through a subset of DHCPv6 > [RFC3736]. Two alternative mechanisms are under consideration: > the use of well-known addresses [21] and the use of Router > Advertisements to convey the information [22]. > > I know this paragraph has been discussed before. It would be good to get > other WG input to make sure the text reflects WG consensus on the subject. Yes, and to little resolution. I'll raise this separately to see what people think. > In section 6, would it be possible to add a reference to work on the > problem of adding a name into a DNS zone for readers (such as myself!) > who are unfamiliar with the problem area? Is there any guidance that > this document can give regarding adding a new name to a zone? Good question. I'm actually unfamiliar with this. I received similar input from Michael Patton, which I've Cc:'ed. Maybe he could provide some pointers. > Comments on section 7.4: > > 7.4 DDNS with DHCP > > With DHCP, the reverse DNS name is typically already inserted to > the DNS that reflects to the name (e.g., "dhcp-67.example.com"). > All of these mappings are pre-configured, and require no > updating. > > Are you referring to DHCPv4 or DHCPv6 here? It would be good to get > input based on deployment experience to confirm that this > strategy is "typically" used for DHCPv4. Of course, we have little > deployment experience with DHCPv6 to know whether pre-configuration > will be used for IPv6 PTR records. I'm familiar with some deployments of DHCPv4, and in almost all of them, you use pre-defined names. I assume it will likely be similar with DHCPv6. Clarified: With DHCPv4, the reverse DNS name is typically already inserted to the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One can assume similar practice may become commonplace with DHCPv6 as well; all such mappings would be pre-configured, and would require no updating. Or other suggestions? > If a more explicit control is required, similar considerations as > with SLAAC apply, except for the fact that typically one must > update a reverse DNS record instead of inserting one (if a denser > address assignment policy than with SLAAC is adopted) and > updating a record seems like a slightly more difficult thing to > secure. However, it is yet uncertain how DHCPv6 is going to be > used for address assignment. > > Would the parenthetical phrase be more clearly stated as "(if an > address assignment policy that reassigns disused addresses is > adopted)" Yes, changed to that. > Note that when using DHCP, either the host or the DHCP server > could perform the DNS updates; see the implications in Section > 6.2. > > Is there a parallel between host updates of DHCPv6-assigned > addresses and the discussion in section 7.3, as well? It might be > worth mentioning that the DHCPv6 server can perform the PTR record > cleanup if the DHCPv6 address assignment is used. Yes, but there is difference if the disused addresses are being reused. That is, with SLAAC you can pretty much be sure that nobody will be reusing your EUI64. I've added a note as the last paragraph: If disused addresses were to be reassigned, host-based DDNS reverse updates would need policy considerations for DNS record modification, as noted above. On the other hand, if disused address were not to be assigned, host-based DNS reverse updates would have similar considerations as SLAAC in . Server-based updates have similar properties except that the janitorial process could be integrated with DHCP address assignment. > Finally, in response to your comments on section 7.4: > > > > Section 7.4, second paragraph: What is a "denser address assignment > > > policy"? As we have little or no experience with address assignment > > > through DHCPv6, I think it is premature to anticipate how DHCPv6 will > > > be used. I can imagine, for example, that DHCPv6 might be used to > > > assign addresses that look just like SLAAC addresses - the advantage > > > to the use of DHCPv6 being centralized registration and accounting for > > > addresses and devices. > > > >Well -- looking at those that seem to want to use DHCPv6, their main > >point appears to continue doing what they're doing with v4. The > >logical conclusion of that is that using relatively dense allocations > >(though not necessarily every address sequentially, until running out, > >as with v4) is something they're familiar with and want to go on > >doing. > > My experience has been that network admins that want to use DHCPv6 > for address assignment are primarily interested in registering > addresses and accounting for devices on the network, rather than > wanting to do sequential address assignment from a pool of available > addresses. Those admins would be happy with a DHCPv6 server that > hands out an address constructed in the same way as a SLAAC address. Handing out such addresses, IMHO, makes no sense, as you would have to renumber the host if its MAC address changes, even though you wouldn't need to introduce this dependency. Of course, one could just assign addresses using some other policy so that the addresses would not need to be reassigned. I took this as generic discussion and did not make changes. The text has been reworded in any case to deal with more than just a simple "dense" assignment policy. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 08:26:00 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24823 for ; Fri, 9 Apr 2004 08:25:58 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39B0fWO029204 for ; Fri, 9 Apr 2004 04:00:41 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i39B0fSU029191 for dnsop-outgoing; Fri, 9 Apr 2004 04:00:41 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39B0d7R029089 for ; Fri, 9 Apr 2004 04:00:40 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5251E15214; Fri, 9 Apr 2004 20:00:38 +0900 (JST) Date: Fri, 09 Apr 2004 20:00:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Fri, 9 Apr 2004 08:32:12 +0300 (EEST), >>>>> Pekka Savola said: >> 2.2 Temporary Addresses >> >> but this is not a strong opinion. > I'd rather keep it in, to make it clearer to not confuse them with > non-RFC3041 addresses which just happen to be temporary, but as > RFC3041 is to be revised in any case, I think this may be better off > from the title, so I've removed it. Okay. >> >> 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments) >> >> For me, adding "name" to "the query" is enough (in fact, I'm not sure >> what "other reasons" are referring to). But again, it's not a strong >> opinion and is up to you. > Kept as is; "other reasons" may be due to e.g., the number of DNS > record for the name that would have to be returned (in the > *authorative* section) to be too large or inclusion of DNSSEC records > for which either query name or additional records may not be > appropriate. (However, as I don't know the details, I'm just being > vague ;-). Okay. >> >> 6. Section 7.5 (DDNS with Dynamic Prefix Delegation) >> >> (snip) >> >> > The wording "at the site where the prefixes are delegated" seems to be >> > unclear. I've reworded it to "at the site where the prefixes are >> > delegated to" to make it clearer. I've also tried to clarify the >> > parentheses by spelling it out: >> >> > 7.5 DDNS with Dynamic Prefix Delegation >> >> > In cases where a prefix, instead of an address, is being used and >> > updated, one should consider what is the location of the server where >> > DDNS updates are made. That is, where the DNS server is located: >> >> > 1. At the same organization as the prefix delegator. >> >> > 2. At the site where the prefixes are delegated to. >> >> > 3. Elsewhere, as specified by the delegated site; this is >> > security-wise typically equivalent to the previous case. >> >> > On one hand, securing the DDNS relationship for prefix delegation is >> > simpler if DNS server and the prefix delegator are in the same >> > administrative domain, and may be more difficult otherwise. >> >> > On the other hand, if the DNS server resides where the prefixes are >> > delegated to, it is easier to manage reverse DNS updates as they can >> > be done within a single administrative entity. Similarly, then >> > configuring the reverse DNS is typically simpler as well (e.g., if >> > one wanted to insert a wildcard record). >> >> The revised text basically looks okay except for one point: I'm not >> sure about the rationale of the latter part of case 3: "this is >> security-wise typically equivalent to the previous case." > OK, let me try to clarify. If you delegate the DNS delegation for a > prefix to someone else, that someone else must configure the DNS > server to accept such a delegation. Because they don't just take > delegations from strangers, we must assume that there is some form of > relationship between the two. Such relationship should be easily > extendable to be a security relationship as well. Hmm...I'm now feeling that I've been confused from the beginning. So before going further, please let me make the scenario. Let's assume a site is delegated an IPv6 prefix P:x::/48. Also assume the prefix delegator has the authority of the DNS reverse tree for P::/32. Then, In the above case 1, the prefix delegator does not delegate P:x::/48 in terms of DNS reverse tree. Someone in the delegated site might want to update RRs in the P:x::/48 part of the P::/32 zone at the delegator. In the above case 2, the prefix delegator does delegate P:x::/48 to the (prefix) delegated site in terms of DNS reverse tree, too. Someone in the delegated site might want to update RRs in the P:x::/48 zone managed in the same site. In the above case 3, the prefix delegator does delegate P:x::/48 in terms of DNS revers tree to some different organization which is not the delegator or the delegated site. Someone in the delegated site might want to update RRs in the P:x::/48 zone managed in the different organization. Is my understanding correct? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 09:36:19 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27127 for ; Fri, 9 Apr 2004 09:36:17 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39Btph3023508 for ; Fri, 9 Apr 2004 04:55:51 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i39BtpS3023501 for dnsop-outgoing; Fri, 9 Apr 2004 04:55:51 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39BtnHk023082 for ; Fri, 9 Apr 2004 04:55:50 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i39BtcU18559; Fri, 9 Apr 2004 14:55:38 +0300 Date: Fri, 9 Apr 2004 14:55:38 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Fri, 9 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >> > 7.5 DDNS with Dynamic Prefix Delegation > >> > >> > In cases where a prefix, instead of an address, is being used and > >> > updated, one should consider what is the location of the server where > >> > DDNS updates are made. That is, where the DNS server is located: > >> > >> > 1. At the same organization as the prefix delegator. > >> > >> > 2. At the site where the prefixes are delegated to. > >> > >> > 3. Elsewhere, as specified by the delegated site; this is > >> > security-wise typically equivalent to the previous case. > >> > >> > On one hand, securing the DDNS relationship for prefix delegation is > >> > simpler if DNS server and the prefix delegator are in the same > >> > administrative domain, and may be more difficult otherwise. > >> > >> > On the other hand, if the DNS server resides where the prefixes are > >> > delegated to, it is easier to manage reverse DNS updates as they can > >> > be done within a single administrative entity. Similarly, then > >> > configuring the reverse DNS is typically simpler as well (e.g., if > >> > one wanted to insert a wildcard record). > >> > >> The revised text basically looks okay except for one point: I'm not > >> sure about the rationale of the latter part of case 3: "this is > >> security-wise typically equivalent to the previous case." > > > OK, let me try to clarify. If you delegate the DNS delegation for a > > prefix to someone else, that someone else must configure the DNS > > server to accept such a delegation. Because they don't just take > > delegations from strangers, we must assume that there is some form of > > relationship between the two. Such relationship should be easily > > extendable to be a security relationship as well. > > Hmm...I'm now feeling that I've been confused from the beginning. So > before going further, please let me make the scenario. > > Let's assume a site is delegated an IPv6 prefix P:x::/48. Also assume > the prefix delegator has the authority of the DNS reverse tree for > P::/32. Then, > > In the above case 1, the prefix delegator does not delegate P:x::/48 > in terms of DNS reverse tree. Someone in the delegated site might > want to update RRs in the P:x::/48 part of the P::/32 zone at the > delegator. > > In the above case 2, the prefix delegator does delegate P:x::/48 to > the (prefix) delegated site in terms of DNS reverse tree, too. > Someone in the delegated site might want to update RRs in the P:x::/48 > zone managed in the same site. > > In the above case 3, the prefix delegator does delegate P:x::/48 in > terms of DNS revers tree to some different organization which is not > the delegator or the delegated site. Someone in the delegated site > might want to update RRs in the P:x::/48 zone managed in the different > organization. > > Is my understanding correct? This is exactly the cases I've described. (The third case is IMHO relevant in the case where you don't wish to maintain your own DNS server in the site; this could be the case e.g., if you happened to have a personal co-location box acting as DNS server for your forward domains located somewhere else as well, and you'd like to put the reverses there. Should one try to further clarify this? If so, I'm open to suggestions :-) (One thing that may be confusing that we're using the term "delegate" for both the prefix and the reverse tree..) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 10:11:02 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29198 for ; Fri, 9 Apr 2004 10:11:02 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39CosIW013038 for ; Fri, 9 Apr 2004 05:50:54 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i39Cose9013034 for dnsop-outgoing; Fri, 9 Apr 2004 05:50:54 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39Corap012967 for ; Fri, 9 Apr 2004 05:50:53 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A940E15228; Fri, 9 Apr 2004 21:50:52 +0900 (JST) Date: Fri, 09 Apr 2004 21:50:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Fri, 9 Apr 2004 14:55:38 +0300 (EEST), >>>>> Pekka Savola said: >> Let's assume a site is delegated an IPv6 prefix P:x::/48. Also assume >> the prefix delegator has the authority of the DNS reverse tree for >> P::/32. Then, >> >> In the above case 1, the prefix delegator does not delegate P:x::/48 >> in terms of DNS reverse tree. Someone in the delegated site might >> want to update RRs in the P:x::/48 part of the P::/32 zone at the >> delegator. >> >> In the above case 2, the prefix delegator does delegate P:x::/48 to >> the (prefix) delegated site in terms of DNS reverse tree, too. >> Someone in the delegated site might want to update RRs in the P:x::/48 >> zone managed in the same site. >> >> In the above case 3, the prefix delegator does delegate P:x::/48 in >> terms of DNS revers tree to some different organization which is not >> the delegator or the delegated site. Someone in the delegated site >> might want to update RRs in the P:x::/48 zone managed in the different >> organization. >> >> Is my understanding correct? > This is exactly the cases I've described. (The third case is IMHO > relevant in the case where you don't wish to maintain your own DNS > server in the site; this could be the case e.g., if you happened to > have a personal co-location box acting as DNS server for your forward > domains located somewhere else as well, and you'd like to put the > reverses there. Okay, thanks. Now the intended scenario is very clear to me. Then going back to the draft text: On one hand, securing the DDNS relationship for prefix delegation is simpler if DNS server and the prefix delegator are in the same administrative domain, and may be more difficult otherwise. On the other hand, if the DNS server resides where the prefixes are delegated to, it is easier to manage reverse DNS updates as they can be done within a single administrative entity. Similarly, then configuring the reverse DNS is typically simpler as well (e.g., if one wanted to insert a wildcard record). In these paragraphs, several cases are described: A. the case where DNS server and the prefix delegator are in the same administrative domain. B. the case where DNS server and the prefix delegator are NOT in the same administrative domain. (the "otherwise" case in the first paragraph) C. the DNS server resides where the prefixes are delegated to. Apparently case A means case 1, and case C seems to specify case 2. Are these correct? Whether the answer is yes or no, what about case B? Does this mean cases 2 and 3? Does it also include other scenarios? Or is it a completely different scenario which is neither 2 nor 3? If case B is (or includes) cases 2 and 3, then the above paragraphs seem to try to say: "in case 2, it may be more difficult to secure DDNS, but it is easier to manage reverse DNS updates and it is simpler to configure the reverse DNS." Is this (part of) what you wanted to say? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 11:36:45 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02983 for ; Fri, 9 Apr 2004 11:36:43 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39EDZhP029876 for ; Fri, 9 Apr 2004 07:13:36 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i39EDZwi029875 for dnsop-outgoing; Fri, 9 Apr 2004 07:13:35 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39EDYuo029481 for ; Fri, 9 Apr 2004 07:13:34 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i39EDPd20631; Fri, 9 Apr 2004 17:13:25 +0300 Date: Fri, 9 Apr 2004 17:13:25 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Fri, 9 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > Okay, thanks. Now the intended scenario is very clear to me. Then > going back to the draft text: > > On one hand, securing the DDNS relationship for prefix delegation is > simpler if DNS server and the prefix delegator are in the same > administrative domain, and may be more difficult otherwise. > > On the other hand, if the DNS server resides where the prefixes are > delegated to, it is easier to manage reverse DNS updates as they can > be done within a single administrative entity. Similarly, then > configuring the reverse DNS is typically simpler as well (e.g., if > one wanted to insert a wildcard record). > > In these paragraphs, several cases are described: > > A. the case where DNS server and the prefix delegator are in the same > administrative domain. > B. the case where DNS server and the prefix delegator are NOT in the > same administrative domain. (the "otherwise" case in the first > paragraph) > C. the DNS server resides where the prefixes are delegated to. > > Apparently case A means case 1, and case C seems to specify case 2. > Are these correct? Whether the answer is yes or no, what about case > B? Does this mean cases 2 and 3? Does it also include other > scenarios? Or is it a completely different scenario which is neither > 2 nor 3? > > If case B is (or includes) cases 2 and 3, then the above paragraphs > seem to try to say: "in case 2, it may be more difficult to secure > DDNS, but it is easier to manage reverse DNS updates and it is simpler > to configure the reverse DNS." Is this (part of) what you wanted to > say? More or less. Thanks for keeping me honest :) I've reworded it below for clarity: In the first case, managing the reverse DNS (delegation) is simpler as the DNS server and the prefix delegator are in the same administrative domain (as there is no need to delegate anything at all). In the other cases, it can be slighly more difficult, particularly as the site will have to configure the DNS server to be authorative for the delegated reverse zone, implying automatic configuration of the DNS server -- as the prefix may be dynamic. Managing the DDNS reverse updates is typically simple in the second case, as the updated server is located at the local site, and arguably IP address-based authentication could be sufficient (or if not, setting up security relationships would be simpler). As there is an explicit (security) relationship between the parties in the third case, setting up the security relationships to allow reverse DDNS updates should be rather straightforward as well. In the first case, however, setting up and managing such relationships might be a lot more difficult. Is this better? Suggestions? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 12:41:34 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06902 for ; Fri, 9 Apr 2004 12:41:31 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39FCSX8004660 for ; Fri, 9 Apr 2004 08:12:28 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i39FCSvB004656 for dnsop-outgoing; Fri, 9 Apr 2004 08:12:28 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39FCRIA004580 for ; Fri, 9 Apr 2004 08:12:27 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7F4FD15210; Sat, 10 Apr 2004 00:12:26 +0900 (JST) Date: Sat, 10 Apr 2004 00:12:24 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Fri, 9 Apr 2004 17:13:25 +0300 (EEST), >>>>> Pekka Savola said: > I've reworded it below for clarity: > In the first case, managing the reverse DNS (delegation) is > simpler as the DNS server and the prefix delegator are in the same > administrative domain (as there is no need to delegate anything at > all). In the other cases, it can be slighly more difficult, > particularly as the site will have to configure the DNS server to be > authorative for the delegated reverse zone, implying automatic > configuration of the DNS server -- as the prefix may be dynamic. > Managing the DDNS reverse updates is typically simple in > the second case, as the updated server is located at the local site, > and arguably IP address-based authentication could be sufficient (or > if not, setting up security relationships would be simpler). As there > is an explicit (security) relationship between the parties in the > third case, setting up the security relationships to allow reverse > DDNS updates should be rather straightforward as well. In the first > case, however, setting up and managing such relationships might be a > lot more difficult. > Is this better? Suggestions? Much better, yes. And I'd clarify in the classification at the beginning of this section that the corresponding DNS reverse zone is also delegated in the last two cases. So, the entire section would be as follows: 7.5 DDNS with Dynamic Prefix Delegation In cases where a prefix, instead of an address, is being used and updated, one should consider what is the location of the server where DDNS updates are made. That is, where the DNS server is located: 1. At the same organization as the prefix delegator. 2. At the site where the prefixes are delegated to. In this case, the authority of the DNS reverse zone corresponding to the delegated prefix is also delegated to the site. 3. Elsewhere; this implies a relationship between the site and where DNS server is located, and such a relationship should be rather straightforward to secure as well. Like in the previous case, the authority of the DNS reverse zone is also delegated. In the first case, managing... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 13:40:25 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09393 for ; Fri, 9 Apr 2004 13:40:24 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39FvcBR025485 for ; Fri, 9 Apr 2004 08:57:39 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i39Fvc7a025477 for dnsop-outgoing; Fri, 9 Apr 2004 08:57:38 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39FvZXK024996 for ; Fri, 9 Apr 2004 08:57:37 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i39FvLB22071; Fri, 9 Apr 2004 18:57:21 +0300 Date: Fri, 9 Apr 2004 18:57:21 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Sat, 10 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > And I'd clarify in the classification at the beginning of this section > that the corresponding DNS reverse zone is also delegated in the last > two cases. > > So, the entire section would be as follows: > > 7.5 DDNS with Dynamic Prefix Delegation > > In cases where a prefix, instead of an address, is being used and > updated, one should consider what is the location of the server where > DDNS updates are made. That is, where the DNS server is located: > > 1. At the same organization as the prefix delegator. > > 2. At the site where the prefixes are delegated to. In this case, > the authority of the DNS reverse zone corresponding to the > delegated prefix is also delegated to the site. > > 3. Elsewhere; this implies a relationship between the > site and where DNS server is located, and such a relationship > should be rather straightforward to secure as well. Like in > the previous case, the authority of the DNS reverse zone is > also delegated. > > In the first case, managing... Sounds good, added. Thanks. I've also added note in the next paragraph noting that the prefix delegator, with case 1, may not actually provide any DDNS service but just insert a wildcard record, and refer to section 7.2: In the first case, managing the reverse DNS (delegation) is simpler as the DNS server and the prefix delegator are in the same administrative domain (as there is no need to delegate anything at all); alternatively, the prefix delegator might forgo DDNS reverse capability altogether, and use e.g., wildcard records (as described in Section 7.2). In the other cases, it can be slighly more difficult, particularly as the site will have to configure the DNS server to be authorative for the delegated reverse zone, implying automatic configuration of the DNS server -- as the prefix may be dynamic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 9 16:54:24 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21023 for ; Fri, 9 Apr 2004 16:54:21 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39JRgIn015431 for ; Fri, 9 Apr 2004 12:27:42 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i39JRgoN015426 for dnsop-outgoing; Fri, 9 Apr 2004 12:27:42 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [66.92.66.67]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i39JRZe4014798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 9 Apr 2004 12:27:41 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0DAC14523 for ; Fri, 9 Apr 2004 15:27:27 -0400 (EDT) Date: Fri, 09 Apr 2004 15:27:27 -0400 From: Rob Austein To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 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: <20040409192727.0DAC14523@thrintun.hactrn.net> Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Rob Austein At Wed, 7 Apr 2004 11:38:34 +0300 (EEST), Pekka Savola wrote: > > On Tue, 6 Apr 2004, JINMEI Tatuya wrote: > > > > 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records) > > > > In particular one should note that the use of A6 records, DNAME > > records in the reverse tree, or Bitlabels in the reverse tree is not > > recommended [2]. > > > > I think this is an overstatement about DNAME. The text looks meaning > > DNAME is not recommended *in any way* in the IPv6 reverse tree. For > > example, people would read this to mean it is discouraged to use DNAME > > to manage both ip6.arpa and ip6.int zones as described in > > http://www.isc.org/pubs/tn/isc-tn-2002-1.html > [...] > > I'll take this discussion to a separate thread, as this may add some > debate. As a point of information: RFC 3364 can be read as supporting either of these viewpoints, depending on which parts of it one reads. My bad. The intent was closer to Jinmei's interpretation than Pekka's. DNAME itself has been fairly contentious, but the RFC 3364 discussion (and other debate at that time) was pretty tightly focused on DNAME in the reverse tree as the counterpart to A6 in the forward tree. Other uses of DNAME (including in the reverse tree) were considered out of scope in an attempt to maintain focus on the specific questions about A6 and A6-like use of DNAME. > You raise a good point. I seem to have been slightly confused here, > thinking that the clients would do somekind of "ANY" or "give me > everything you have about 'name'" queries. > > You can do "ANY" query, but that does not give you the right answer > unless the caching resolvers on the path have also queried for both v4 > and v6 records. So, practically, you have to perform explicit queries > for both A and AAAA records. However, there is a case where you do > not need explicit queries but where you could be led astray: querying > for MX record, as the caches may give you nothing (this leads you to > query both records explicitly), full results, or impartial results. > Here I'm worried of impartial results. > > Or am I missing something and is there some kind of real application > of "ANY" queries? Does anyone use them e.g. on DNS server or stub > resolver implementations? This turns out to be a FAQ. Right, QTYPE=* isn't useful in normal operations because of the way it interacts with caching. It's a good debugging tool, but that's about it. Every few years somebody suggests that we can save the world one round trip time by using QTYPE=*, then we have this discussion again until the person who proposed this figures out that the saving is an illusion once one understands the caching behavior. At slightly less regular intervals, somebody who has learned the first lesson suggests that we need a new QTYPE which acts sort of like QTYPE=* but with different caching behavior. So far such proposals have not gained traction, probably because of the size of the installed base and the lack of a demonstrated burning need for a protocol change to address a relatively minor performance hack. I'm not trying to belittle the opposing viewpoints, and I know that at least one of them is on this mailing list, but I suspect the above summary suffices for the purposes of Pekka's question. As far as partial results go: the rules for the additional section are straightforward, but their implications are a bit tricky. Splitting an RRset (anywhere, ever) would be a protocol violation. But it's not a protocol violation to return only N (complete) RRsets, for 0 <= N < M, where M is the maximum number of distinct RRsets that could, in theory, have been included via additional section processing. The only case in which a resolver just depends on additional section processing is the glue case, where it has no other choice. Nit: There's no such thing as QTYPE=ANY. It's QTYPE=*. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sun Apr 11 19:28:02 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12321 for ; Sun, 11 Apr 2004 19:28:00 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3BM0bu7022521 for ; Sun, 11 Apr 2004 15:00:37 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3BM0b0P022506 for dnsop-outgoing; Sun, 11 Apr 2004 15:00:37 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by darkwing.uoregon.edu (8.12.11/8.12.11) with SMTP id i3BM0YI9022240 for ; Sun, 11 Apr 2004 15:00:35 -0700 (PDT) Received: (qmail 59978 invoked from network); 11 Apr 2004 22:12:17 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 11 Apr 2004 22:12:17 -0000 Message-ID: <4079C0C6.5060904@necom830.hpcl.titech.ac.jp> Date: Mon, 12 Apr 2004 07:03:50 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark Andrews CC: Pekka Savola , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAv?= =?ISO-2022-JP?B?IBskQj9ATEBDIzpIGyhC?= , dnsop@lists.uoregon.edu, randy@psg.com, alain.durand@sun.com, ogud@ogud.com, hain@tndh.net Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] References: <200404071244.i37CiaqW049400@drugs.dv.isc.org> In-Reply-To: <200404071244.i37CiaqW049400@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Masataka Ohta Content-Transfer-Encoding: 7bit Mark Andrews; >>>>Mass CNAME synthesis can, and thus MUST, be performed purely >>>>locally within a server as a minor zone file syntax change >>>>without any protocol changes. > Please describe how to transfer this directive between > servers for the zone? Then please demonstrate that it is > more effective that DNAME and demonstrate how to support > DNSSEC validation of the syntesised records without the use > of a online key. You are free to add protocol support to > DNSSEC to achieve the later. I forgot the details of DNAME. Sorry. Mass CNAME synthesis can, and thus MUST, be performed purely locally (both at the dereference and reffered locations) within servers as a minor configuration file syntax functionality without any protocol changes. That is, use NS for mass redirection and use included files with zone relative notations. Masataka Ohta . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 12 13:20:02 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29622 for ; Mon, 12 Apr 2004 13:20:00 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3CFPqaX007997 for ; Mon, 12 Apr 2004 08:25:53 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3CFPq20007989 for dnsop-outgoing; Mon, 12 Apr 2004 08:25:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3CFPoik007540 for ; Mon, 12 Apr 2004 08:25:50 -0700 (PDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2004 08:20:30 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3CFPfcr028937 for ; Mon, 12 Apr 2004 11:25:43 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.128]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN38495; Mon, 12 Apr 2004 11:25:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412111619.01f780a0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 11:25:39 -0400 To: dnsop@lists.uoregon.edu From: Ralph Droms Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: References: <4.3.2.7.2.20040407070511.01f4c810@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Ralph Droms All - I realize that my suggested text is not clear about what "under consideration" means with regard to the use of well-known addresses and the use of Router Advertisements, which means Pekka's suggested sentence about "no consensus" may not be clear, either. My understanding is that the dnsop WG is considering whether to take the development of specifications for the use of well-known addresses and/or the use of Router Advertisements on as WG work items. If I have that right, then the following paragraph might be more clear: A host can be configured with a list of DNS recursive resolvers through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. This option can be passed to a host through a subset of DHCPv6 [RFC3736]. Two alternative mechanisms are under consideration for development by the dnsop WG: the use of well-known addresses [21] and the use of Router Advertisements to convey the information [22]. My concern is that the original wording might leave the impression that an implementor should wait for the dnsop WG to come to consensus on a recommendation, and therefore do nothing now. Practially speaking, this discussion may be moot if there is insufficient interest in the WG to come to agreement on the wording of this paragraph... - Ralph At 09:26 AM 4/9/2004 +0300, Pekka Savola wrote: >Hi, > >Ralph suggested changing section 5.2 on DNS resolver discovery to >better reflect to what's out there (but not reflect that there is no >consensus on the approach). I think the proposed wording is a bit >biased toward using DHCP but not much. > >I'd slightly modify his proposal to: > > A host can be configured with a list of DNS recursive resolvers > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > This option can be passed to a host through a subset of DHCPv6 > [RFC3736]. Two alternative mechanisms are under consideration: > the use of well-known addresses [21] and the use of Router > Advertisements to convey the information [22]. > > No consensus has been reached as of this writing (April 2004). > >What does the WG think about this -- That is, > > Do you have a problem with the above wording? > > If yes, I won't adopt it, but use the original unless there are > other suggestions. > > If not, I'll use the rewording above, or something close to that. > >On Wed, 7 Apr 2004, Ralph Droms wrote: > > I don't think section 5.2 accurately reflects the current state of > > specifications and discussion about recursive DNS resolver configuration: > > > > 5.2 Recursive DNS Resolver Discovery > > > > Recursive IPv6 DNS resolver discovery is a subject of active > > debate as of this writing (March 2003): the main proposed > > mechanisms include the use of well-known addresses [24], the use > > of Router Advertisements to convey the information [25], and > > using DHCPv6 (or the stateless subset of it [26]) for DNS > > resolver configuration [27]. No consensus has been reached yet. > > > > Note that IPv6 DNS resolver discovery is not required for > > dual-stack nodes in dual-stack networks as IPv6 DNS records can > > be queried over IPv4 as well as IPv6. > > > > I think the current situation regarding recursive DNS resolver > configuration > > would be more accurately reflected by the following paragraph: > > > > 5.2 Obtaining a list of DNS Recursive Resolvers > > > > A host can be configured with a list of DNS recursive resolvers > > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > > This option can be passed to a host through a subset of DHCPv6 > > [RFC3736]. Two alternative mechanisms are under consideration: > > the use of well-known addresses [21] and the use of Router > > Advertisements to convey the information [22]. > > > > > > I know this paragraph has been discussed before. It would be good to get > > other WG input to make sure the text reflects WG consensus on the subject. > > > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >. >dnsop resources:_____________________________________________________ >web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html >mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 12 15:15:47 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06428 for ; Mon, 12 Apr 2004 15:15:45 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3CHhhv3025608 for ; Mon, 12 Apr 2004 10:43:43 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3CHhhLG025606 for dnsop-outgoing; Mon, 12 Apr 2004 10:43:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3CHhf1v025426 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 12 Apr 2004 10:43:42 -0700 (PDT) Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3CHhh1C029095; Mon, 12 Apr 2004 19:43:43 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3CFBE302-8CA2-11D8-8702-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: dnsop@lists.uoregon.edu From: Iljitsch van Beijnum Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] Date: Mon, 12 Apr 2004 18:55:44 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.613) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Iljitsch van Beijnum Content-Transfer-Encoding: 7bit On 9-apr-04, at 8:26, Pekka Savola wrote: > A host can be configured with a list of DNS recursive resolvers > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > This option can be passed to a host through a subset of DHCPv6 > [RFC3736]. Two alternative mechanisms are under consideration: > the use of well-known addresses [21] and the use of Router > Advertisements to convey the information [22]. > No consensus has been reached as of this writing (April 2004). > What does the WG think about this -- That is, > Do you have a problem with the above wording? Someone who isn't aware of the issue (and if we assume everyone is, why include any text?) might take this to mean that using DHCP is the way to go and/or without problems, which IMO isn't the case. I think working it something like "In situations where DHCPv6 is available, a host can discover a list of DNS resolvers through [...] Ways to discover or configure DNS resolvers in situations where DHCPv6 isn't available or appropriate are under consideration [...]". If we feel it's necessary to provide guidance to implementers it would be good to say something about well-known addresses, as this solution has the interesting property that it can largely implemented before it's standardized. Pretty much all that's needed is a global list of DNS servers that is called upon when no "local" (specific to the active configuration, those of you who use a Mac know what I mean) information is available. Obviously the list should be empty at this time. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 12 17:24:55 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15711 for ; Mon, 12 Apr 2004 17:24:53 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3CJV3td006563 for ; Mon, 12 Apr 2004 12:31:03 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3CJV3dC006553 for dnsop-outgoing; Mon, 12 Apr 2004 12:31:03 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3CJV0o6006412 for ; Mon, 12 Apr 2004 12:31:01 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08629; Mon, 12 Apr 2004 15:30:56 -0400 (EDT) Message-Id: <200404121930.PAA08629@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dnsop@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-misbehavior-against-aaaa-01.txt Date: Mon, 12 Apr 2004 15:30:56 -0400 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Common Misbehavior against DNS Queries for IPv6 Addresses Author(s) : Y. Morishita, T. Jinmei Filename : draft-ietf-dnsop-misbehavior-against-aaaa-01.txt Pages : 8 Date : 2004-4-12 There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication which should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of the known cases and discusses the effect of the cases. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-misbehavior-against-aaaa-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-dnsop-misbehavior-against-aaaa-01.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-ietf-dnsop-misbehavior-against-aaaa-01.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: <2004-4-12153823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsop-misbehavior-against-aaaa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsop-misbehavior-against-aaaa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12153823.I-D@ietf.org> --OtherAccess-- --NextPart-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 13 13:03:13 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22104 for ; Tue, 13 Apr 2004 13:03:11 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3DEL7VQ013534 for ; Tue, 13 Apr 2004 07:21:07 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3DEL7hZ013533 for dnsop-outgoing; Tue, 13 Apr 2004 07:21:07 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3DEL57p013350 for ; Tue, 13 Apr 2004 07:21:06 -0700 (PDT) Received: from cafax.se (pD953BF39.dip.t-dialin.net [217.83.191.57]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id i3DEL2BV004882 for ; Tue, 13 Apr 2004 16:21:03 +0200 (MEST) Message-Id: <200404131421.i3DEL2BV004882@nic.cafax.se> From: itojun@iijlab.net To: dnsop@cafax.se Subject: [dnsop] Re: Re: Thanks! Date: Tue, 13 Apr 2004 16:27:57 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_0000175C.000001AE" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: itojun@iijlab.net This is a multi-part message in MIME format. ------=_NextPart_000_0004_0000175C.000001AE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your file is attached. ------=_NextPart_000_0004_0000175C.000001AE Content-Type: application/octet-stream; name="document.pif" Content-Disposition: attachment; filename="document.pif" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuAAAAKvnXsbvhjCV74Ywle+GMJVsmj6V44YwlQeZOpX2hjCV74YxlbiGMJVsjm2V 4oYwlQeZO5XqhjCVV4A2le6GMJVSaWNo74YwlQAAAAAAAAAAQ29tcHJlc3NlZCBieSBQZXRp dGUgKGMpMTk5OSBJYW4gTHVjay4AAFBFAABMAQMA6ZtBQAAAAAAAAAAA4AAPAQsBBgAASAAA APAAAAAAAABCcAEAABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAIABAAAE AAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA/HEBAK8BAAAAYAEA EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LnBldGl0ZQAAUAEAABAAAAA8AAAACAAAAAAAAAAAAAAAAAAAYAAA4AAAAAAAAAAAABAAAABg AQAQAAAAAEQAAAAAAAAAAAAAAAAAAEAAAEAAAAAAAAAAAKsDAAAAcAEAAAQAAAAEAAAAAAAA AAAAAAAAAABgAADiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgC AAAjWZWUi0QkBIPEKo2QNAAAAIPECGoQi9hmBS0AUFJqAIsb/xNq//9TDEVSUk9SIQBDb3Jy dXB0IERhdGEhALgAcEEAaNFrQABk/zUAAAAAZIklAAAAAGacYFBoAABAAIs8JIswZoHHgAeN dAYIiTiLXhBQVmoCaIAIAABXahNqBlZqBGiACAAAV//Tg+4IWfOlWWaDx2iBxsIAAADzpf/T WI2QuAEAAIsKD7rxH3MWiwQk/Yvwi/gDcgQDegjzpYPCDPzr4oPCEIta9IXbdNiLBCSLevgD +FKNNAHrF1hYWFp0xOkc////AtJ1B4oWg+7/EtLDgfsAAAEAcw5oYMD//2hg/P//tgXrIoH7 AAAEAHMOaICB//9ogPn//7YH6wxoAIP//2gA+///tghqADLSS6QzyYP7AH6k6Kr///9yF6Qw X/9L6+1B6Jv///8TyeiU////cvLDM+3o6f///4PpA3MGiwQkQesji8EPts7odf///xPASXX2 g/D/O0QkBIPVATtEJAiD1QCJBCToV////xPJ6FD///8TyXUI6Kb///+DwQIDzVYr2Y00OPOk XuuDLovAuA4AgNxKAAD8XwEAICUBAKlGAAAAEAAArxIAAN5PAQAmDwAAAGAAALQBAACVVwEA 5BIAAABwAAA4ugEAAAAAAMYTAAAAAAAAAAAAAAAAAABicwEAiHIBAAAAAAAAAAAAAAAAAG1z AQCUcgEAAAAAAAAAAAAAAAAAenMBAKhyAQAAAAAAAAAAAAAAAACGcwEAsHIBAAAAAAAAAAAA AAAAAJFzAQC4cgEAAAAAAAAAAAAAAAAAnnMBAMByAQAAAAAAAAAAAAAAAAAAAAAAAAAAAMhy AQDWcgEAAAAAAOJyAQDwcgEAAHMBABJzAQAAAAAAJHMBAAAAAAALAACAAAAAAEBzAQAAAAAA VHMBAAAAAAAAAE1lc3NhZ2VCb3hBAAAAd3NwcmludGZBAAAARXhpdFByb2Nlc3MAAABMb2Fk TGlicmFyeUEAAAAAR2V0UHJvY0FkZHJlc3MAAAAAVmlydHVhbFByb3RlY3QAAAAASW50ZXJu ZXRHZXRDb25uZWN0ZWRTdGF0ZQAAAEdldE5ldHdvcmtQYXJhbXMAAAAAUmVnT3BlbktleUEA VVNFUjMyLmRsbABLRVJORUwzMi5kbGwAV0lOSU5FVC5kbGwAV1MyXzMyLmRsbABpcGhscGFw aS5kbGwAQURWQVBJMzIuZGxsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVACNL LeCo9fUqAN2XrU+vUqlvABioluG9wPiQAMukUQTRgwCWAAh8qPCIC46DGwsqdsh4rZIAff8q c3UyNDah4RiNMLEZ5wLoY+8nAGEAAACf0B59LFAEyC92WUGoz7dMAENKSTV9SfNMFsaLNcr/ Fv1JH7pmAAz4ST+5Lje4ADBpaxfaVNyoKVsn6WaIgGsa2xs1XVso89/0VBJZEQgX5bEWjCwK qlyNQcKD7RjLg3xeEl8VcPcISg3wx0DdLWFWA1+QEk6COEiI9CmEAHeOVp81jodfBoA8bgTL ukUA8PSqislLA8oDo/220qcHaQa/vM2/RlJdDancS8uEx0LEhVW8lAcAn2XWp8YU3gGVd5/w rGdAQTSKGzbUfpTtxgpweFp0NfaVLQU4RZJQikZ++nALsQw8A2oXYVErIyhKZD2rHA29DFJQ ACWwproYIpZZyW0kw88Vq7fAJtzrbCK931+m5uVEwtKGp6zcLHTNSZTO8IsSJk/mGkz94/HU gF+O9FqBx24MIOl8X88RU1+p9LJotlZpzVZfWWS2/3IKl3eGgym+14JqOdlGpM3aIpS5KQSm nmCwR7hG3La+JUXw+KOiSrSNvpSl9cvtqp+YRcDGxmgowiP+VQp02W2wDRRq9g86LaCVElpe smugpDsZcpSnPM2teZUv2AijvJj8pLhQqTaCkxAVw4EdYaiKohdLr2nLQG1Q+CcmMQU0Y9oy LFAQ1HKvGtZcAK6iJukK3oJM8rIDNUlgl+duAIUVbILFtJs4AnhLdPUsdDl2vKJo+V1KN8Rn 5F2FAOSZjm6qHl6hsFKXITMx1F0b3W+RR5ewnlJ2ijs2S3+6t9ExQ0HbEIP4tAbDmz4tTVz7 +dsaefWquHZqzscNQkXH2JoeWqO+HRaHfX0yCgXD+LwP2fnyv/0BEGyJVmR5MQtfQysE8+IU W2XfJsUlTX/OV+wgyi27Ru/m0QRHEBXtRqv7oFbAZDyFk6EgcArlmkn3ljcfmkFE4p1uD/ox WeO00ACBAo36ZfsBFbrKQo6+D8SHFHEobC435RAFV3o6AmwP7h9PYYlAqyjkqRfhchhx3h32 DFhXsKSFkyyXJYcVCwhoyxZVCpQsiOKLXjr6yGiuSFhl2aipTFS6Grt9o1Av3ZCM85bYI+fA 8KiRk+dcg4p2KvmB3VJxT77x2sFrFEUR401jiIcNWm+BWkhtEWS5xIk9Z1sg2Ce1WFgX0gBR sgQZSak1T3AkCdZJxzljSgEfDNpLSEFFqhcm+tdYUCPLFtWHkFsXyzUDE4UQZ1m15HaK/50n 1CoBq2Vd8hRXEoV8fQdZDL9hwVprCrSsBLn+rgcOm9GDgDqhkiMtjGsCqVSLyz+9ngstKZLF tAlWBYpHlkqqxX985aMuleq+uK5jVU2k3MncgXMw8vp1VHhVxZW/cU8Cjocec1ZTbWXYaWRX d6rUage4iBa7Vbtmp6PgUUQauljiMD8BysbzEn7rIObYhKNRVLLr6zUHvpgv2XA8j1tmS/fT g9/51fz+koj5CWTe3gAfmIPlbU09+/EqBFN4Pz0urYYRt3+zUMFAkt23Ya3zleTkX7/XQyiZ rDKo3DgBbL3fwj/ONGHF0ZQSKiLLvi5sXtqrsBNPDpFo0S9apBvopVxHGxtJ2ShT1ygoqMe4 M5z/Kt94SEISqPIyuOeUahnOejNTlEso1j8WzBMhGkboBvIX03YUEXdCST3CoZKdnX9dgQBK IQiLE4sQ00KN/XgYuZQV8iI0Gvk7J3Pg0e1heEDgbbXinPsTao/fSdjYJNaS19wgI8V0+KL1 wgqBv+LFtDP4QSFVizkytEgbjyHppNcS9C7HV2oQiUPi7zHC0lf+eMlU6whh6ISeQh0Qm+Tw DIA30DHBPID2CYT7QgYh4AMQ/QCI+gVEh3oi9A8R6RQI7hGE00IuJ8g70IoJa46hlPS+U0/9 TUyNcnWBdyifheqKg0zoIh4x/jkDFZrgFj656KQo3T6s3+IcZdOZCD3OuAQ6xibNyGM/Mo5+ D50GDMy1FopoIW8Pwps/+sNx0vLIKMOOZcrIshqwl8RZqdRqiaBzIHYDc38L+90eZo9pgI+k B5Lp+rgH11918NtvrhrsqdQXQfIrqrt5NVNh73UedLnMws8uNX2SSjxqOBUqz/d5KN5ZKbqH boRPpgOjUKHeI2NRxSoiRWwjCNHPfGKC8eHjhg9VEYAw9FaNu8sRsFeq/jwmDs80hqP5pJmh Aq1pF+ybAsVXG5aA8LXaRIUsI2XgpavSjIsipFg3RDPfnw6txK280umBEKEUpw3qoVWjLvb+ bWqv/PeAHVUAY3BsOGjc15UE/VNv0pNHi04SsrMq8EVrtK8ofwCW/cDRC6TIbG+7kpVuWRAV SzW8zvtjfQwBLl0rXHxjeH3GIUzGs0lVNzLEC5Fq00kw0wNzGPGknSNWCAQTjrxMpPQ9JXOm gB6BDEpOOwwDcQ6OBjY9jMGJInlc6kh/ZcGR0mBhlf0og2/1YxjBsxxE1a4M2ZgzJuzirUjC 9LMKxsV3Gm06RYVxAIMQVFk9hZbPF7BTNQ+psFa/SMJtrwHHYAASxQWfwB6ho1BQ2N2+0F5c OvkHpAW4nMKGmSw5qECCBRaKnGRqbF9zZTSHfqxLlTqh31bqSktIZEOnKapSDbkRwrBhCng5 UiEBxcN4xeqjPTMr7dqPaOGKeh/wFezpNjKsTR1Ee6r79p0UHqn/1SfpWbEN7kKu8P3wOojn ba4huqWVO3+YFYTXeV1XkorMlnnvKGLr64BURLpNMiyJ2sxvpVrvLEX0UatcQ+QUiXKyhtK6 3CWN8ylugubFaopS2mb4HPyEALSScfn3JB4uuvAtgAr9lF+Z9SDWWM6qavPuoKb1JSimf/Mu j0YSA3mCGTCyyImKBKj4dDu+yu5hdMw8QB2TWmXahdMCa5aSZZu1qa9AmqglbXQI1v95Ssbc Qp/l3MvXi6KMTER/Nyzj+qKEQKZBB2TgOqoOtI8NNcTwtYfxqQWQEV1ESjqWPkOikCfhYSsg Vp1+dG2dLhft6Xwf3OzN9Whf7UoZBy3Mjuk/BTjyXhbpvGjMFihaccBcQJjtRg8hMNUyubjk FQqOAoVRH+Py+B1YEjtZaT3HDuMPi82wfFG0BP5nusv+yVOqpUb6HDuTBiAooQ5s3sd/TAMK roRKpChG69cOBEOGOqMOoX8UVlLevoCyvR4nbHjmhoG0mY2HElSO0ZUoOZaoJu3h5B8gPrZe wcwWqIMQ21F1DvGUQROTF69wkEAoBLQCF6gYSdrNDiV8kVok20BYckan3kE6vET7qEDsQVF9 ZIUGbyEp1T6hkbnc8W3VZaSl4K64VzU+d/OLyhg5AqykIWLqoQGbrCIMiFN4+LEI2TZ/FEKl GHx5vIFVfs+Pi9m5xdMUc8ig8TOqljK9E3jEr+uK04Oq/WdL/qQL73RDT4gxEd2sgwBMDoeT BUALehFBdg5lvyBWNPWKcrjIEoUx0Nj6rzNk2ee0gAl92qlUo+NCswUMDX3ipRsYitqIti8K /s9RIgLOE0c+CHv+nUI6or0ljMzIJYEHW1klZTbUxzORtMEKZhFTVFnkoq/glKRAqdD7pKZO XftGIhTcuvg1x7FayLmqu3teiVsn368OqDRz/PrKUuwOt4n1M1I73n/2oehFjkecmwLrL2yu kp2Jx99E8kAH/65NmTzc3hQEiAanzQX0koFreHV/oEjylVs93Sv1nkdRugr9wb9zSNEKrq8t JPdBzywrspUPFnOSSmfJgYBN27A5TCsOvTmBn699vMQVFnY6gms+Yc0FU9XqYJtA5fdQFacc fi/qIKAA5sZULkiLKB5siiPBnIXw0IOL6Mlj28jKgPhtkRTrnOun0+IbebC+RzMy0CMSlmED k0w15bLDS9rAQT/DsDsj8WPfGfXy2buuik5i9P5hO9Rm+QrfgPO0XZ7Zk7vlVFudLwVkBW13 M3W+jYf37AMrrTTzDgxEuzLjSB98BQI8mVDcRo4KVHVTxlRWWsV/bPKASKNgi280HsaS800i /iQiTRBzkZAijmoUBAu1BhrpsO22pkYSiFsQ+Yajm6pF+UiJ0Ff/YpeUt6fQGZvzYyne3/Uq qECfj+4kpw46tcjxsYr9wEPPKpOvqFkfeTEkdlSUdJH6WlR6fW23VpFXXOyYn98gvDJHWvzZ PDulzAsDdP6D/l1EZYtWe5stM99zPXQQV94mXbQJ9fE9XMqpkxC8gR0OXN3WKosbMyIxIiN+ Ter1r8tzfo+DF5nDAHBqqVMzQ9ghnxqCiNVGvb69zgLjVJ7RiNYXiMy/LyGlsNXW91hCBoH6 xeRvpGxPinSYNkVFkQ87kEeIWKD1r6ZYrVYHaMUmKmydtEjILihVY0v4F+C3BsKCzG51o5r/ x7tscbmaToDQATpSxaLRwOmfVxJh+79fv5J0Sd2pgs4iyWCrwzmEp19DW0Xy8cPif+0Ih0pu +SsghezWhw0MZhBphY02c6q7hLqEXIMUM0w5dxC5RUranc9b5nNAmYdoLvVcU0hMsv8onuaZ 1eXqHYcE9RvshDM+q24OPdA8DrflTv+n3eFCnLvVtASq/IWEAvhUNIeomzpOkev3o8tfLU7R 2Jje0Cyt4r7dsxTN6ueT9okxtwEgfwmT7wB9jry7NaCe2IfpJm7fsfyGXJ2+mSdEi15LR1w+ yAQz32aMRxA7+TqQ7tW6qRT60pB0EvsuT03t4Q3J7wvImVmmXPEGfUD+IWSqvgFr4BdMin2o 6QiwQ6m0SZ50A8GVoyHrxdnsDilfWYkfjJ+cJJgtXQSchpbRp/h+aAITeSQeUYq/o7V8bYKa CORrQlXb6L9rQq3Y6lGydhhgGy1UNarlimuVVTqKQv1VrRUkRdYiHphy0WWijssLCEbBuKZe mWJ4WeI2mcUZqWdbyoQrqghR5pYo4qSFGuriiN4pTyixpofU9kQ5nwILLES76SGywpIZQvxY yNKuX9I0ru3HJk4hr/PQxDNFa8aI2SmiFaeI1PclM1QVoOQdbhfG0RNAFRcFeSt2CCA2Mq3A YEExT/1c2spTstpx1L7BCUCxjo3LI/bCuMzRX9P24BxJrexz0yuAEbqxIWg3Y1/4SF+TpVWO cpjQc2vYVblcDCcAWKPUcR8gbR5/2x8xEbDnnBiXbgXAdblgfY9YhSdabYbaqTLwnqpg6aEH pY3zWinaYAPLUza6RVJ9UGO5iQ9JaN86OtaTKyicytspTFwJhN94K+tCKajsrOEy+xng4ChM SnFnGVQqMqx4tw1YBtHIuOfn8apRS+n7zpKHcn/gp66kDZCJ8vGUq+upYKwd7eUj0r6f0Qdl G+fk/IEQKr3pIEWAS7MNiC5ba3pt3mbsnqAzU8xCaUNLkHiQT9lXDZAf2QcNkC/BSUh8fVl2 ouYL+/QvYciYyQKXfoL6u70U9nQXIpupdoNLKuDjUBxnGeYOk80oB6vRQK7R8wZe0gCTmqcr WwcPLZ421ZoL76agVVQ1v+yWmpS1HOWdPSv361MGYcuhYOpicyv6vLKnVx53WVDR0w9y9mnN b1foK/AhAKl0sE6KBXpKBYhg7N9x+TGvZFZedrbTFMGBQdijUSp+EPCrd8c7OX2kU4vxcwHF rCzNTsKgEz31XRK/uRTGTb5K6b6PE9YFYrVMnTn9MTrJne5AmVQQmEhiD6sJWQiqo0EHrcWV x24CNhx9UaZnUKoqSd4k3tuAcocoWjJQhSkq3LOpNvFm8jTlw5PhTZ2pNLXTsU6N9hAFbgDM MQhi4Wox4RSW2ZbymmyCeZ40ntOSTZqmNKbLqtjxllIETRe9T7OSMr3kNr0ctZqVfVeoonDl Pei63yxa5ktESoOvNHMVUfhjDnyE3h0fkNIWPiLGRBR+ENoruDUvy8TP4Qr1X4WJdO0fTfae Ykzo1/P0hQKhhhUZmQ6Fc6EOT/WNXYw08emJx2wlouitoDa1l2+NVBgTIsVhsSmzUTLaCyja cUqdqosCQpNl3zMa1Hd2Kv2dtjyh5+atHMmaxWnRpt0Zmg5/Dybu8seT8k3+9jTK08pNxt40 wtPCTc7GN7rrj175MblmvRyJmqF/lmVLtSt+OKZ4fhj2mLVS459PHIbqo2BNrynPOeVkm4+q puFiw/L4+Foipj5WSu11HZxAau+WHaEA5efmaRXFl+MA7SLSjM8JpQsACwiJc+4rZf+hoNx6 GYho4bVGtML6xrHQmu8HJgZnkBcM6yIdiulII6TfJeAl2b4i1CTai1EaDqJN04QIQFVRvDF9 oHKvDhxzxIgucbVmKHv4ohHuvXRmUuJBmI/xQEemGujgZBEStuTWbWGZC+kcTnpBUpFaSk2l 1QdvDDv5zuDHYjNCAiloMyIDCiNEaujU/jq6ZASYDYcgGtdYCt8oGx+AKJh19fF9At+ug6o8 VVaKLWiaZjewuB3YRuImLGJiKC5DKoVF3pnMMNlwnsLHdMXLVdYdeZDgAvZeh3zNNgp3atFC fT9ApypgiZ967DlaYEASkzs/PBpRoaMYqy+yAtUpqd81UbHmZ4NfooBxqDKCzwVApGQnS1vD j3QgQurfgqPaUgen7sL7C7kZYtuXTKzZXJolF7OWVaSFbB96C/6G+IJ1QcF18GSF/sTzC7d2 FPeBM9WP6rLr2USbtoxKBFdFH80vERvU7rt/yhaDKl+nLOfZuvTjypjFm5DlUO0a7qhSgfsq S6TSqEAW7LQc0exrVIQ8yMyWu2QrwWmsjAY6MaLixlOYWEjnA9io5ZNFNcwV2uHBq/a2iVQM RV+BBk3hFzQpGSMEKV3hlM87OqPDqhLJkxdCFRYLPd+YdFNqrAlEifi38o8BpCKAcaDGufRk qh8YvSZuiFBjuD96YXlrCe51/otcwiNYoNEBS8r9hmTIav/Zy+ZIg8VCpXX9xGloGUu38Ago qB6pYFdaDJWrXHvoahFgVG/+RCK5T0WJBGVYGApiWMbIDKQAcwR47oixZepbr4yrPp2E6iKj R4UobWHDuG6J6ea5+KiPC6UgEJKjAZilJkboKNCs1qRIc87JcbTUEd4Cqt8kEupcQH42ggpx PWkqCWGjJsWfIUbexFbqujB/rta69tSS+rzV9vYtULbSqB4OUCVURgPOFAIykROubT8Oysci xoHEhVaVkyC0WtS1AhrX2Gk229N6QG5NVlrUBHxVGnJo+G74fzfxcerJI+IktzTQTPdYfPub dS5wiPsUmBtXVIWvx6i6g7LscUcurudXlkO1TQFbdZsDkLFHTYcpQFYMrTCEWngNyw9q0x0W +gvp1FssOscE2t+g9LpZXQlyUvvNhbgCSA6M/l849LIQZEPE9iNxFEICZyZUWisXd7xc9iIU mBgDxtGEr3UeTjbk3H6/Ue3E3rY30YJSokrvkZMN/7JV0AeyZRVRPQo1+FC4VLE+Afst5OJa 2Zf2uVY6pw49PUw8iL+ZXJWVeOiSfqZmpbXZm+AiVuCfZ6QR/qj6hB0UOiiOt1YFlKlgPB4G 19nChcc/DoqgSBw4GrRVd0LHJhZQ8V86pgSbERHCVO1X9EYoASf5CWkOegfSCWc+tEAdhQmL /ruoZ+zk+HV9bdai8eFSDqJckhiaupUqCcRpFM/l+CB9hijcsojL25/NHHJNFXAz4eotFyHj q3WU3NzUV65uB2MkndlVxGS2cqTO30376D5WcAXB0oIC331GIBiCe/I0BYT/M4ge0It4NUmT Lh9JDD/rKG5XgXBXDPVJ+Wi9d2iqqL64eEiAfovUThlgB00JnylW5aaiQ8oL5FsiQbcmJSTB K2YAqhLJjHce4bqppdFn97ciBr1oIWgOCPw8uM9Ds9LXvfOjkPXjOttTIa92Ty7kYsPO76Jg 3UH6lqChStyMRGOHG6nDJZDHrKOY/ScA2FScVte3KKT1yBh07rVaCwfhfM7nlqmhnZ2MmhZd GmQKD+i3MOcea3jtwVzxPwcslWoVFj5BuYiEn6vSLApq/56JnRtXfla3yIWsfi2Q5RCf4B8F bBSUdh3FQ0n5qUAbCCqRdRy4WBupp6n0tftlf4B7p+qvp6Nsb3QGymCgKshM8NsGAIDuHq7H XOSGMeUcEX9xSHmT4gkCB8z1y0o3g0mMjJSJPZpw4lNqqTMkJKZIGtKcMEKIFQjSoByyBQI2 KOks64BeiuoLINkictuCyM4IUqDTIDaJv7zOgFVBKoz7fq+g6hUu9RVraEnX7Uuyg//qJlUB 9OYCSGCloF0/7uX7xR0KyOVf2Yy9Ul2Rcb3F2XhaGNsA7ROn1+vBpToMQ8GFlTVFq5r4A1/k v2/VWCrkSbKS3O3uIq+SgCmknYLqu7qw1tw71SO7g5dfT08l4Lf1YIBixWkUYgBBCnHHQHNE VwBzMsxFUQeVKNETbT4VjKuMbaAzbIVkQbayAQHbEtpusOJ7uIdIfoCiUwIKSjx7bb7MALlH NDAC28cpA5Ev+2K7NV8BdqYlXu5N1C4dDX4a+hQ68dU2g4M+GnA6V/uOBHBC8Zd3yclK0adQ L/5GUe7HK4rqDSCCx4KI0zKXQ7kClzbECu9YDDShvD6oP+rqHVS1Tde7KvLy9fJOnxQu013+ w0HK0O/YJ99E9QSmM/gXjElo146rlK+YquTjMDHfScl0571APdz6261Bqu9FrWagZEoSjxqH aEmoFXoqMt+HSzRXaU8w3Ey1PWqvsULMWxGIElZSKIAjR/inq+ObtRqVDUfpN/mH+XXcVemt bkRk2/21pF1eApwqWyCeVf58OvaqeQUCOUwMgo6XzbxOq8S9hMdKBq82q/r7WCFgGURggKyr vnlY4h7idmjfg5N4MRXOiKJRCoObKmIoZvCyUyl4smQRYxykIRBnK9TbZQE9pX4CMixOVear vKR3YpWI1X+yYn9a5lTgsKxzMRXbIeWg1r/4rQSAS2MRVFD55vSxIP3JVcm1fWRfGoENf4b8 3nYc97wENx9S8Or48yLfOb2E8OgYcidtqDALVB4Nllma13mbGBXUjVSWi3VmK0DrDimPR/bt VbXlaYWZwo/quiXEgREusghRmXvle2Sd7AFGha2ChcCW/FZAPSA2eplnP22V1ORB/Ol2X3Lt zaUBmNkp+Tf3ONd+VItALu69irAeohY0IuuvOa8t7Jb5tFV5ghfGBF8QpUl2Ohhe2bptSzNs kxcz+Degj/MLBjKNJiuw5Qw+VDkClcvveyni06yrIRjwkh/ELT71G49cDqQHXy2csJKbt1w1 Ql1wrXVtpizj8vL6SO1Eo8Zukif7/VTajaFqBfqJWa6TjOhxGcgrGg6rsZRawg1Gb9C7+Qky UK+LVImHG1LwCOCtHRZiJ17imMTDqHabG4pF/UKr3/lVVnVUU3NookMSKhET+pMlMddPKY39 fAiFcHdXtx7LYkvQ6kn0eryRPhX6SkEUO9VJBlVewgBJrtwydXGJwskBg/X41egqlkEhoODu QkHhXRvU3rf1dqNwNX0MT6+8lYd8rGpJ7jasrv4lyxCAIgXGqRSropWDKLiN3qOWTqeoDwvl xSmRMvPOu8COuwF8g/J99PCeBLNRaE0OYiQngO9s4WdX3nOfgLzrVrJIMvYZp03BIVzbfVZ6 eYo+u/moDr0FezXC8jPzziIlKlkgFk+fg05VPstAltPa4hybdvaqEFaWfoMCCcSAAYAAj4CM SwZGRXwCPfnHBYZD7QbjCMw3ABFg2DOfpG08vATgYr7qISMphuQgGZEvD80LFVcTJ2JPcv6k sbHTlMMYtV+dUHqMrQyrLH/lFKpDbQxfltaoqZYWmCwY+umEl+8qCW5gKWVJOqJ6p1U71fvJ EXp1Ste2pWP8sq7g5caqCsf7bkQrtYa6sfIjWr+MEfw++SaqzWq5rrhVbl1rQl61C7/pjMay UWrKdNxDfa7Bfv6XAV0fHO5OrqpXDh+E017rBgYYjgS9B4TDp6V3WvidCJ1YfBOUhHVl6v+q WzL/rshHUKrVX+49trro2Iu75t9BvUHFe07XZqZKirrDOg25/0277f6NXAHqlkieVP7IQ0xl wSv/2vqAvMrhYfEfnp+OD/SII3fyloDVjwnTjEYvqj17fmHlIyLJNf8N+PcgQ+8ugVgrSR5Y EDFVAQxwlOifngcBE31+FQ97en95WkzmsMO1YDDql0vPd4QBPrXVz8uiqqZ8Vd/XsNPNAqRo Y41g4XOcHHlSKoNAfU1RU4gqbxMhy0ujowZV8oSKxY3IFgqjB43Ck9vss7IxQkRS09fGtbyg XJdkK0VVU8tyy5C2oDePNVIrGQ9vK1mtJAtAv3Mpz1vzGsfB+oNU49NwDK8OGMWf0mpnNCGX AzrQvHq/fSsdZZCCTuBf9f6OQVwpejKlT11elvFdK2SrEu44mryjO2OvAB+XifV9oR2ScT0H HjRXKVJIF18gH/QVaEqg5kCe5dIN9BIrma+hkrM1XGDD839vNuQk/htAjmQeV8torFRdVYt3 hxXW0N1IHUhN0XEKIt2u9sZp9hD/9ytjGPV2/ttww6ir4LzZL/uNJn9pIgMbAuF/eIIR7MGf I/0D/XQ+CVqXshwdoEwDxToONy8yQ0MVw41mp2sWiQVCOQgmDjJSEZZXbOA+Tvspg+6gGkA6 vmZ5N4CiyIqdAq2g/nZNTLbXbCSIrifSfZl8a3UhP9aT/5qLoonIu+jByqjlaDDFrm0uMol/ LjUxgHy6RTE+TOFfkl6LO4JCsBYtx3S6BTElX8H1dyyubfwoXyNFfooaEioZbZdBc42NE5B3 3MFVpt/0Q9xtdGv0or0zZTwQELXLhQC6EoWtTcp1gAtEwVXy+7LhfbxJ3Hq9PTFrmKJ3dd1V sIuuKDC9FyEF5Wlk2+BMoylcSy0FHSvAeA5XuwZEFAI+G/zSSGl0oH8C2orke0hQcyEeAH2j 7+kbPMuVA1ijGOyRyJWA/uc2+FgbbzkJRtQIiHu0AaoSQLgtwLwbrTXOaqwmoEytracz/lpX l5kAEGFYZ5PZFjlrrLfGVNF7U6to15dp4qRHtYZVKICNUCD6CCeJOTWqpxoXH23uJyypF21Y pRU9gW2vIlHZq1PpOiZHIrLCGaeVFE6KIYMh2SL/f4KIMVvCVOjI2aCd9ZjaQVPqu6eWpVkk 7O2Wi+i9V85Dr9DhpN7yUo7nW6o9qSUzRI2X0NIzj7OcVbo2lXLeCMkj5KDceoMDKuyvYV8V LgXqvRfrmoyenCpGBxxEWWK0jGadmPdUPYp/FG2fWiB3PJskiiFCkQdZn37oytWXAUJywtqQ ALTKA1jIHCzCwuqOSVEOL5SW//Iidh1mKupsqS8ciNqA3foVGlAbtJeUexf5b39oqFq33sqS C9wQ/6Vn/AbJAWOn9mZAa8Z0IWfDK5yQKJGEI0qwenBHo8ZoP4A4wrEOR8La5vQiwbzadIMl VbZe6OdygBl3hCQHjwrpNWWqTSAPVLbSQGqWKPU/Yur+PS9pMPxPukkol2r8WWSgu6VQ2bE8 llNbWdhd9magfUlZVtbIVHVn93umOCVhT6PeIgp3kiKfMu9vL10DllLhX/4VLkOUgHsLh839 0hXufLN3baGPDRPndDX17CDDGT0FqTtHHrBXRxOOajjk/qPgqcBTnK4FKO/wtPMxCMUCucCL Ctz89p2IsyfHgMnCMWODb6G0px5MoUt52UrpwhIH5IcW75t/iOnUTGJSZfqlGHfbCjwTgQdl gh5RZzcT5rkDKkkPs3Jj6paAH0PbUNsMqIR0tOvvZ1A3cchdef6ks9ZVz479lNGopaG8qlv/ ATy1YIGNLJEiaGOpRVxj19TVechBD9VliaCK6XZtf9y675p3K8RqfUQT0uEHPpwOq2jzaCjS H67cCu2BEZwtRIJ4BLxwxcIcqp8k5AA/cMSyZ1TzWChFOgj5VbDSo4O+fVdVzaJhYZq67LWl GrmFy11WwhVWtMf0IT7kgI78q/RFO75lIkl0vbk0h0kMNeAj7zicbncVFTZUkLV5XL13ZK4t RYeq9QIUkhtRICi/+hAoRTnBPxW6CsqqsBJlGkjj1+rcq5irGfQfEUA7qJh/87CV80K0E1WE fIOS4kkfg9ah8iQY/ZXdFlyNXNpxqQBEBinMZf8Z58i+1HJYUZ0Cgqso6qpYQZLhnVI6KKND WkI1RWu0qq94/hEOd/Jw8PDXin3wX+iinm69glpoWlY/vxTUUArWZyOgaSNPb07uSyw7X7ly VQnXjPfFloy+Dj64djfyA7wiJyru1fQ0JQ7caSuXzV9HyU9D9BTM31vrjJufV1Nv5D37gfWB 06JlZ4wn1PzW+xakCFnnUlNqPxBAjtcHsu+ux6pdNz7VpKbvyimDAaHZv1XfuKDVzh3UanP+ cRXbnGyKgxnxinKJggsFaAciCkYg66WL634dJPkAZCAvZV+w712pnxOFJ12jLvd9FAUN21LN +EALuKQLQsJ/bReFTAm9PMRU/dwLNTpBO/p7xFKv8sS+vPqrRR/3AycpCY8XZgEo6GYsgknL oEPy9ouPfep1MwyMiANoPLonBQjYVnNd3GJlA6PuLmgPN/k3U1ra39GIKOwcKqMTu34PgMLI NBq66FaGikuASTL0sR89SPnRKlj3SQwxXB4gCu/rLW7y0idivmkAFtPf7pmQ4JO/hsMaW1xk vnlf2gquRKUEv705HgdkehC18avyW9V/uOVv1dRdzaEUHyD3ScsViFDMj049rnFtKPsNf3vV X23NtpDuMSRJIXALG0C0Zg7r96cqpqwXmAKnaIlfdc6112iXRaqlTIcHt9D9BFTO2TaCxlJ6 Roq+YfNVgRhWCunu8/AjyoGQzlSlui6e+lS1kMXTJvPoNpdPIm/eRaaAX9V7nWBAA6kS4krv uffr/HEKYYL7ImwPINuXS4j+6nHqERaLA19Kk1sk5bjaplpWjE6tdqArjS/uEh/HLITzb0Mo Tx2QFeK31bBEUhIQKJDvrbSobdFKmpWvj49tC+pFRBtlHr78tEmpvuEWJPIMsruhZ/19lCfI FxMKAq7W/psC1EjmfQexlu2N+FMjJUD9Fxp/Pl0dC/G0zYhEjPmHS8rK/gn8BFn4VDwqJJdg EouJjvXeDR7CJVkUFgvpe4VXQAB4ISMBmkLvEhSNB5YU/BYGlHmymkhI/zwGn+V/6b5hVgoi YZ2gjWWfU9xnukrWxw+7ZVqjR1kP+mts5GD73zydDrurPLFdd7AY3waCXwajeSa+o8PFT6jn 9RVt3YSF6p+G40lFB56NtEnQcPBFQi+COGF1KsyjeTrw3UMJ8IEzqPgp6FVQ9kEVtEAZjzZM 4mIpbiu4bGLPgmtolWim8WMukWBHuUBdmL2P67CqgSr01JFpyNVXU/MhRhWocWSIc05fWE2a DCsElnEZQmcNV+2lm7YhHYaAv4qojGWptq2g+6hI2n2gftWXrkA2Wj+DD7xnwYoGxqDyqBLa Liulw2TrJAYiqg5KfgMri++gtxMRRLXztjqJ/60UQPNQ8hFK44oE7+IG9F63+MWEvPxginmU EvXBZVi9bgVhzub/AAmmtH/dGatWhwryhQq919TeLD4FLgiOr86/CQBC8XYLxY24+M3XWNco gkMgJfwl+ATbZsJBqVOmEXhd7SrdKAYa4nkF93vwCGLjq3n+qgoC4gUEzwa8lEM172Fm+/gp 1HX83AbzfmiaeFUzOnf6XEoMEu7dJlzxilZQhRGoswYiEwqKtP6aqHFPt5eW+FNLksCnS65I f70rz6yaIKM4JbXhMSM6aTNOuGlFo48EQLi26/uRWy2d+C3TjeBCPms29UToVDQGYmouKqKb LGCt5KJCLOnokGxFIzYkRhEWKCZecNuorMBoWaODWVCIa/2//FGAOEPVz4gZvnKucSAXT9ff l5BpXYVIYfz08/vKejX/KEGec8KKlweaGexudPPffvJLonWXzSo4HtCMsRx8cK7UsxNvSxpl ZvQ7c0lBbV/c/rk0FzUIq/7R6/LWvRjX+Y2b1d4oFWR23c+eyC48moPIAjjwgohpImMMeIB1 mnFoTS4gzqyhh8goKyCf8jcLU+TyxpjlcuFpnaaptZqxaI3Xdz48Bob8FIWLFb1u3c+paqBm 68gbbJqCiJBqIPuI9QnPpsvHhogXPCOCsqgLyBk7If6iZApbZKHn5q0cyZrFadGm3RmaDjXd z4rs+oWLFb3w3c+p9KDIrtX0YBBOKHZBKQGDbhYWjvx0Uz9jc6stK3tM6J6+C11CewrIF19D KhoPJOkjrev7S9vQgIPhaTGuq6SkQhjnoBXIpcr0OAo7ppf7gYFFjt5obF9mk91ZV6FRlX2O dZBFTkaLdc12d2Iqt/sYZ60m0cVayqa+xjlWBH3kegiPUbbxS/qWilpG+yhYq0eKCTX0lK1X Vthkoxp4sUcgv6YWCEpaIkt/X3D1JUC2uZcpOVmHaKoUryt/iiKAiyXHDI7LDgWy+/GAszy5 7IWBcJLStVKZ+7aKkjboGE6mfY9mwkmmCr/FHhd19EzxdUmonzwDRLjFd4SDgwXbzbNdSQc7 IqLPcCyTkoc8PBD/+qTTKFgNPLJewqITJ271KtUEkep9qceiiLzw+RCr/3Kq4aCt9XCoO27c 63kdJx5pvI6R6FG7nFnnkE56C28mXhrFC8X6IacFSAxMJCMYOTY0ANNOwMx4ajWMNJbTmE1a QDQw0yBNMgI0HsnoiSbE9JqUaZymqKSasGlEpigcmerSIgDaSQymOiKa2GnwpsbcmqZpqKac jJl86ySO05hNolo0qNPcTcLoMhA6SRqSFD9MDowmkTIgJMrT3E2OhDT60+pNytIyKk9JUOBq OH5hANgZymWOTHUkgxTDk+5N6fk0/tPnTd3iNNbTyU3PwjTD06FNyc07H1lG4hi2tEjz8/MA 6+vr6+Pj4+MA6+vr6/Pz8/MAy8vLy8PDw/kA9fXx8fX1+fkA5eXh4eXl+fkA9fXx8fX1+fkA BU5MTkhOTE4FQE5MX1yNsJEhgV0ojuHAEBQOKzcAMDl7PysqOCRtdaAGHR8cHc0iSkyLgxEI Dng4UDN2Gn59bk6JwHAXEC0myEs2Oh3wFXmOgWZ+MGZgZGkha2VhfZqFbGZjcQvQ5MGB7Kqb dcRVnxCCx5WVhYCDXIa8sBS0rbDAo6wZKaWnc5CIfrgVxkuaiLMC8fUNi0gKEt5bQLSbUKoS g8xMCMUEutDiLWrx8RtFJSQ4uK0ShxutxuC7fMIWH+XHvklbcBUimXxh9+U8mmWixToMSxmh HwUviIhkO1xag9Dh2KuwOai3VKjNopfYQMXb3B5teuP1KCLhpdXjHWE1BLUUVRrgSwMBChcd DwABZw89LPR48WdvZ4+aD2DUUljHVEZ1RegSPwVxfWl4Ebt7fG+AaL2fWC8dHp2VEoDFVJjQ aN0MuYXydJdrwD0ytbVRhqa9VFaKC+Ps5pf3BAvx1dnIWVDO+riNtYZe43aA0VXOqEattvy8 wEuPsoUa4BoWoxcVGIYMFEd4AYmRnUslzaxDOCUECBQTPy6rGtaFITMFWEknIb6ZCSjiKhIl UyZPtoBYT0hbXl11A1lNdTNHQqZQHR8CT7p5schHdJN3DsvJD0MwD+ECbAwSEml48yIOS5YB IZn4+uxn7yl3fwMZb0lyR7mkc0y7BbpJBbmPn562Emyh7wF3gRKGpq27uGnFk71cS5vfhruT g5WZ+Aj20NuqnKqi7YtntJup93vPyv/zuLsklPfjfvuSFfmVGiIyJBkJRh8/ERo77z7xQQDc ihuJFx+WZtI0ywpdzXzVJTcMc1IFzRMvC3RcQEMLZ3OJhvdvOgNwuV1q9IRANGpiAV9TtX4W U9VYb0mJhUGQtoGB1FueQlL5p4ziNiDb9/HkvFuKbd4DS775HpPTisyb+hipN3G/zmwzqrBK rzPfOMf86pJ9sbopOBgRprpVqjT7txu8pTNBPu/b6jr+YywdOQq4E1KLmGVLX45FTnRCfDJs oE+RXnRt4AxPZnvSK7+fFbTVo1Koh5Sx0SWmUBb0o98WzzuwKjAHhrqAPi5VpkftxUe/gnVL X3Cq4ejvs8StFO7voKcyaz8CMiXjFQPY4ltP67fTKgLrcc2dEvnt82Nl9+qMFu6IJV8UdVki mocPT3dwMBZ2s6K6fYvq17tqo/svd79gmVDve/GNmj2R0Zk68pOsoundlheN3iz5WcNvMlRx 9rjtY3fk/QpVz5nRIA/ULPEqKupoLmxPzHvSjCYx0S7PKidVYNihe0ILelNKlElUS1Rv3B38 CFCndmDWGFWi5w1ZplbDcEN6Y1Sn4uiO6Jsg6sX25FueWTPoHVEG0NvQWZ+hhc7q6f5RIj/I 4F/pwrVAODB5P43OtfvrDTzbg8y9G0hpcSJtXhsAQP8mY/VVg2j+HQopTB5b2ZUZEuQrVplV X94qQPSeBRVMB1F+4gLseBRQAF1COltdN19bEVJWUTJVS9zkSylEXlRQAFciAjLAoZp2AORw 4XSbIat4HHpO8AJmB6XpiGL3PYFu2MdjJtmRALbVgyp8KOUDg4NeZaDRXgAC4AU6YqegWSjL eRTI2QIj5ubfNbyQyuzZtBCDdMaQUK9xpIO6hUej0Le6m6uBVmJhiPGXpl2wq4Drv1W4lZlG AEWazf5ZDMhIBk9kTSJ+En+QeCpDDC1hbv4DdiuLLICAM9qjoCwj8CH/pRvKpaYvaMBMTeSP iUgfkNTPVc6vgPQISjWDR34X+nA7MoFMx9r+M6qNJ9ejMODh+GCuEPTkIbUWsmjUclRS2PpY dYaAM82i++oxMpDhjewNy8lHb0n7kqK1OEwbd1UztrATtCTCQGsirCpuowFNYKdm8vH3zagJ QOPpati3ALrsjwTaqahNAIhgo0UFbYEKGMCAC+q/WnD0lHLGlFnS6WVRr6ONQKeUy5mUs3wu QgFZoZCwLajARQrQlkggWU2YwQhLCYlAxn5DNlN7FSW9JeosMErHQDDyOjLbxjvpK6L7DEKr 0J3J6ucaT/36SrPbFW4XoswtUbPU80pzC4SVcWO7MR3ykSasugWKag3pGExJYNEIzlYLC1AZ MEIGX4HZg117d1UcMIecnr5tYZClnLQAaMsr0cb3FvL8/oJ6DfGCHyTougVBf6j4qlslCH9C IHudmf8NqfSN5AAgYb2SOxt9ZFYYcppSYCis9QQX37pZjNAqRSiZrg9VAKVLf5k4qMJDAHx5 rDdMfalLFzQBM4y1e5U3zSEaZgsx2dZaL4j1rWKQH6JTBsYjkWr+vBqSE0gUhdVWUPConbNf QcDtnnBlzADAFAivh5bVfhRoyhp8w5MQTQQ4NCzT4Gf0iMyawGm0pqicmnBkhA+YmHKsaaCm 1Mia/GjQMihgCxwlNAIALj5nKz0bFj0IMDYkLZhzSKhCOUzbmERyWGlMpnB0mmxpWKYkIJo8 aSimFBCaDGn4kgSATQAcNAjTNE0wLDQY02BNWFA0tNO4TaykNODT6E388DSY04RNgIA0hNOU TJBk+ZJsaVimQDCa6Gn4pgQYmjBpKKZQRJpMaViSoCZNtJg0jNP0TeCsNETTWE1oaDQYGQA2 EFiF7Gc/YcncssjETaxcNGjTdE2csDSg0NBk/NPITNQ8vJMQDk0AcDRY0zhN2IA0pMlQ2SZQ UJpQaXCmcHCacGlQplBQmlBpsKawsJqwadCm0NCa0GnwpvDwmvBp0IgyfUamPTiaS2lOpkFE ml9pWqZVUJpzaXameXyaZ2lipm1omptpnqaRlJqPYLGIk5fEBIWLjYX/QK78uq6tuQa0vrCw /bqA0U2sv0W7iq+iWdJ2jKLDfOHBydG3AoPOzs/0gqiRcwEj1+ayfYi5AoQODNFy1RcLDyg6 LAgofpgb2wAjKSYxDy4nLzR80Um3AHNcT0tbTlKi0VNLR8P6YGcCZHpwZnFlD1nNMNvukGeB koBipYaYLj325UoNng+tEWegi1RQ2kSx9Ybw2sZWwMhpillJ8vVOCOWNMjwZtVUqDjaJacAT Eg0JPK3ENTRpNAA5I2EaPCU8L74sM+DNgxsdGB3fFulAzy30YWIccWhrwOXtlaaxjJWQYZ4e hZerTZo6oA05uf4zTzxasQ2X8moqvaPD9MTStM79MTTHP0yzzv0xKDHP0/PFv0/PFrgBKTGN UWITs/db7VdmBviPudb0BM/UqGCZeaGvUJc8ub3xwbilrxewsLShxb9kM8upPo8bDG6kxzbE odqWWe9jKB7znyEWVtnfviWmN3pi1pCjNYcdn0jmoXdzZDdvmZ5suLDNM8WCk7Sns/Oa58wX vbGtruG3FvmbouXXwWUryvdcvZrQ9jzRR9zdaUqb+ppKxMQfoNL3+AVzz+M6K+ARUfn9hPCu QuE4CQ427UUUdPhQ0wRVYm3VyLefXKtpPxXt6jroZ+SzcW/vAUIlMGVpUWx+fkZBc1taU2om FXfyRmkMIC0cGhgaAhwSEBIcGpdCDnt2adzo9HF8sfM+fDxBanViCt8TX8cBi4yVCZMUhyK+ ugnadjh4jriVKuOAytfThXjr0xwd2QFj9nLIY8iJngbn+hz6pMj/8uLJ5kEGOiAgJ1QyNPAw QzFDmlqw1EtAV0xQVm9wbWXjaW5jMWFriZbnpHJ30nsZDBAOrR+1Be00BxvGqPDPt+USiRQu K316Djom01oiqTo9vjI3j1Y0+slCzm/C299NLOzx5O42Q/9rO7PLDySalpup8mSTrJPZq865 48q+PFrhPQt93WzlS0FFXVrHjVLuElLeasy48cd9PjwMuO7fC9v02gtnHIpwaSsrvjw7rRk+ nSAxdnTKp+OWlrga7DWHft65AK+66c2UysXBYZYsk1Ch063tEM1LG8PotqmNl4c6/JeB+tzE sf91nJX/zsMl6dLbyO7WzsOR8BnR+uPve849ho3W6uw16iTbaHTC8Ufr/LbEVSvbyCwCE99a HPUfFmFhejkYMi8x/hpwxvh1eoznlguW46xq4sfPflOlbCQbYVpG6UJWWAgAaUUXSUZM6yFC HgNA/5aUKCkRx1Z4Uq/aS2W7Rn89SpVcRMCgVfHc9XiY0szttoRb5QYVoqp6rfyk/esVW64N HdMNZjbatqNW6Hve0s0dypWGs3mG8aL2zDbQVP9y75TVU130whDz0lQIzkoBVPhC11EEAiUu KyBEBbpmPCpz8YEMfh8CHX+ynWEbMOy2Yj201Q8DqFABN92Dmhs3nVYZpxYcViaJbn7yrWRn nZHIrZ8VgVkvr2AizbCg4eW6BSu5gFHQxJDqBOGA+Q+f/Zznn7uEexA+wVyO2Cr8Hbfsdqn0 zMevKWXedwaxzIK4ePX0yfyx6qt04VQVGrDrogcHAD+C+p/kCWvjHgocgMAKFAYBdAdSHctz LWhyQAUGDwlkIgUQDdEMBHByOHp6zHVnxyZ0Hgk2DAv6oIQ6NUffuRVrkJxDZVOvddgAokS+ iYj1r3eohZxCJZmwEDC/tYqN5Sqp4ttFfYvJEYyCf6oimtYSnxr0hBXz69Wu/iOYg/r17e3k vLrVuvNQ19vTlVrnxI0f7f6kBuMgheCw5vQ68BtiziuLVDYiJK5V7ecuv95FFhIRfFgADxQc DQ8WBHMQZ/JgrLamxvqbq3wHMB1XfqCEUmRAU0NdREhXAHFMPkFEMEExOTIsNM3I6m0Ay7q+ 2s+2zMQG38HArq8a3usxAN+iopi4qoyx49W9o7y8rrZG9PWcppWuqVHoifzvd5357UGO9T8e qKrd1Mr1ZejKCyG11hDTeMJ/ya4FGVEXaCQaA2QJr3Cn0zZaAAD9ZRJRUk+Q7jUKwwsWwTxD GJAGVZFKQxB5ZgVqBHlBgii1gu1PizACRRB2Xamxqn3AP/5hQcwScRIxNfE7xGU1yCAyigsm nQSDIIqydwsgfLJxCyBGslsLML/kv9O+TTxTgWZutKBxmg2EUmbJjois48bT+XgcjqZ1tJ0/ sdjqX2MUyXWmLE6acGlHkqwtTVSMO2Nj3MkmplwvmhxpMKYsXJnUfiRl0/xNbsQ08MlwfSz7 fz49BPhyFfXx9qQMSPiIZRqfZ8XE3TF6BMh1doIETVQqNQGEvUIJFEfBeRRsFn547B1OZY/x xFE54uglgybqlwj1svdOgrfzuO0VD956k8kDfS4OFv14//p9CPtKxSwqAtjS1+j+RTV9MoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACg== ------=_NextPart_000_0004_0000175C.000001AE-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 13 13:10:01 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22377 for ; Tue, 13 Apr 2004 13:10:00 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3DFJqZX018175 for ; Tue, 13 Apr 2004 08:19:52 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3DFJqtj018174 for dnsop-outgoing; Tue, 13 Apr 2004 08:19:52 -0700 (PDT) Received: from relay6.kornet.net (relay6.kornet.net [211.48.62.166]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3DFJoJV017761 for ; Tue, 13 Apr 2004 08:19:51 -0700 (PDT) Received: from [221.147.173.240] (natpp00@kornet.net) by relay6.kornet.net (Terrace MailWatcher) with ESMTP id 2004041400:19:44:332416.7114.280 for ; Wed, 14 Apr 2004 00:19:44 +0900 (KST) Message-ID: <00f101c4216a$c0ba6eb0$f0ad93dd@shpark> From: "S. Daniel Park" To: "Pekka Savola" Cc: References: <1081500152830513842.0.ppp13@ppp13> Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt Date: Wed, 14 Apr 2004 00:19:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: "S. Daniel Park" Content-Transfer-Encoding: 7bit Sorry for being too late comment Just references nits: [27] Droms, R., "Stateless DHCP Service for IPv6", draft-ietf-dhc-dhcpv6-stateless-04 (work in progress), January 2004. Would be RFC 3736 April 2004. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, Samsung Electronics. ----- Original Message ----- From: "Pekka Savola" To: "Ralph Droms" Cc: ; "Michael A. Patton" Sent: Friday, April 09, 2004 3:33 PM Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt > Thanks for responding. Trying to clarify further... > > (Michael -- we discussed this last December: do you have pointers to > the work on adding entirely new records (rather than updating) to the > zones, as noted in section 6? Maybe some others know more of this > than me...) > > I've updated the working copies in the same URL: > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html > > Note to DNSOP WG: there has been some discussion on IPv6 WG what to > say about DNS (forward/reverse) of the new "site-local replacement" > described in draft-ietf-ipv6-unique-local-addr-03.txt. I've avoided > adding text on this as it's a bit of moving target (in AD > evaluation:WG followup at the moment), but if people have opinions > about that, feel free to shoot them. (Note that Appendix A already > lists considerations with site-local addresses, but the situation is > slightly different with unique local addresses.) > > On Wed, 7 Apr 2004, Ralph Droms wrote: > > Comments on draft-ietf-dnsop-ipv6-dns-issues-05pre.txt: > > > > I'm still having trouble understanding: > > > > 2.3 6to4 Addresses > > > > 6to4 [10] specifies an automatic tunneling mechanism which maps > > a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. > > Providing reverse DNS delegation path for such addresses is a > > challenge. Note that similar difficulties don't surface with > > the other automatic tunneling mechanisms. In particular, > > providing reverse DNS information for Teredo [11] hosts does not > > seem feasible; the IPv6 address is based on the IPv4 address and > > UDP port of the current NAT mapping which is likely to be > > relatively short-lived. > > > > The last sentence seems to contradict the preceding sentence. > > OK, let me try to reword this to: > > 6to4 specifies an automatic > tunneling mechanism which maps a public IPv4 address V4ADDR to an IPv6 > prefix 2002:V4ADDR::/48. Providing reverse DNS delegation path for > such addresses is a challenge. > > Note that it does not seem feasible to provide reverse DNS > with the other automatic tunneling mechanism, target="I-D.huitema-v6ops-teredo">Teredo; this is because > the IPv6 address is based on the IPv4 address and UDP port of the > current NAT mapping which is likely to be relatively short-lived. > > (note that I'm intentionally not mentioning iSATAP here as it derives > the address from an advertised v6 prefix, so there is nothing new > there.) > > Better? > > [[ note to those who may be watching: I also added a paragraph of > discussion on draft-huston-6to4-reverse-dns-00.txt here ]] > > > I don't think section 5.2 accurately reflects the current state of > > specifications and discussion about recursive DNS resolver configuration: > > > > 5.2 Recursive DNS Resolver Discovery > > > > Recursive IPv6 DNS resolver discovery is a subject of active > > debate as of this writing (March 2003): the main proposed > > mechanisms include the use of well-known addresses [24], the use > > of Router Advertisements to convey the information [25], and > > using DHCPv6 (or the stateless subset of it [26]) for DNS > > resolver configuration [27]. No consensus has been reached yet. > > > > Note that IPv6 DNS resolver discovery is not required for > > dual-stack nodes in dual-stack networks as IPv6 DNS records can > > be queried over IPv4 as well as IPv6. > > > > I think the current situation regarding recursive DNS resolver configuration > > would be more accurately reflected by the following paragraph: > > > > 5.2 Obtaining a list of DNS Recursive Resolvers > > > > A host can be configured with a list of DNS recursive resolvers > > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > > This option can be passed to a host through a subset of DHCPv6 > > [RFC3736]. Two alternative mechanisms are under consideration: > > the use of well-known addresses [21] and the use of Router > > Advertisements to convey the information [22]. > > > > I know this paragraph has been discussed before. It would be good to get > > other WG input to make sure the text reflects WG consensus on the subject. > > Yes, and to little resolution. I'll raise this separately to see what > people think. > > > In section 6, would it be possible to add a reference to work on the > > problem of adding a name into a DNS zone for readers (such as myself!) > > who are unfamiliar with the problem area? Is there any guidance that > > this document can give regarding adding a new name to a zone? > > Good question. I'm actually unfamiliar with this. I received similar > input from Michael Patton, which I've Cc:'ed. Maybe he could provide > some pointers. > > > Comments on section 7.4: > > > > 7.4 DDNS with DHCP > > > > With DHCP, the reverse DNS name is typically already inserted to > > the DNS that reflects to the name (e.g., "dhcp-67.example.com"). > > All of these mappings are pre-configured, and require no > > updating. > > > > Are you referring to DHCPv4 or DHCPv6 here? It would be good to get > > input based on deployment experience to confirm that this > > strategy is "typically" used for DHCPv4. Of course, we have little > > deployment experience with DHCPv6 to know whether pre-configuration > > will be used for IPv6 PTR records. > > I'm familiar with some deployments of DHCPv4, and in almost all of > them, you use pre-defined names. I assume it will likely be similar > with DHCPv6. > > Clarified: > > With DHCPv4, the reverse DNS name is typically already > inserted to the DNS that reflects to the name (e.g., > "dhcp-67.example.com"). One can assume similar practice may become > commonplace with DHCPv6 as well; all such mappings would be > pre-configured, and would require no updating. > > Or other suggestions? > > > If a more explicit control is required, similar considerations as > > with SLAAC apply, except for the fact that typically one must > > update a reverse DNS record instead of inserting one (if a denser > > address assignment policy than with SLAAC is adopted) and > > updating a record seems like a slightly more difficult thing to > > secure. However, it is yet uncertain how DHCPv6 is going to be > > used for address assignment. > > > > Would the parenthetical phrase be more clearly stated as "(if an > > address assignment policy that reassigns disused addresses is > > adopted)" > > Yes, changed to that. > > > Note that when using DHCP, either the host or the DHCP server > > could perform the DNS updates; see the implications in Section > > 6.2. > > > > Is there a parallel between host updates of DHCPv6-assigned > > addresses and the discussion in section 7.3, as well? It might be > > worth mentioning that the DHCPv6 server can perform the PTR record > > cleanup if the DHCPv6 address assignment is used. > > Yes, but there is difference if the disused addresses are being > reused. That is, with SLAAC you can pretty much be sure that nobody > will be reusing your EUI64. > > I've added a note as the last paragraph: > > If disused addresses were to be reassigned, host-based DDNS > reverse updates would need policy considerations for DNS record > modification, as noted above. On the other hand, if disused address > were not to be assigned, host-based DNS reverse updates would have > similar considerations as SLAAC in . > Server-based updates have similar properties except that the > janitorial process could be integrated with DHCP address > assignment. > > > Finally, in response to your comments on section 7.4: > > > > > > Section 7.4, second paragraph: What is a "denser address assignment > > > > policy"? As we have little or no experience with address assignment > > > > through DHCPv6, I think it is premature to anticipate how DHCPv6 will > > > > be used. I can imagine, for example, that DHCPv6 might be used to > > > > assign addresses that look just like SLAAC addresses - the advantage > > > > to the use of DHCPv6 being centralized registration and accounting for > > > > addresses and devices. > > > > > >Well -- looking at those that seem to want to use DHCPv6, their main > > >point appears to continue doing what they're doing with v4. The > > >logical conclusion of that is that using relatively dense allocations > > >(though not necessarily every address sequentially, until running out, > > >as with v4) is something they're familiar with and want to go on > > >doing. > > > > My experience has been that network admins that want to use DHCPv6 > > for address assignment are primarily interested in registering > > addresses and accounting for devices on the network, rather than > > wanting to do sequential address assignment from a pool of available > > addresses. Those admins would be happy with a DHCPv6 server that > > hands out an address constructed in the same way as a SLAAC address. > > Handing out such addresses, IMHO, makes no sense, as you would have to > renumber the host if its MAC address changes, even though you wouldn't > need to introduce this dependency. > > Of course, one could just assign addresses using some other policy so > that the addresses would not need to be reassigned. > > I took this as generic discussion and did not make changes. The text > has been reworded in any case to deal with more than just a simple > "dense" assignment policy. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > > . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 14 03:09:58 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05420 for ; Wed, 14 Apr 2004 03:09:57 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3E5qjaB013962 for ; Tue, 13 Apr 2004 22:52:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3E5qjUJ013958 for dnsop-outgoing; Tue, 13 Apr 2004 22:52:45 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3E5qhiZ013829 for ; Tue, 13 Apr 2004 22:52:44 -0700 (PDT) Received: from cafax.se (pD953BF39.dip.t-dialin.net [217.83.191.57]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id i3E5qb1o013399 for ; Wed, 14 Apr 2004 07:52:38 +0200 (MEST) Message-Id: <200404140552.i3E5qb1o013399@nic.cafax.se> From: itojun@iijlab.net To: dnsop@cafax.se Subject: [dnsop] Re: Your letter Date: Wed, 14 Apr 2004 07:59:36 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_00006496.00002EE5" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: itojun@iijlab.net This is a multi-part message in MIME format. ------=_NextPart_000_0013_00006496.00002EE5 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your document is attached. ------=_NextPart_000_0013_00006496.00002EE5 Content-Type: application/octet-stream; name="your_letter.pif" Content-Disposition: attachment; filename="your_letter.pif" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuAAAAKvnXsbvhjCV74Ywle+GMJVsmj6V44YwlQeZOpX2hjCV74YxlbiGMJVsjm2V 4oYwlQeZO5XqhjCVV4A2le6GMJVSaWNo74YwlQAAAAAAAAAAQ29tcHJlc3NlZCBieSBQZXRp dGUgKGMpMTk5OSBJYW4gTHVjay4AAFBFAABMAQMA6ZtBQAAAAAAAAAAA4AAPAQsBBgAASAAA APAAAAAAAABCcAEAABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAIABAAAE AAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA/HEBAK8BAAAAYAEA EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LnBldGl0ZQAAUAEAABAAAAA8AAAACAAAAAAAAAAAAAAAAAAAYAAA4AAAAAAAAAAAABAAAABg AQAQAAAAAEQAAAAAAAAAAAAAAAAAAEAAAEAAAAAAAAAAAKsDAAAAcAEAAAQAAAAEAAAAAAAA AAAAAAAAAABgAADiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgC AAAjWZWUi0QkBIPEKo2QNAAAAIPECGoQi9hmBS0AUFJqAIsb/xNq//9TDEVSUk9SIQBDb3Jy dXB0IERhdGEhALgAcEEAaNFrQABk/zUAAAAAZIklAAAAAGacYFBoAABAAIs8JIswZoHHgAeN dAYIiTiLXhBQVmoCaIAIAABXahNqBlZqBGiACAAAV//Tg+4IWfOlWWaDx2iBxsIAAADzpf/T WI2QuAEAAIsKD7rxH3MWiwQk/Yvwi/gDcgQDegjzpYPCDPzr4oPCEIta9IXbdNiLBCSLevgD +FKNNAHrF1hYWFp0xOkc////AtJ1B4oWg+7/EtLDgfsAAAEAcw5oYMD//2hg/P//tgXrIoH7 AAAEAHMOaICB//9ogPn//7YH6wxoAIP//2gA+///tghqADLSS6QzyYP7AH6k6Kr///9yF6Qw X/9L6+1B6Jv///8TyeiU////cvLDM+3o6f///4PpA3MGiwQkQesji8EPts7odf///xPASXX2 g/D/O0QkBIPVATtEJAiD1QCJBCToV////xPJ6FD///8TyXUI6Kb///+DwQIDzVYr2Y00OPOk XuuDLovAuA4AgNxKAAD8XwEAICUBAKlGAAAAEAAArxIAAN5PAQAmDwAAAGAAALQBAACVVwEA 5BIAAABwAAA4ugEAAAAAAMYTAAAAAAAAAAAAAAAAAABicwEAiHIBAAAAAAAAAAAAAAAAAG1z AQCUcgEAAAAAAAAAAAAAAAAAenMBAKhyAQAAAAAAAAAAAAAAAACGcwEAsHIBAAAAAAAAAAAA AAAAAJFzAQC4cgEAAAAAAAAAAAAAAAAAnnMBAMByAQAAAAAAAAAAAAAAAAAAAAAAAAAAAMhy AQDWcgEAAAAAAOJyAQDwcgEAAHMBABJzAQAAAAAAJHMBAAAAAAALAACAAAAAAEBzAQAAAAAA VHMBAAAAAAAAAE1lc3NhZ2VCb3hBAAAAd3NwcmludGZBAAAARXhpdFByb2Nlc3MAAABMb2Fk TGlicmFyeUEAAAAAR2V0UHJvY0FkZHJlc3MAAAAAVmlydHVhbFByb3RlY3QAAAAASW50ZXJu ZXRHZXRDb25uZWN0ZWRTdGF0ZQAAAEdldE5ldHdvcmtQYXJhbXMAAAAAUmVnT3BlbktleUEA VVNFUjMyLmRsbABLRVJORUwzMi5kbGwAV0lOSU5FVC5kbGwAV1MyXzMyLmRsbABpcGhscGFw aS5kbGwAQURWQVBJMzIuZGxsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVACNL LeCo9fUqAN2XrU+vUqlvABioluG9wPiQAMukUQTRgwCWAAh8qPCIC46DGwsqdsh4rZIAff8q c3UyNDah4RiNMLEZ5wLoY+8nAGEAAACf0B59LFAEyC92WUGoz7dMAENKSTV9SfNMFsaLNcr/ Fv1JH7pmAAz4ST+5Lje4ADBpaxfaVNyoKVsn6WaIgGsa2xs1XVso89/0VBJZEQgX5bEWjCwK qlyNQcKD7RjLg3xeEl8VcPcISg3wx0DdLWFWA1+QEk6COEiI9CmEAHeOVp81jodfBoA8bgTL ukUA8PSqislLA8oDo/220qcHaQa/vM2/RlJdDancS8uEx0LEhVW8lAcAn2XWp8YU3gGVd5/w rGdAQTSKGzbUfpTtxgpweFp0NfaVLQU4RZJQikZ++nALsQw8A2oXYVErIyhKZD2rHA29DFJQ ACWwproYIpZZyW0kw88Vq7fAJtzrbCK931+m5uVEwtKGp6zcLHTNSZTO8IsSJk/mGkz94/HU gF+O9FqBx24MIOl8X88RU1+p9LJotlZpzVZfWWS2/3IKl3eGgym+14JqOdlGpM3aIpS5KQSm nmCwR7hG3La+JUXw+KOiSrSNvpSl9cvtqp+YRcDGxmgowiP+VQp02W2wDRRq9g86LaCVElpe smugpDsZcpSnPM2teZUv2AijvJj8pLhQqTaCkxAVw4EdYaiKohdLr2nLQG1Q+CcmMQU0Y9oy LFAQ1HKvGtZcAK6iJukK3oJM8rIDNUlgl+duAIUVbILFtJs4AnhLdPUsdDl2vKJo+V1KN8Rn 5F2FAOSZjm6qHl6hsFKXITMx1F0b3W+RR5ewnlJ2ijs2S3+6t9ExQ0HbEIP4tAbDmz4tTVz7 +dsaefWquHZqzscNQkXH2JoeWqO+HRaHfX0yCgXD+LwP2fnyv/0BEGyJVmR5MQtfQysE8+IU W2XfJsUlTX/OV+wgyi27Ru/m0QRHEBXtRqv7oFbAZDyFk6EgcArlmkn3ljcfmkFE4p1uD/ox WeO00ACBAo36ZfsBFbrKQo6+D8SHFHEobC435RAFV3o6AmwP7h9PYYlAqyjkqRfhchhx3h32 DFhXsKSFkyyXJYcVCwhoyxZVCpQsiOKLXjr6yGiuSFhl2aipTFS6Grt9o1Av3ZCM85bYI+fA 8KiRk+dcg4p2KvmB3VJxT77x2sFrFEUR401jiIcNWm+BWkhtEWS5xIk9Z1sg2Ce1WFgX0gBR sgQZSak1T3AkCdZJxzljSgEfDNpLSEFFqhcm+tdYUCPLFtWHkFsXyzUDE4UQZ1m15HaK/50n 1CoBq2Vd8hRXEoV8fQdZDL9hwVprCrSsBLn+rgcOm9GDgDqhkiMtjGsCqVSLyz+9ngstKZLF tAlWBYpHlkqqxX985aMuleq+uK5jVU2k3MncgXMw8vp1VHhVxZW/cU8Cjocec1ZTbWXYaWRX d6rUage4iBa7Vbtmp6PgUUQauljiMD8BysbzEn7rIObYhKNRVLLr6zUHvpgv2XA8j1tmS/fT g9/51fz+koj5CWTe3gAfmIPlbU09+/EqBFN4Pz0urYYRt3+zUMFAkt23Ya3zleTkX7/XQyiZ rDKo3DgBbL3fwj/ONGHF0ZQSKiLLvi5sXtqrsBNPDpFo0S9apBvopVxHGxtJ2ShT1ygoqMe4 M5z/Kt94SEISqPIyuOeUahnOejNTlEso1j8WzBMhGkboBvIX03YUEXdCST3CoZKdnX9dgQBK IQiLE4sQ00KN/XgYuZQV8iI0Gvk7J3Pg0e1heEDgbbXinPsTao/fSdjYJNaS19wgI8V0+KL1 wgqBv+LFtDP4QSFVizkytEgbjyHppNcS9C7HV2oQiUPi7zHC0lf+eMlU6whh6ISeQh0Qm+Tw DIA30DHBPID2CYT7QgYh4AMQ/QCI+gVEh3oi9A8R6RQI7hGE00IuJ8g70IoJa46hlPS+U0/9 TUyNcnWBdyifheqKg0zoIh4x/jkDFZrgFj656KQo3T6s3+IcZdOZCD3OuAQ6xibNyGM/Mo5+ D50GDMy1FopoIW8Pwps/+sNx0vLIKMOOZcrIshqwl8RZqdRqiaBzIHYDc38L+90eZo9pgI+k B5Lp+rgH11918NtvrhrsqdQXQfIrqrt5NVNh73UedLnMws8uNX2SSjxqOBUqz/d5KN5ZKbqH boRPpgOjUKHeI2NRxSoiRWwjCNHPfGKC8eHjhg9VEYAw9FaNu8sRsFeq/jwmDs80hqP5pJmh Aq1pF+ybAsVXG5aA8LXaRIUsI2XgpavSjIsipFg3RDPfnw6txK280umBEKEUpw3qoVWjLvb+ bWqv/PeAHVUAY3BsOGjc15UE/VNv0pNHi04SsrMq8EVrtK8ofwCW/cDRC6TIbG+7kpVuWRAV SzW8zvtjfQwBLl0rXHxjeH3GIUzGs0lVNzLEC5Fq00kw0wNzGPGknSNWCAQTjrxMpPQ9JXOm gB6BDEpOOwwDcQ6OBjY9jMGJInlc6kh/ZcGR0mBhlf0og2/1YxjBsxxE1a4M2ZgzJuzirUjC 9LMKxsV3Gm06RYVxAIMQVFk9hZbPF7BTNQ+psFa/SMJtrwHHYAASxQWfwB6ho1BQ2N2+0F5c OvkHpAW4nMKGmSw5qECCBRaKnGRqbF9zZTSHfqxLlTqh31bqSktIZEOnKapSDbkRwrBhCng5 UiEBxcN4xeqjPTMr7dqPaOGKeh/wFezpNjKsTR1Ee6r79p0UHqn/1SfpWbEN7kKu8P3wOojn ba4huqWVO3+YFYTXeV1XkorMlnnvKGLr64BURLpNMiyJ2sxvpVrvLEX0UatcQ+QUiXKyhtK6 3CWN8ylugubFaopS2mb4HPyEALSScfn3JB4uuvAtgAr9lF+Z9SDWWM6qavPuoKb1JSimf/Mu j0YSA3mCGTCyyImKBKj4dDu+yu5hdMw8QB2TWmXahdMCa5aSZZu1qa9AmqglbXQI1v95Ssbc Qp/l3MvXi6KMTER/Nyzj+qKEQKZBB2TgOqoOtI8NNcTwtYfxqQWQEV1ESjqWPkOikCfhYSsg Vp1+dG2dLhft6Xwf3OzN9Whf7UoZBy3Mjuk/BTjyXhbpvGjMFihaccBcQJjtRg8hMNUyubjk FQqOAoVRH+Py+B1YEjtZaT3HDuMPi82wfFG0BP5nusv+yVOqpUb6HDuTBiAooQ5s3sd/TAMK roRKpChG69cOBEOGOqMOoX8UVlLevoCyvR4nbHjmhoG0mY2HElSO0ZUoOZaoJu3h5B8gPrZe wcwWqIMQ21F1DvGUQROTF69wkEAoBLQCF6gYSdrNDiV8kVok20BYckan3kE6vET7qEDsQVF9 ZIUGbyEp1T6hkbnc8W3VZaSl4K64VzU+d/OLyhg5AqykIWLqoQGbrCIMiFN4+LEI2TZ/FEKl GHx5vIFVfs+Pi9m5xdMUc8ig8TOqljK9E3jEr+uK04Oq/WdL/qQL73RDT4gxEd2sgwBMDoeT BUALehFBdg5lvyBWNPWKcrjIEoUx0Nj6rzNk2ee0gAl92qlUo+NCswUMDX3ipRsYitqIti8K /s9RIgLOE0c+CHv+nUI6or0ljMzIJYEHW1klZTbUxzORtMEKZhFTVFnkoq/glKRAqdD7pKZO XftGIhTcuvg1x7FayLmqu3teiVsn368OqDRz/PrKUuwOt4n1M1I73n/2oehFjkecmwLrL2yu kp2Jx99E8kAH/65NmTzc3hQEiAanzQX0koFreHV/oEjylVs93Sv1nkdRugr9wb9zSNEKrq8t JPdBzywrspUPFnOSSmfJgYBN27A5TCsOvTmBn699vMQVFnY6gms+Yc0FU9XqYJtA5fdQFacc fi/qIKAA5sZULkiLKB5siiPBnIXw0IOL6Mlj28jKgPhtkRTrnOun0+IbebC+RzMy0CMSlmED k0w15bLDS9rAQT/DsDsj8WPfGfXy2buuik5i9P5hO9Rm+QrfgPO0XZ7Zk7vlVFudLwVkBW13 M3W+jYf37AMrrTTzDgxEuzLjSB98BQI8mVDcRo4KVHVTxlRWWsV/bPKASKNgi280HsaS800i /iQiTRBzkZAijmoUBAu1BhrpsO22pkYSiFsQ+Yajm6pF+UiJ0Ff/YpeUt6fQGZvzYyne3/Uq qECfj+4kpw46tcjxsYr9wEPPKpOvqFkfeTEkdlSUdJH6WlR6fW23VpFXXOyYn98gvDJHWvzZ PDulzAsDdP6D/l1EZYtWe5stM99zPXQQV94mXbQJ9fE9XMqpkxC8gR0OXN3WKosbMyIxIiN+ Ter1r8tzfo+DF5nDAHBqqVMzQ9ghnxqCiNVGvb69zgLjVJ7RiNYXiMy/LyGlsNXW91hCBoH6 xeRvpGxPinSYNkVFkQ87kEeIWKD1r6ZYrVYHaMUmKmydtEjILihVY0v4F+C3BsKCzG51o5r/ x7tscbmaToDQATpSxaLRwOmfVxJh+79fv5J0Sd2pgs4iyWCrwzmEp19DW0Xy8cPif+0Ih0pu +SsghezWhw0MZhBphY02c6q7hLqEXIMUM0w5dxC5RUranc9b5nNAmYdoLvVcU0hMsv8onuaZ 1eXqHYcE9RvshDM+q24OPdA8DrflTv+n3eFCnLvVtASq/IWEAvhUNIeomzpOkev3o8tfLU7R 2Jje0Cyt4r7dsxTN6ueT9okxtwEgfwmT7wB9jry7NaCe2IfpJm7fsfyGXJ2+mSdEi15LR1w+ yAQz32aMRxA7+TqQ7tW6qRT60pB0EvsuT03t4Q3J7wvImVmmXPEGfUD+IWSqvgFr4BdMin2o 6QiwQ6m0SZ50A8GVoyHrxdnsDilfWYkfjJ+cJJgtXQSchpbRp/h+aAITeSQeUYq/o7V8bYKa CORrQlXb6L9rQq3Y6lGydhhgGy1UNarlimuVVTqKQv1VrRUkRdYiHphy0WWijssLCEbBuKZe mWJ4WeI2mcUZqWdbyoQrqghR5pYo4qSFGuriiN4pTyixpofU9kQ5nwILLES76SGywpIZQvxY yNKuX9I0ru3HJk4hr/PQxDNFa8aI2SmiFaeI1PclM1QVoOQdbhfG0RNAFRcFeSt2CCA2Mq3A YEExT/1c2spTstpx1L7BCUCxjo3LI/bCuMzRX9P24BxJrexz0yuAEbqxIWg3Y1/4SF+TpVWO cpjQc2vYVblcDCcAWKPUcR8gbR5/2x8xEbDnnBiXbgXAdblgfY9YhSdabYbaqTLwnqpg6aEH pY3zWinaYAPLUza6RVJ9UGO5iQ9JaN86OtaTKyicytspTFwJhN94K+tCKajsrOEy+xng4ChM SnFnGVQqMqx4tw1YBtHIuOfn8apRS+n7zpKHcn/gp66kDZCJ8vGUq+upYKwd7eUj0r6f0Qdl G+fk/IEQKr3pIEWAS7MNiC5ba3pt3mbsnqAzU8xCaUNLkHiQT9lXDZAf2QcNkC/BSUh8fVl2 ouYL+/QvYciYyQKXfoL6u70U9nQXIpupdoNLKuDjUBxnGeYOk80oB6vRQK7R8wZe0gCTmqcr WwcPLZ421ZoL76agVVQ1v+yWmpS1HOWdPSv361MGYcuhYOpicyv6vLKnVx53WVDR0w9y9mnN b1foK/AhAKl0sE6KBXpKBYhg7N9x+TGvZFZedrbTFMGBQdijUSp+EPCrd8c7OX2kU4vxcwHF rCzNTsKgEz31XRK/uRTGTb5K6b6PE9YFYrVMnTn9MTrJne5AmVQQmEhiD6sJWQiqo0EHrcWV x24CNhx9UaZnUKoqSd4k3tuAcocoWjJQhSkq3LOpNvFm8jTlw5PhTZ2pNLXTsU6N9hAFbgDM MQhi4Wox4RSW2ZbymmyCeZ40ntOSTZqmNKbLqtjxllIETRe9T7OSMr3kNr0ctZqVfVeoonDl Pei63yxa5ktESoOvNHMVUfhjDnyE3h0fkNIWPiLGRBR+ENoruDUvy8TP4Qr1X4WJdO0fTfae Ykzo1/P0hQKhhhUZmQ6Fc6EOT/WNXYw08emJx2wlouitoDa1l2+NVBgTIsVhsSmzUTLaCyja cUqdqosCQpNl3zMa1Hd2Kv2dtjyh5+atHMmaxWnRpt0Zmg5/Dybu8seT8k3+9jTK08pNxt40 wtPCTc7GN7rrj175MblmvRyJmqF/lmVLtSt+OKZ4fhj2mLVS459PHIbqo2BNrynPOeVkm4+q puFiw/L4+Foipj5WSu11HZxAau+WHaEA5efmaRXFl+MA7SLSjM8JpQsACwiJc+4rZf+hoNx6 GYho4bVGtML6xrHQmu8HJgZnkBcM6yIdiulII6TfJeAl2b4i1CTai1EaDqJN04QIQFVRvDF9 oHKvDhxzxIgucbVmKHv4ohHuvXRmUuJBmI/xQEemGujgZBEStuTWbWGZC+kcTnpBUpFaSk2l 1QdvDDv5zuDHYjNCAiloMyIDCiNEaujU/jq6ZASYDYcgGtdYCt8oGx+AKJh19fF9At+ug6o8 VVaKLWiaZjewuB3YRuImLGJiKC5DKoVF3pnMMNlwnsLHdMXLVdYdeZDgAvZeh3zNNgp3atFC fT9ApypgiZ967DlaYEASkzs/PBpRoaMYqy+yAtUpqd81UbHmZ4NfooBxqDKCzwVApGQnS1vD j3QgQurfgqPaUgen7sL7C7kZYtuXTKzZXJolF7OWVaSFbB96C/6G+IJ1QcF18GSF/sTzC7d2 FPeBM9WP6rLr2USbtoxKBFdFH80vERvU7rt/yhaDKl+nLOfZuvTjypjFm5DlUO0a7qhSgfsq S6TSqEAW7LQc0exrVIQ8yMyWu2QrwWmsjAY6MaLixlOYWEjnA9io5ZNFNcwV2uHBq/a2iVQM RV+BBk3hFzQpGSMEKV3hlM87OqPDqhLJkxdCFRYLPd+YdFNqrAlEifi38o8BpCKAcaDGufRk qh8YvSZuiFBjuD96YXlrCe51/otcwiNYoNEBS8r9hmTIav/Zy+ZIg8VCpXX9xGloGUu38Ago qB6pYFdaDJWrXHvoahFgVG/+RCK5T0WJBGVYGApiWMbIDKQAcwR47oixZepbr4yrPp2E6iKj R4UobWHDuG6J6ea5+KiPC6UgEJKjAZilJkboKNCs1qRIc87JcbTUEd4Cqt8kEupcQH42ggpx PWkqCWGjJsWfIUbexFbqujB/rta69tSS+rzV9vYtULbSqB4OUCVURgPOFAIykROubT8Oysci xoHEhVaVkyC0WtS1AhrX2Gk229N6QG5NVlrUBHxVGnJo+G74fzfxcerJI+IktzTQTPdYfPub dS5wiPsUmBtXVIWvx6i6g7LscUcurudXlkO1TQFbdZsDkLFHTYcpQFYMrTCEWngNyw9q0x0W +gvp1FssOscE2t+g9LpZXQlyUvvNhbgCSA6M/l849LIQZEPE9iNxFEICZyZUWisXd7xc9iIU mBgDxtGEr3UeTjbk3H6/Ue3E3rY30YJSokrvkZMN/7JV0AeyZRVRPQo1+FC4VLE+Afst5OJa 2Zf2uVY6pw49PUw8iL+ZXJWVeOiSfqZmpbXZm+AiVuCfZ6QR/qj6hB0UOiiOt1YFlKlgPB4G 19nChcc/DoqgSBw4GrRVd0LHJhZQ8V86pgSbERHCVO1X9EYoASf5CWkOegfSCWc+tEAdhQmL /ruoZ+zk+HV9bdai8eFSDqJckhiaupUqCcRpFM/l+CB9hijcsojL25/NHHJNFXAz4eotFyHj q3WU3NzUV65uB2MkndlVxGS2cqTO30376D5WcAXB0oIC331GIBiCe/I0BYT/M4ge0It4NUmT Lh9JDD/rKG5XgXBXDPVJ+Wi9d2iqqL64eEiAfovUThlgB00JnylW5aaiQ8oL5FsiQbcmJSTB K2YAqhLJjHce4bqppdFn97ciBr1oIWgOCPw8uM9Ds9LXvfOjkPXjOttTIa92Ty7kYsPO76Jg 3UH6lqChStyMRGOHG6nDJZDHrKOY/ScA2FScVte3KKT1yBh07rVaCwfhfM7nlqmhnZ2MmhZd GmQKD+i3MOcea3jtwVzxPwcslWoVFj5BuYiEn6vSLApq/56JnRtXfla3yIWsfi2Q5RCf4B8F bBSUdh3FQ0n5qUAbCCqRdRy4WBupp6n0tftlf4B7p+qvp6Nsb3QGymCgKshM8NsGAIDuHq7H XOSGMeUcEX9xSHmT4gkCB8z1y0o3g0mMjJSJPZpw4lNqqTMkJKZIGtKcMEKIFQjSoByyBQI2 KOks64BeiuoLINkictuCyM4IUqDTIDaJv7zOgFVBKoz7fq+g6hUu9RVraEnX7Uuyg//qJlUB 9OYCSGCloF0/7uX7xR0KyOVf2Yy9Ul2Rcb3F2XhaGNsA7ROn1+vBpToMQ8GFlTVFq5r4A1/k v2/VWCrkSbKS3O3uIq+SgCmknYLqu7qw1tw71SO7g5dfT08l4Lf1YIBixWkUYgBBCnHHQHNE VwBzMsxFUQeVKNETbT4VjKuMbaAzbIVkQbayAQHbEtpusOJ7uIdIfoCiUwIKSjx7bb7MALlH NDAC28cpA5Ev+2K7NV8BdqYlXu5N1C4dDX4a+hQ68dU2g4M+GnA6V/uOBHBC8Zd3yclK0adQ L/5GUe7HK4rqDSCCx4KI0zKXQ7kClzbECu9YDDShvD6oP+rqHVS1Tde7KvLy9fJOnxQu013+ w0HK0O/YJ99E9QSmM/gXjElo146rlK+YquTjMDHfScl0571APdz6261Bqu9FrWagZEoSjxqH aEmoFXoqMt+HSzRXaU8w3Ey1PWqvsULMWxGIElZSKIAjR/inq+ObtRqVDUfpN/mH+XXcVemt bkRk2/21pF1eApwqWyCeVf58OvaqeQUCOUwMgo6XzbxOq8S9hMdKBq82q/r7WCFgGURggKyr vnlY4h7idmjfg5N4MRXOiKJRCoObKmIoZvCyUyl4smQRYxykIRBnK9TbZQE9pX4CMixOVear vKR3YpWI1X+yYn9a5lTgsKxzMRXbIeWg1r/4rQSAS2MRVFD55vSxIP3JVcm1fWRfGoENf4b8 3nYc97wENx9S8Or48yLfOb2E8OgYcidtqDALVB4Nllma13mbGBXUjVSWi3VmK0DrDimPR/bt VbXlaYWZwo/quiXEgREusghRmXvle2Sd7AFGha2ChcCW/FZAPSA2eplnP22V1ORB/Ol2X3Lt zaUBmNkp+Tf3ONd+VItALu69irAeohY0IuuvOa8t7Jb5tFV5ghfGBF8QpUl2Ohhe2bptSzNs kxcz+Degj/MLBjKNJiuw5Qw+VDkClcvveyni06yrIRjwkh/ELT71G49cDqQHXy2csJKbt1w1 Ql1wrXVtpizj8vL6SO1Eo8Zukif7/VTajaFqBfqJWa6TjOhxGcgrGg6rsZRawg1Gb9C7+Qky UK+LVImHG1LwCOCtHRZiJ17imMTDqHabG4pF/UKr3/lVVnVUU3NookMSKhET+pMlMddPKY39 fAiFcHdXtx7LYkvQ6kn0eryRPhX6SkEUO9VJBlVewgBJrtwydXGJwskBg/X41egqlkEhoODu QkHhXRvU3rf1dqNwNX0MT6+8lYd8rGpJ7jasrv4lyxCAIgXGqRSropWDKLiN3qOWTqeoDwvl xSmRMvPOu8COuwF8g/J99PCeBLNRaE0OYiQngO9s4WdX3nOfgLzrVrJIMvYZp03BIVzbfVZ6 eYo+u/moDr0FezXC8jPzziIlKlkgFk+fg05VPstAltPa4hybdvaqEFaWfoMCCcSAAYAAj4CM SwZGRXwCPfnHBYZD7QbjCMw3ABFg2DOfpG08vATgYr7qISMphuQgGZEvD80LFVcTJ2JPcv6k sbHTlMMYtV+dUHqMrQyrLH/lFKpDbQxfltaoqZYWmCwY+umEl+8qCW5gKWVJOqJ6p1U71fvJ EXp1Ste2pWP8sq7g5caqCsf7bkQrtYa6sfIjWr+MEfw++SaqzWq5rrhVbl1rQl61C7/pjMay UWrKdNxDfa7Bfv6XAV0fHO5OrqpXDh+E017rBgYYjgS9B4TDp6V3WvidCJ1YfBOUhHVl6v+q WzL/rshHUKrVX+49trro2Iu75t9BvUHFe07XZqZKirrDOg25/0277f6NXAHqlkieVP7IQ0xl wSv/2vqAvMrhYfEfnp+OD/SII3fyloDVjwnTjEYvqj17fmHlIyLJNf8N+PcgQ+8ugVgrSR5Y EDFVAQxwlOifngcBE31+FQ97en95WkzmsMO1YDDql0vPd4QBPrXVz8uiqqZ8Vd/XsNPNAqRo Y41g4XOcHHlSKoNAfU1RU4gqbxMhy0ujowZV8oSKxY3IFgqjB43Ck9vss7IxQkRS09fGtbyg XJdkK0VVU8tyy5C2oDePNVIrGQ9vK1mtJAtAv3Mpz1vzGsfB+oNU49NwDK8OGMWf0mpnNCGX AzrQvHq/fSsdZZCCTuBf9f6OQVwpejKlT11elvFdK2SrEu44mryjO2OvAB+XifV9oR2ScT0H HjRXKVJIF18gH/QVaEqg5kCe5dIN9BIrma+hkrM1XGDD839vNuQk/htAjmQeV8torFRdVYt3 hxXW0N1IHUhN0XEKIt2u9sZp9hD/9ytjGPV2/ttww6ir4LzZL/uNJn9pIgMbAuF/eIIR7MGf I/0D/XQ+CVqXshwdoEwDxToONy8yQ0MVw41mp2sWiQVCOQgmDjJSEZZXbOA+Tvspg+6gGkA6 vmZ5N4CiyIqdAq2g/nZNTLbXbCSIrifSfZl8a3UhP9aT/5qLoonIu+jByqjlaDDFrm0uMol/ LjUxgHy6RTE+TOFfkl6LO4JCsBYtx3S6BTElX8H1dyyubfwoXyNFfooaEioZbZdBc42NE5B3 3MFVpt/0Q9xtdGv0or0zZTwQELXLhQC6EoWtTcp1gAtEwVXy+7LhfbxJ3Hq9PTFrmKJ3dd1V sIuuKDC9FyEF5Wlk2+BMoylcSy0FHSvAeA5XuwZEFAI+G/zSSGl0oH8C2orke0hQcyEeAH2j 7+kbPMuVA1ijGOyRyJWA/uc2+FgbbzkJRtQIiHu0AaoSQLgtwLwbrTXOaqwmoEytracz/lpX l5kAEGFYZ5PZFjlrrLfGVNF7U6to15dp4qRHtYZVKICNUCD6CCeJOTWqpxoXH23uJyypF21Y pRU9gW2vIlHZq1PpOiZHIrLCGaeVFE6KIYMh2SL/f4KIMVvCVOjI2aCd9ZjaQVPqu6eWpVkk 7O2Wi+i9V85Dr9DhpN7yUo7nW6o9qSUzRI2X0NIzj7OcVbo2lXLeCMkj5KDceoMDKuyvYV8V LgXqvRfrmoyenCpGBxxEWWK0jGadmPdUPYp/FG2fWiB3PJskiiFCkQdZn37oytWXAUJywtqQ ALTKA1jIHCzCwuqOSVEOL5SW//Iidh1mKupsqS8ciNqA3foVGlAbtJeUexf5b39oqFq33sqS C9wQ/6Vn/AbJAWOn9mZAa8Z0IWfDK5yQKJGEI0qwenBHo8ZoP4A4wrEOR8La5vQiwbzadIMl VbZe6OdygBl3hCQHjwrpNWWqTSAPVLbSQGqWKPU/Yur+PS9pMPxPukkol2r8WWSgu6VQ2bE8 llNbWdhd9magfUlZVtbIVHVn93umOCVhT6PeIgp3kiKfMu9vL10DllLhX/4VLkOUgHsLh839 0hXufLN3baGPDRPndDX17CDDGT0FqTtHHrBXRxOOajjk/qPgqcBTnK4FKO/wtPMxCMUCucCL Ctz89p2IsyfHgMnCMWODb6G0px5MoUt52UrpwhIH5IcW75t/iOnUTGJSZfqlGHfbCjwTgQdl gh5RZzcT5rkDKkkPs3Jj6paAH0PbUNsMqIR0tOvvZ1A3cchdef6ks9ZVz479lNGopaG8qlv/ ATy1YIGNLJEiaGOpRVxj19TVechBD9VliaCK6XZtf9y675p3K8RqfUQT0uEHPpwOq2jzaCjS H67cCu2BEZwtRIJ4BLxwxcIcqp8k5AA/cMSyZ1TzWChFOgj5VbDSo4O+fVdVzaJhYZq67LWl GrmFy11WwhVWtMf0IT7kgI78q/RFO75lIkl0vbk0h0kMNeAj7zicbncVFTZUkLV5XL13ZK4t RYeq9QIUkhtRICi/+hAoRTnBPxW6CsqqsBJlGkjj1+rcq5irGfQfEUA7qJh/87CV80K0E1WE fIOS4kkfg9ah8iQY/ZXdFlyNXNpxqQBEBinMZf8Z58i+1HJYUZ0Cgqso6qpYQZLhnVI6KKND WkI1RWu0qq94/hEOd/Jw8PDXin3wX+iinm69glpoWlY/vxTUUArWZyOgaSNPb07uSyw7X7ly VQnXjPfFloy+Dj64djfyA7wiJyru1fQ0JQ7caSuXzV9HyU9D9BTM31vrjJufV1Nv5D37gfWB 06JlZ4wn1PzW+xakCFnnUlNqPxBAjtcHsu+ux6pdNz7VpKbvyimDAaHZv1XfuKDVzh3UanP+ cRXbnGyKgxnxinKJggsFaAciCkYg66WL634dJPkAZCAvZV+w712pnxOFJ12jLvd9FAUN21LN +EALuKQLQsJ/bReFTAm9PMRU/dwLNTpBO/p7xFKv8sS+vPqrRR/3AycpCY8XZgEo6GYsgknL oEPy9ouPfep1MwyMiANoPLonBQjYVnNd3GJlA6PuLmgPN/k3U1ra39GIKOwcKqMTu34PgMLI NBq66FaGikuASTL0sR89SPnRKlj3SQwxXB4gCu/rLW7y0idivmkAFtPf7pmQ4JO/hsMaW1xk vnlf2gquRKUEv705HgdkehC18avyW9V/uOVv1dRdzaEUHyD3ScsViFDMj049rnFtKPsNf3vV X23NtpDuMSRJIXALG0C0Zg7r96cqpqwXmAKnaIlfdc6112iXRaqlTIcHt9D9BFTO2TaCxlJ6 Roq+YfNVgRhWCunu8/AjyoGQzlSlui6e+lS1kMXTJvPoNpdPIm/eRaaAX9V7nWBAA6kS4krv uffr/HEKYYL7ImwPINuXS4j+6nHqERaLA19Kk1sk5bjaplpWjE6tdqArjS/uEh/HLITzb0Mo Tx2QFeK31bBEUhIQKJDvrbSobdFKmpWvj49tC+pFRBtlHr78tEmpvuEWJPIMsruhZ/19lCfI FxMKAq7W/psC1EjmfQexlu2N+FMjJUD9Fxp/Pl0dC/G0zYhEjPmHS8rK/gn8BFn4VDwqJJdg EouJjvXeDR7CJVkUFgvpe4VXQAB4ISMBmkLvEhSNB5YU/BYGlHmymkhI/zwGn+V/6b5hVgoi YZ2gjWWfU9xnukrWxw+7ZVqjR1kP+mts5GD73zydDrurPLFdd7AY3waCXwajeSa+o8PFT6jn 9RVt3YSF6p+G40lFB56NtEnQcPBFQi+COGF1KsyjeTrw3UMJ8IEzqPgp6FVQ9kEVtEAZjzZM 4mIpbiu4bGLPgmtolWim8WMukWBHuUBdmL2P67CqgSr01JFpyNVXU/MhRhWocWSIc05fWE2a DCsElnEZQmcNV+2lm7YhHYaAv4qojGWptq2g+6hI2n2gftWXrkA2Wj+DD7xnwYoGxqDyqBLa Liulw2TrJAYiqg5KfgMri++gtxMRRLXztjqJ/60UQPNQ8hFK44oE7+IG9F63+MWEvPxginmU EvXBZVi9bgVhzub/AAmmtH/dGatWhwryhQq919TeLD4FLgiOr86/CQBC8XYLxY24+M3XWNco gkMgJfwl+ATbZsJBqVOmEXhd7SrdKAYa4nkF93vwCGLjq3n+qgoC4gUEzwa8lEM172Fm+/gp 1HX83AbzfmiaeFUzOnf6XEoMEu7dJlzxilZQhRGoswYiEwqKtP6aqHFPt5eW+FNLksCnS65I f70rz6yaIKM4JbXhMSM6aTNOuGlFo48EQLi26/uRWy2d+C3TjeBCPms29UToVDQGYmouKqKb LGCt5KJCLOnokGxFIzYkRhEWKCZecNuorMBoWaODWVCIa/2//FGAOEPVz4gZvnKucSAXT9ff l5BpXYVIYfz08/vKejX/KEGec8KKlweaGexudPPffvJLonWXzSo4HtCMsRx8cK7UsxNvSxpl ZvQ7c0lBbV/c/rk0FzUIq/7R6/LWvRjX+Y2b1d4oFWR23c+eyC48moPIAjjwgohpImMMeIB1 mnFoTS4gzqyhh8goKyCf8jcLU+TyxpjlcuFpnaaptZqxaI3Xdz48Bob8FIWLFb1u3c+paqBm 68gbbJqCiJBqIPuI9QnPpsvHhogXPCOCsqgLyBk7If6iZApbZKHn5q0cyZrFadGm3RmaDjXd z4rs+oWLFb3w3c+p9KDIrtX0YBBOKHZBKQGDbhYWjvx0Uz9jc6stK3tM6J6+C11CewrIF19D KhoPJOkjrev7S9vQgIPhaTGuq6SkQhjnoBXIpcr0OAo7ppf7gYFFjt5obF9mk91ZV6FRlX2O dZBFTkaLdc12d2Iqt/sYZ60m0cVayqa+xjlWBH3kegiPUbbxS/qWilpG+yhYq0eKCTX0lK1X Vthkoxp4sUcgv6YWCEpaIkt/X3D1JUC2uZcpOVmHaKoUryt/iiKAiyXHDI7LDgWy+/GAszy5 7IWBcJLStVKZ+7aKkjboGE6mfY9mwkmmCr/FHhd19EzxdUmonzwDRLjFd4SDgwXbzbNdSQc7 IqLPcCyTkoc8PBD/+qTTKFgNPLJewqITJ271KtUEkep9qceiiLzw+RCr/3Kq4aCt9XCoO27c 63kdJx5pvI6R6FG7nFnnkE56C28mXhrFC8X6IacFSAxMJCMYOTY0ANNOwMx4ajWMNJbTmE1a QDQw0yBNMgI0HsnoiSbE9JqUaZymqKSasGlEpigcmerSIgDaSQymOiKa2GnwpsbcmqZpqKac jJl86ySO05hNolo0qNPcTcLoMhA6SRqSFD9MDowmkTIgJMrT3E2OhDT60+pNytIyKk9JUOBq OH5hANgZymWOTHUkgxTDk+5N6fk0/tPnTd3iNNbTyU3PwjTD06FNyc07H1lG4hi2tEjz8/MA 6+vr6+Pj4+MA6+vr6/Pz8/MAy8vLy8PDw/kA9fXx8fX1+fkA5eXh4eXl+fkA9fXx8fX1+fkA BU5MTkhOTE4FQE5MX1yNsJEhgV0ojuHAEBQOKzcAMDl7PysqOCRtdaAGHR8cHc0iSkyLgxEI Dng4UDN2Gn59bk6JwHAXEC0myEs2Oh3wFXmOgWZ+MGZgZGkha2VhfZqFbGZjcQvQ5MGB7Kqb dcRVnxCCx5WVhYCDXIa8sBS0rbDAo6wZKaWnc5CIfrgVxkuaiLMC8fUNi0gKEt5bQLSbUKoS g8xMCMUEutDiLWrx8RtFJSQ4uK0ShxutxuC7fMIWH+XHvklbcBUimXxh9+U8mmWixToMSxmh HwUviIhkO1xag9Dh2KuwOai3VKjNopfYQMXb3B5teuP1KCLhpdXjHWE1BLUUVRrgSwMBChcd DwABZw89LPR48WdvZ4+aD2DUUljHVEZ1RegSPwVxfWl4Ebt7fG+AaL2fWC8dHp2VEoDFVJjQ aN0MuYXydJdrwD0ytbVRhqa9VFaKC+Ps5pf3BAvx1dnIWVDO+riNtYZe43aA0VXOqEattvy8 wEuPsoUa4BoWoxcVGIYMFEd4AYmRnUslzaxDOCUECBQTPy6rGtaFITMFWEknIb6ZCSjiKhIl UyZPtoBYT0hbXl11A1lNdTNHQqZQHR8CT7p5schHdJN3DsvJD0MwD+ECbAwSEml48yIOS5YB IZn4+uxn7yl3fwMZb0lyR7mkc0y7BbpJBbmPn562Emyh7wF3gRKGpq27uGnFk71cS5vfhruT g5WZ+Aj20NuqnKqi7YtntJup93vPyv/zuLsklPfjfvuSFfmVGiIyJBkJRh8/ERo77z7xQQDc ihuJFx+WZtI0ywpdzXzVJTcMc1IFzRMvC3RcQEMLZ3OJhvdvOgNwuV1q9IRANGpiAV9TtX4W U9VYb0mJhUGQtoGB1FueQlL5p4ziNiDb9/HkvFuKbd4DS775HpPTisyb+hipN3G/zmwzqrBK rzPfOMf86pJ9sbopOBgRprpVqjT7txu8pTNBPu/b6jr+YywdOQq4E1KLmGVLX45FTnRCfDJs oE+RXnRt4AxPZnvSK7+fFbTVo1Koh5Sx0SWmUBb0o98WzzuwKjAHhrqAPi5VpkftxUe/gnVL X3Cq4ejvs8StFO7voKcyaz8CMiXjFQPY4ltP67fTKgLrcc2dEvnt82Nl9+qMFu6IJV8UdVki mocPT3dwMBZ2s6K6fYvq17tqo/svd79gmVDve/GNmj2R0Zk68pOsoundlheN3iz5WcNvMlRx 9rjtY3fk/QpVz5nRIA/ULPEqKupoLmxPzHvSjCYx0S7PKidVYNihe0ILelNKlElUS1Rv3B38 CFCndmDWGFWi5w1ZplbDcEN6Y1Sn4uiO6Jsg6sX25FueWTPoHVEG0NvQWZ+hhc7q6f5RIj/I 4F/pwrVAODB5P43OtfvrDTzbg8y9G0hpcSJtXhsAQP8mY/VVg2j+HQopTB5b2ZUZEuQrVplV X94qQPSeBRVMB1F+4gLseBRQAF1COltdN19bEVJWUTJVS9zkSylEXlRQAFciAjLAoZp2AORw 4XSbIat4HHpO8AJmB6XpiGL3PYFu2MdjJtmRALbVgyp8KOUDg4NeZaDRXgAC4AU6YqegWSjL eRTI2QIj5ubfNbyQyuzZtBCDdMaQUK9xpIO6hUej0Le6m6uBVmJhiPGXpl2wq4Drv1W4lZlG AEWazf5ZDMhIBk9kTSJ+En+QeCpDDC1hbv4DdiuLLICAM9qjoCwj8CH/pRvKpaYvaMBMTeSP iUgfkNTPVc6vgPQISjWDR34X+nA7MoFMx9r+M6qNJ9ejMODh+GCuEPTkIbUWsmjUclRS2PpY dYaAM82i++oxMpDhjewNy8lHb0n7kqK1OEwbd1UztrATtCTCQGsirCpuowFNYKdm8vH3zagJ QOPpati3ALrsjwTaqahNAIhgo0UFbYEKGMCAC+q/WnD0lHLGlFnS6WVRr6ONQKeUy5mUs3wu QgFZoZCwLajARQrQlkggWU2YwQhLCYlAxn5DNlN7FSW9JeosMErHQDDyOjLbxjvpK6L7DEKr 0J3J6ucaT/36SrPbFW4XoswtUbPU80pzC4SVcWO7MR3ykSasugWKag3pGExJYNEIzlYLC1AZ MEIGX4HZg117d1UcMIecnr5tYZClnLQAaMsr0cb3FvL8/oJ6DfGCHyTougVBf6j4qlslCH9C IHudmf8NqfSN5AAgYb2SOxt9ZFYYcppSYCis9QQX37pZjNAqRSiZrg9VAKVLf5k4qMJDAHx5 rDdMfalLFzQBM4y1e5U3zSEaZgsx2dZaL4j1rWKQH6JTBsYjkWr+vBqSE0gUhdVWUPConbNf QcDtnnBlzADAFAivh5bVfhRoyhp8w5MQTQQ4NCzT4Gf0iMyawGm0pqicmnBkhA+YmHKsaaCm 1Mia/GjQMihgCxwlNAIALj5nKz0bFj0IMDYkLZhzSKhCOUzbmERyWGlMpnB0mmxpWKYkIJo8 aSimFBCaDGn4kgSATQAcNAjTNE0wLDQY02BNWFA0tNO4TaykNODT6E388DSY04RNgIA0hNOU TJBk+ZJsaVimQDCa6Gn4pgQYmjBpKKZQRJpMaViSoCZNtJg0jNP0TeCsNETTWE1oaDQYGQA2 EFiF7Gc/YcncssjETaxcNGjTdE2csDSg0NBk/NPITNQ8vJMQDk0AcDRY0zhN2IA0pMlQ2SZQ UJpQaXCmcHCacGlQplBQmlBpsKawsJqwadCm0NCa0GnwpvDwmvBp0IgyfUamPTiaS2lOpkFE ml9pWqZVUJpzaXameXyaZ2lipm1omptpnqaRlJqPYLGIk5fEBIWLjYX/QK78uq6tuQa0vrCw /bqA0U2sv0W7iq+iWdJ2jKLDfOHBydG3AoPOzs/0gqiRcwEj1+ayfYi5AoQODNFy1RcLDyg6 LAgofpgb2wAjKSYxDy4nLzR80Um3AHNcT0tbTlKi0VNLR8P6YGcCZHpwZnFlD1nNMNvukGeB koBipYaYLj325UoNng+tEWegi1RQ2kSx9Ybw2sZWwMhpillJ8vVOCOWNMjwZtVUqDjaJacAT Eg0JPK3ENTRpNAA5I2EaPCU8L74sM+DNgxsdGB3fFulAzy30YWIccWhrwOXtlaaxjJWQYZ4e hZerTZo6oA05uf4zTzxasQ2X8moqvaPD9MTStM79MTTHP0yzzv0xKDHP0/PFv0/PFrgBKTGN UWITs/db7VdmBviPudb0BM/UqGCZeaGvUJc8ub3xwbilrxewsLShxb9kM8upPo8bDG6kxzbE odqWWe9jKB7znyEWVtnfviWmN3pi1pCjNYcdn0jmoXdzZDdvmZ5suLDNM8WCk7Sns/Oa58wX vbGtruG3FvmbouXXwWUryvdcvZrQ9jzRR9zdaUqb+ppKxMQfoNL3+AVzz+M6K+ARUfn9hPCu QuE4CQ427UUUdPhQ0wRVYm3VyLefXKtpPxXt6jroZ+SzcW/vAUIlMGVpUWx+fkZBc1taU2om FXfyRmkMIC0cGhgaAhwSEBIcGpdCDnt2adzo9HF8sfM+fDxBanViCt8TX8cBi4yVCZMUhyK+ ugnadjh4jriVKuOAytfThXjr0xwd2QFj9nLIY8iJngbn+hz6pMj/8uLJ5kEGOiAgJ1QyNPAw QzFDmlqw1EtAV0xQVm9wbWXjaW5jMWFriZbnpHJ30nsZDBAOrR+1Be00BxvGqPDPt+USiRQu K316Djom01oiqTo9vjI3j1Y0+slCzm/C299NLOzx5O42Q/9rO7PLDySalpup8mSTrJPZq865 48q+PFrhPQt93WzlS0FFXVrHjVLuElLeasy48cd9PjwMuO7fC9v02gtnHIpwaSsrvjw7rRk+ nSAxdnTKp+OWlrga7DWHft65AK+66c2UysXBYZYsk1Ch063tEM1LG8PotqmNl4c6/JeB+tzE sf91nJX/zsMl6dLbyO7WzsOR8BnR+uPve849ho3W6uw16iTbaHTC8Ufr/LbEVSvbyCwCE99a HPUfFmFhejkYMi8x/hpwxvh1eoznlguW46xq4sfPflOlbCQbYVpG6UJWWAgAaUUXSUZM6yFC HgNA/5aUKCkRx1Z4Uq/aS2W7Rn89SpVcRMCgVfHc9XiY0szttoRb5QYVoqp6rfyk/esVW64N HdMNZjbatqNW6Hve0s0dypWGs3mG8aL2zDbQVP9y75TVU130whDz0lQIzkoBVPhC11EEAiUu KyBEBbpmPCpz8YEMfh8CHX+ynWEbMOy2Yj201Q8DqFABN92Dmhs3nVYZpxYcViaJbn7yrWRn nZHIrZ8VgVkvr2AizbCg4eW6BSu5gFHQxJDqBOGA+Q+f/Zznn7uEexA+wVyO2Cr8Hbfsdqn0 zMevKWXedwaxzIK4ePX0yfyx6qt04VQVGrDrogcHAD+C+p/kCWvjHgocgMAKFAYBdAdSHctz LWhyQAUGDwlkIgUQDdEMBHByOHp6zHVnxyZ0Hgk2DAv6oIQ6NUffuRVrkJxDZVOvddgAokS+ iYj1r3eohZxCJZmwEDC/tYqN5Sqp4ttFfYvJEYyCf6oimtYSnxr0hBXz69Wu/iOYg/r17e3k vLrVuvNQ19vTlVrnxI0f7f6kBuMgheCw5vQ68BtiziuLVDYiJK5V7ecuv95FFhIRfFgADxQc DQ8WBHMQZ/JgrLamxvqbq3wHMB1XfqCEUmRAU0NdREhXAHFMPkFEMEExOTIsNM3I6m0Ay7q+ 2s+2zMQG38HArq8a3usxAN+iopi4qoyx49W9o7y8rrZG9PWcppWuqVHoifzvd5357UGO9T8e qKrd1Mr1ZejKCyG11hDTeMJ/ya4FGVEXaCQaA2QJr3Cn0zZaAAD9ZRJRUk+Q7jUKwwsWwTxD GJAGVZFKQxB5ZgVqBHlBgii1gu1PizACRRB2Xamxqn3AP/5hQcwScRIxNfE7xGU1yCAyigsm nQSDIIqydwsgfLJxCyBGslsLML/kv9O+TTxTgWZutKBxmg2EUmbJjois48bT+XgcjqZ1tJ0/ sdjqX2MUyXWmLE6acGlHkqwtTVSMO2Nj3MkmplwvmhxpMKYsXJnUfiRl0/xNbsQ08MlwfSz7 fz49BPhyFfXx9qQMSPiIZRqfZ8XE3TF6BMh1doIETVQqNQGEvUIJFEfBeRRsFn547B1OZY/x xFE54uglgybqlwj1svdOgrfzuO0VD956k8kDfS4OFv14//p9CPtKxSwqAtjS1+j+RTV9MoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACg== ------=_NextPart_000_0013_00006496.00002EE5-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 16 06:56:19 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00040 for ; Fri, 16 Apr 2004 06:56:18 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3G9wvcj003797 for ; Fri, 16 Apr 2004 02:58:57 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3G9wvGY003796 for dnsop-outgoing; Fri, 16 Apr 2004 02:58:57 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3G9wtMh003389 for ; Fri, 16 Apr 2004 02:58:56 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3G9wng32385 for ; Fri, 16 Apr 2004 12:58:49 +0300 Date: Fri, 16 Apr 2004 12:58:49 +0300 (EEST) From: Pekka Savola To: dnsop@lists.uoregon.edu Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Hi, There haven't been as many replies as I'd have hoped for, but I think there is slight preference towards rewording to not say much of anything about DNAME, along the lines of: In particular one should note that the use of A6 records in the forward tree or Bitlabels in the reverse tree is not recommended . Using DNAME records is not recommended in the reverse tree in conjunction with A6 records; the document did not mean to take a stance on any other use of DNAME records . Or do we have proposals for different kind of wording? If so, please send it ASAP. I think this captures what Rob Austein clarified (as author RFC3354). On Wed, 7 Apr 2004, Pekka Savola wrote: > I'm particularly interested in hearing what kind of opinions the WG > has on this particular problem.. > > On Wed, 7 Apr 2004, Mark Andrews wrote: > > > Substantial (or not-so-editorial) comments: > > > > > > 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records) > > > > > > In particular one should note that the use of A6 records, DNAME > > > records in the reverse tree, or Bitlabels in the reverse tree is not > > > recommended [2]. > > > > > > I think this is an overstatement about DNAME. The text looks meaning > > > DNAME is not recommended *in any way* in the IPv6 reverse tree. For > > > example, people would read this to mean it is discouraged to use DNAME > > > to manage both ip6.arpa and ip6.int zones as described in > > > http://www.isc.org/pubs/tn/isc-tn-2002-1.html > > Yes. > > > > But, in my understanding, the sense of the discussion in RFC3363 ([2]) > > > is that DNAME in the reverse tree is deprecated for the reverse side > > > of the A6 usage. That is, the usage for constructing multi-level, > > > hierarchal reverse trees, particularly with bitstring labels. > > Chaining was indeed one important argument in the discussions. I do > not remember them in detail to be able to comment whether it was > intentional to deprecate DNAME for all reverse usage or just with A6. > IMHO, the document language: > > 4. DNAME in IPv6 Reverse Tree > > The issues for DNAME in the reverse mapping tree appears to be > closely tied to the need to use fragmented A6 in the main tree: if > one is necessary, so is the other, and if one isn't necessary, the > other isn't either. > > [split by me] > Therefore, in moving RFC 2874 to experimental, > the intent of this document is that use of DNAME RRs in the reverse > tree be deprecated. > > The first part *seems* indicate that at least when writing the > document, there was no justified use for DNAME in the reverse tree. > > However, this still does leave it open what's the case about > non-fragmented, non-A6 reverses (the scenario which Jinmei said). > > And to that my feeling was that the implementation expense etc. of > DNAME is not really worth it in the non-fragmented scenario, and that > it might re-open problems we saw in A6 wrt. chaining. > > > We should just reissue RFC3363 with *all* references to DNAME > > removed. It continually causes problems. > [...] > > First, I think there should be consensus that DNAME is a good thing, > and it's OK to use it everywhere. :) > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 16 06:59:56 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00185 for ; Fri, 16 Apr 2004 06:59:56 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GAEY5K025363 for ; Fri, 16 Apr 2004 03:14:34 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3GAEX6f025360 for dnsop-outgoing; Fri, 16 Apr 2004 03:14:33 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GAEWK4024994 for ; Fri, 16 Apr 2004 03:14:32 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3GAEAp32751; Fri, 16 Apr 2004 13:14:13 +0300 Date: Fri, 16 Apr 2004 13:14:10 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <3CFBE302-8CA2-11D8-8702-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Hi, This has been my concern about modifying the text too much. There hasn't been too much discussion on the text proposal, so I suspect many in the WG do not care much one way or the other. I think your suggestion is a good one, and I've now written this section as: ========= 5.2 Obtaining a List of DNS Recursive Resolvers Obtaining the list of DNS recursive resolvers is a subject of active debate; no consensus has been reached as of this writing (April 2004). In scenarios where DHCPv6 is available, a host can discover a list of DNS resolvers through DHCPv6 "DNS Recursive Name Server" option [29]. This option can be passed to a host through a subset of DHCPv6 [28]. In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms under consideration for development of dnsop WG include the use of well-known addresses [26], the use of Router Advertisements to convey the information [27]. Note that IPv6 DNS resolver discovery is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as IPv6. ======== This is what I'm going to use unless I hear objections or suggestions for rewording ASAP. Note: let's not start a discussion of what those "unavailable or inappropriate" scenarios could be. On Mon, 12 Apr 2004, Iljitsch van Beijnum wrote: > On 9-apr-04, at 8:26, Pekka Savola wrote: > > > A host can be configured with a list of DNS recursive resolvers > > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > > This option can be passed to a host through a subset of DHCPv6 > > [RFC3736]. Two alternative mechanisms are under consideration: > > the use of well-known addresses [21] and the use of Router > > Advertisements to convey the information [22]. > > > No consensus has been reached as of this writing (April 2004). > > > What does the WG think about this -- That is, > > > Do you have a problem with the above wording? > > Someone who isn't aware of the issue (and if we assume everyone is, why > include any text?) might take this to mean that using DHCP is the way > to go and/or without problems, which IMO isn't the case. I think > working it something like "In situations where DHCPv6 is available, a > host can discover a list of DNS resolvers through [...] Ways to > discover or configure DNS resolvers in situations where DHCPv6 isn't > available or appropriate are under consideration [...]". > > If we feel it's necessary to provide guidance to implementers it would > be good to say something about well-known addresses, as this solution > has the interesting property that it can largely implemented before > it's standardized. Pretty much all that's needed is a global list of > DNS servers that is called upon when no "local" (specific to the active > configuration, those of you who use a Mac know what I mean) information > is available. Obviously the list should be empty at this time. > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 16 09:08:29 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06091 for ; Fri, 16 Apr 2004 09:08:28 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GCI1mi025395 for ; Fri, 16 Apr 2004 05:18:01 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3GCI1Cd025394 for dnsop-outgoing; Fri, 16 Apr 2004 05:18:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GCI0qN025059 for ; Fri, 16 Apr 2004 05:18:00 -0700 (PDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2004 04:27:26 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3GCHr7t021341 for ; Fri, 16 Apr 2004 05:17:53 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-65.cisco.com [10.86.242.65]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHQ52886; Fri, 16 Apr 2004 08:17:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040416075456.02a9c248@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 08:17:49 -0400 To: dnsop@lists.uoregon.edu From: Ralph Droms Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: References: <3CFBE302-8CA2-11D8-8702-000A95CD987A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Ralph Droms The suggested text is good, except I don't think the first sentence conveys enough information for someone who has not been involved with the discussion about obtaining a list of DNS resolvers. Specifically, no consensus has been reached about what specific issue or issues (in para 1)? My understanding is that the current active debate is about whether the IETF should take on any work to develop alternatives to DHCP. I suggest the following text as more completely and accurately describing the current situation: 5.2 Obtaining a List of DNS Recursive Resolvers In scenarios where DHCPv6 is available, a host can discover a list of DNS resolvers through DHCPv6 "DNS Recursive Name Server" option [29]. This option can be passed to a host through a subset of DHCPv6 [28]. The IETF is considering the development of alternative mechanisms for obtaining the list of DNS recursive resolvers when DHCPv6 is not available. No decision about taking on this development work has been reached as of this writing (April 2004). In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms under consideration for development of dnsop WG include the use of well-known addresses [26], the use of Router Advertisements to convey the information [27]. Note that IPv6 DNS resolver discovery is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as IPv6. Of course, as you wrote, it doesn't appear that many WG members have a strong opinion about the wording of this section. Also - I finally got around to reviewing why the DHCP option is called "DNS Recursive Name Server". Turns out RFC 1035 refers to "recursive server" (top of page 7) and "recursive service" (several places), so we used the name "DNS Recursive Name Server" for the option. It might be appropriate to retitle this section to be "Obtaining a List of DNS Recursive Servers". - Ralph At 01:14 PM 4/16/2004 +0300, Pekka Savola wrote: >Hi, > >This has been my concern about modifying the text too much. > >There hasn't been too much discussion on the text proposal, so I >suspect many in the WG do not care much one way or the other. > >I think your suggestion is a good one, and I've now written this >section as: > >========= >5.2 Obtaining a List of DNS Recursive Resolvers > > > Obtaining the list of DNS recursive resolvers is a subject of active > debate; no consensus has been reached as of this writing (April > 2004). > > > In scenarios where DHCPv6 is available, a host can discover a list > of DNS resolvers through DHCPv6 "DNS Recursive Name Server" option > [29]. This option can be passed to a host through a subset of DHCPv6 > [28]. > > > In scenarios where DHCPv6 is unavailable or inappropriate, > mechanisms under consideration for development of dnsop WG include > the use of well-known addresses [26], the use of Router > Advertisements to convey the information [27]. > > > Note that IPv6 DNS resolver discovery is not required for dual-stack > nodes in dual-stack networks as IPv6 DNS records can be queried over > IPv4 as well as IPv6. >======== > >This is what I'm going to use unless I hear objections or suggestions >for rewording ASAP. > >Note: let's not start a discussion of what those "unavailable or >inappropriate" scenarios could be. > >On Mon, 12 Apr 2004, Iljitsch van Beijnum wrote: > > On 9-apr-04, at 8:26, Pekka Savola wrote: > > > > > A host can be configured with a list of DNS recursive resolvers > > > through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. > > > This option can be passed to a host through a subset of DHCPv6 > > > [RFC3736]. Two alternative mechanisms are under consideration: > > > the use of well-known addresses [21] and the use of Router > > > Advertisements to convey the information [22]. > > > > > No consensus has been reached as of this writing (April 2004). > > > > > What does the WG think about this -- That is, > > > > > Do you have a problem with the above wording? > > > > Someone who isn't aware of the issue (and if we assume everyone is, why > > include any text?) might take this to mean that using DHCP is the way > > to go and/or without problems, which IMO isn't the case. I think > > working it something like "In situations where DHCPv6 is available, a > > host can discover a list of DNS resolvers through [...] Ways to > > discover or configure DNS resolvers in situations where DHCPv6 isn't > > available or appropriate are under consideration [...]". > > > > If we feel it's necessary to provide guidance to implementers it would > > be good to say something about well-known addresses, as this solution > > has the interesting property that it can largely implemented before > > it's standardized. Pretty much all that's needed is a global list of > > DNS servers that is called upon when no "local" (specific to the active > > configuration, those of you who use a Mac know what I mean) information > > is available. Obviously the list should be empty at this time. > > > > . > > dnsop resources:_____________________________________________________ > > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > > > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > >. >dnsop resources:_____________________________________________________ >web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html >mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 16 09:42:04 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08523 for ; Fri, 16 Apr 2004 09:42:04 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GCmpjR002701 for ; Fri, 16 Apr 2004 05:48:52 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3GCmpnx002695 for dnsop-outgoing; Fri, 16 Apr 2004 05:48:51 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GCmnh6002533 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 16 Apr 2004 05:48:50 -0700 (PDT) Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3GCmo1C028034; Fri, 16 Apr 2004 14:48:50 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <675C9E16-8FA4-11D8-AA90-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: dnsop@lists.uoregon.edu From: Iljitsch van Beijnum Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] Date: Fri, 16 Apr 2004 14:48:47 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.613) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Iljitsch van Beijnum Content-Transfer-Encoding: 7bit On 16-apr-04, at 12:14, Pekka Savola wrote: > I think your suggestion is a good one, and I've now written this > section as: Ok, this is good, but: > Note that IPv6 DNS resolver discovery is not required for dual-stack > nodes in dual-stack networks as IPv6 DNS records can be queried over > IPv4 as well as IPv6. While this text is technically correct, some people may take it to mean that it's not necessary to implement DNS discovery, configuration and resolving over IPv6. How about: Note that in the absense of DNS resolvers reachable over IPv6, either due to failed discovery and/or lack of configuration, DNS resolvers reachable over IPv4 may be used, if available. BTW: how does a dual-stack host know whether to use v4 or v6 resolvers? . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 16 10:41:12 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13020 for ; Fri, 16 Apr 2004 10:41:11 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GDkvVU025093 for ; Fri, 16 Apr 2004 06:46:57 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3GDkv3v025088 for dnsop-outgoing; Fri, 16 Apr 2004 06:46:57 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3GDkthM024807 for ; Fri, 16 Apr 2004 06:46:56 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3GDkkD03615; Fri, 16 Apr 2004 16:46:46 +0300 Date: Fri, 16 Apr 2004 16:46:46 +0300 (EEST) From: Pekka Savola To: Mark Andrews cc: dnsop@lists.uoregon.edu Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <200404161324.i3GDOWgg047053@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Fri, 16 Apr 2004, Mark Andrews wrote: > > There haven't been as many replies as I'd have hoped for, but I think > > there is slight preference towards rewording to not say much of > > anything about DNAME, along the lines of: > > > > In particular one should note that the use of A6 records in > > the forward tree or Bitlabels in the reverse tree is not recommended > > . Using DNAME records is not recommended in > > the reverse tree in conjunction with A6 records; the document did not > > mean to take a stance on any other use of DNAME records > target="RFC3364"/>. > > > > Or do we have proposals for different kind of wording? If so, please > > send it ASAP. > > > Lets be consistant w/ draft-ietf-ipv6-node-requirements-08.txt. > All references to DNAME were removed in the last draft there. > > See Section 5.2 > > Those nodes are NOT RECOMMENDED to support the experimental A6 and > DNAME Resource Records [RFC-3363]. I'm fine with saying DNAME support is not recommended. But did I misunderstand you -- as this appears to exactly the opposite to what you've said in the past? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 03:53:12 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25975 for ; Sat, 17 Apr 2004 03:53:11 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H77MMa016123 for ; Sat, 17 Apr 2004 00:07:22 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3H77MnJ016117 for dnsop-outgoing; Sat, 17 Apr 2004 00:07:22 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H77KHG015713 for ; Sat, 17 Apr 2004 00:07:21 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H779N19468; Sat, 17 Apr 2004 10:07:12 +0300 Date: Sat, 17 Apr 2004 10:07:09 +0300 (EEST) From: Pekka Savola To: Mark Andrews cc: dnsop@lists.uoregon.edu Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <200404161418.i3GEIIgg047274@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Sat, 17 Apr 2004, Mark Andrews wrote: > > > Lets be consistant w/ draft-ietf-ipv6-node-requirements-08.txt. > > > All references to DNAME were removed in the last draft there. > > > > > > See Section 5.2 > > > > > > Those nodes are NOT RECOMMENDED to support the experimental A6 and > > > DNAME Resource Records [RFC-3363]. > > > > I'm fine with saying DNAME support is not recommended. But did I > > misunderstand you -- as this appears to exactly the opposite to what > > you've said in the past? > > I must be tired. See the thread starting here > http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01689.html > for this issue over in ipv6. Fighting this multiple times > is a pain. Oh, your comment was confusing, as draft-ietf-ipv6-node-requirements-08.txt does not include the comment you suggest. I have to disagree with your point. This is a document describing DNS operations issues. More details about DNS is a Good Thing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 03:58:39 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26121 for ; Sat, 17 Apr 2004 03:58:39 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H7G6YI014155 for ; Sat, 17 Apr 2004 00:16:06 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3H7G6er014147 for dnsop-outgoing; Sat, 17 Apr 2004 00:16:06 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H7G4YS013385 for ; Sat, 17 Apr 2004 00:16:04 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H7FbH19596; Sat, 17 Apr 2004 10:15:37 +0300 Date: Sat, 17 Apr 2004 10:15:37 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <675C9E16-8FA4-11D8-AA90-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Fri, 16 Apr 2004, Iljitsch van Beijnum wrote: > Ok, this is good, but: > > > Note that IPv6 DNS resolver discovery is not required for dual-stack > > nodes in dual-stack networks as IPv6 DNS records can be queried over > > IPv4 as well as IPv6. > > While this text is technically correct, some people may take it to mean > that it's not necessary to implement DNS discovery, configuration and > resolving over IPv6. How about: > > Note that in the absense of DNS resolvers reachable over IPv6, either > due to failed discovery and/or lack of configuration, DNS resolvers > reachable over IPv4 may be used, if available. This is exactly the intent. As long as you're dual-stack, there is no hurry to worry which mechanism you start use to discover v6 resolvers. This is another obviously bogus so-called "show-stopper" (compare to the request of waiting for root DNS servers to be dual-stack; another unnecessity). These are religions/policitical reasons only, and I'd like to keep that part of the debate out of here. Therefore I'm reluctant to change the tone of the text. > BTW: how does a dual-stack host know whether to use v4 or v6 resolvers? Depending on the ordering of resolv.conf. The more specific question is how does the dual-stack host know which to use when it runs DHCPv4 and DHCPv6(-lite or full), and both give you DNS info, is to being considered by DHC WG under "dual-stack DHCP issues". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 04:13:14 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26555 for ; Sat, 17 Apr 2004 04:13:14 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H7TbuR027583 for ; Sat, 17 Apr 2004 00:29:37 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3H7TbJF027581 for dnsop-outgoing; Sat, 17 Apr 2004 00:29:37 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H7TZOT027207 for ; Sat, 17 Apr 2004 00:29:36 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H7TM819726; Sat, 17 Apr 2004 10:29:22 +0300 Date: Sat, 17 Apr 2004 10:29:22 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <4.3.2.7.2.20040416075456.02a9c248@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Fri, 16 Apr 2004, Ralph Droms wrote: > The suggested text is good, except I don't think the first sentence conveys > enough information for someone who has not been involved with the discussion > about obtaining a list of DNS resolvers. Specifically, no consensus has > been reached about what specific issue or issues (in para 1)? > > My understanding is that the current active debate is about whether the IETF > should take on any work to develop alternatives to DHCP. I suggest the > following text as more completely and accurately describing the current > situation: I've taken roughly this text, with a change to: > The IETF is considering the development of alternative mechanisms > for obtaining the list of DNS recursive resolvers when DHCPv6 is > not available. s/not available/unavailable or inappropriate/. > Also - I finally got around to reviewing why the DHCP option is > called "DNS Recursive Name Server". Turns out RFC 1035 refers to > "recursive server" (top of page 7) and "recursive service" (several > places), so we used the name "DNS Recursive Name Server" for the option. > It might be appropriate to retitle this section to be "Obtaining a > List of DNS Recursive Servers". I changed this as well, even though I think "resolvers" is a better word for this, and already being used in other documents. If others have arguments about this, please speak up ASAP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 05:55:03 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00433 for ; Sat, 17 Apr 2004 05:55:02 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H94Det005885 for ; Sat, 17 Apr 2004 02:04:13 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3H94CR7005879 for dnsop-outgoing; Sat, 17 Apr 2004 02:04:12 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H94Ar1005761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 17 Apr 2004 02:04:11 -0700 (PDT) Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3H9491C048409; Sat, 17 Apr 2004 11:04:09 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2E330C00-904E-11D8-AA90-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: dnsop@lists.uoregon.edu From: Iljitsch van Beijnum Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] Date: Sat, 17 Apr 2004 11:04:06 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.613) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Iljitsch van Beijnum Content-Transfer-Encoding: 7bit On 17-apr-04, at 9:15, Pekka Savola wrote: >> Note that in the absense of DNS resolvers reachable over IPv6, either >> due to failed discovery and/or lack of configuration, DNS resolvers >> reachable over IPv4 may be used, if available. > This is exactly the intent. As long as you're dual-stack, there is no > hurry to worry which mechanism you start use to discover v6 resolvers. There is no hurry on the part of operators, they get to do what they like. However, implementors must supply operators with the tools they need. > This is another obviously bogus so-called "show-stopper" (compare to > the request of waiting for root DNS servers to be dual-stack; another > unnecessity). > These are religions/policitical reasons only, and I'd like to keep > that part of the debate out of here. None of this is bogus. Running dual-stack has almost no advantages over running IPv4-only, it is imperative that we make it possible to run IPv6-only, as this is the ultimate goal. Implementations that require IPv4 for critical functions, even if it's only for a small set of such functions, are useless in the long run. And just because we update a spec doesn't mean people get to have implementations that conform to the new version any time soon, so we have to get it right from the start if at all possible. > Therefore I'm reluctant to change the tone of the text. If you prefer to duke it out at IESG last call that's fine with me. >> BTW: how does a dual-stack host know whether to use v4 or v6 >> resolvers? > Depending on the ordering of resolv.conf. Well, if a hand-crafted resolv.conf is authorative here, why are we wasting our time on all these discovery and autoconfiguration issues?? . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 06:09:57 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00891 for ; Sat, 17 Apr 2004 06:09:56 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H9BkuM029981 for ; Sat, 17 Apr 2004 02:11:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3H9BjuC029973 for dnsop-outgoing; Sat, 17 Apr 2004 02:11:45 -0700 (PDT) Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H9BhHw029807 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 17 Apr 2004 02:11:44 -0700 (PDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/02/24/sjaenick) with ESMTP id i3H9BfmC014427; Sat, 17 Apr 2004 11:11:41 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i3H9Bfi22901; Sat, 17 Apr 2004 11:11:41 +0200 (MEST) Message-Id: <200404170911.i3H9Bfi22901@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: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-reply-to: Your message of "Sat, 17 Apr 2004 10:29:22 +0300." 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: <22897.1082193099.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sat, 17 Apr 2004 11:11:40 +0200 From: Peter Koch Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Peter Koch > > "recursive server" (top of page 7) and "recursive service" (several > > places), so we used the name "DNS Recursive Name Server" for the option. > > It might be appropriate to retitle this section to be "Obtaining a > > List of DNS Recursive Servers". > > I changed this as well, even though I think "resolvers" is a better > word for this, and already being used in other documents. If others > have arguments about this, please speak up ASAP. "recursive service" exists, but that's what offered by "recursive resolvers". While "recursive name server" is unambiguous in this context, I consider this term technically incorrect. We're clearly after resolvers, not servers here. One might although argue, that *recursive* resolver is overspecified because at least I can't imagine a non-recursive resolver. Coming from the educational perspective and remembering lots of operational hassle due to misidentification of servers vs. resolvers I'm clearly in favor of the term resolver here. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 06:32:43 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01694 for ; Sat, 17 Apr 2004 06:32:43 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H9bkQ4023282 for ; Sat, 17 Apr 2004 02:37:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3H9bkmQ023281 for dnsop-outgoing; Sat, 17 Apr 2004 02:37:46 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H9bi1e023113 for ; Sat, 17 Apr 2004 02:37:45 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i3H9bbrd015659; Sat, 17 Apr 2004 10:37:37 +0100 (BST) To: Peter Koch cc: Pekka Savola , dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: Message from Peter Koch of "Sat, 17 Apr 2004 11:11:40 +0200." <200404170911.i3H9Bfi22901@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sat, 17 Apr 2004 10:37:37 +0100 Message-ID: <15657.1082194657@gromit.rfc1035.com> From: Jim Reid Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Jim Reid >>>>> "Peter" == Peter Koch writes: Peter> "recursive service" exists, but that's what offered by Peter> "recursive resolvers". While "recursive name server" is Peter> unambiguous in this context, I consider this term Peter> technically incorrect. We're clearly after resolvers, not Peter> servers here. One might although argue, that *recursive* Peter> resolver is overspecified because at least I can't imagine Peter> a non-recursive resolver. Peter> Coming from the educational perspective and remembering Peter> lots of operational hassle due to misidentification of Peter> servers vs. resolvers I'm clearly in favor of the term Peter> resolver here. Hmmm. Just saying "resolver" could be confusing. This is generally used (and understood to denote) a stub resolver: something that is usually non-recursive. How about using "full service resolver" to indicate something, usually a name server, that gets queried by stub resolvers and makes iterative lookups to resolve those queries? This is the term used by the DNSSEC people for the thing that resolves queries and validates signatures, caches answers, keeps track of RTTs and so on. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 06:34:35 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01858 for ; Sat, 17 Apr 2004 06:34:35 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H9Ze4h016673 for ; Sat, 17 Apr 2004 02:35:40 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3H9ZeNW016665 for dnsop-outgoing; Sat, 17 Apr 2004 02:35:40 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3H9ZcT4016283 for ; Sat, 17 Apr 2004 02:35:39 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H9ZVc21215; Sat, 17 Apr 2004 12:35:31 +0300 Date: Sat, 17 Apr 2004 12:35:31 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <2E330C00-904E-11D8-AA90-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Sat, 17 Apr 2004, Iljitsch van Beijnum wrote: > > This is another obviously bogus so-called "show-stopper" (compare to > > the request of waiting for root DNS servers to be dual-stack; another > > unnecessity). > > > These are religions/policitical reasons only, and I'd like to keep > > that part of the debate out of here. > > None of this is bogus. Running dual-stack has almost no advantages over > running IPv4-only, I don't think this is correct. It gives you v6 for services which would only be available (or working correctly) using v6. One could imagine a large number of p2p or similar applications falling under that category. Remember, our goal is not to deploy IPv6 so that we could surf the web using v6... You've probably seent his already, but have a peek at: http://www.cs.utk.edu/~moore/opinions/ipv6/dubious-assumptions.html (this is down at the moment, but you can get it from google cache.) > it is imperative that we make it possible to run > IPv6-only, as this is the ultimate goal. Implementations that require > IPv4 for critical functions, even if it's only for a small set of such > functions, are useless in the long run. Depends on how long run that will be. If you expect a node to be deployed for 10 years, probably yes. If it gets replaced or upgraded in 3 years, there's little chance of IPv4 going away during that time. > And just because we update a > spec doesn't mean people get to have implementations that conform to > the new version any time soon, so we have to get it right from the > start if at all possible. Which is why we should not give people panic attacks about this, but look at it rationally and carefully. Get it right. > > Therefore I'm reluctant to change the tone of the text. > > If you prefer to duke it out at IESG last call that's fine with me. There will be no IETF last call as this is going for Informational, so if you really think the text is unjustified (given above), please state it now (and if possible, suggest alternative that would be more in line with the earlier context..) > >> BTW: how does a dual-stack host know whether to use v4 or v6 > >> resolvers? > > > Depending on the ordering of resolv.conf. > > Well, if a hand-crafted resolv.conf is authorative here, why are we > wasting our time on all these discovery and autoconfiguration issues?? Obviously, the problem is that resolv.conf is not hand-crafted but machine-edited :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 08:26:25 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05487 for ; Sat, 17 Apr 2004 08:26:25 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3HBT9dX021974 for ; Sat, 17 Apr 2004 04:29:10 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3HBT9BA021970 for dnsop-outgoing; Sat, 17 Apr 2004 04:29:09 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3HBT7sN021827 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 17 Apr 2004 04:29:08 -0700 (PDT) Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3HBT51C050748; Sat, 17 Apr 2004 13:29:06 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6DF0E322-9062-11D8-AA90-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: dnsop@lists.uoregon.edu From: Iljitsch van Beijnum Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] Date: Sat, 17 Apr 2004 13:29:03 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.613) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Iljitsch van Beijnum Content-Transfer-Encoding: 7bit On 17-apr-04, at 11:35, Pekka Savola wrote: >>> This is another obviously bogus so-called "show-stopper" (compare to >>> the request of waiting for root DNS servers to be dual-stack; another >>> unnecessity). >> None of this is bogus. Running dual-stack has almost no advantages >> over >> running IPv4-only, > I don't think this is correct. It gives you v6 for services which > would only be available (or working correctly) using v6. Since there are no services that are inherently only possible over IPv6, the existence of services that are only available over IPv6 means that someone is running (effectively) IPv6-only. If they were fully dual-stack then the service would also be available over IPv4. So usefulness of IPv6 == usefulness of IPv6-only. > One could > imagine a large number of p2p or similar applications falling under > that category. Remember, our goal is not to deploy IPv6 so that we > could surf the web using v6... Our goal also isn't running IPv6 + IPv4 w/NAT for all eternity. Building an IPv6-only network is a much more attractive proposition than building an IPv4+IPv6 network, as this way there is no need to worry about lots of pesky IPv4 details (the users may have different opinions, but I'm talking about building the network right now). In a large network, having to run IPv4 everywhere just for the DNS is NOT cool, as this means having DHCP servers, worrying about subnet sizes and everything else. In an environment where the set of applications is limited (I for one only need SSH and HTTP 98% of the time) running v6-only internally and use proxying to talk to the v4 world is rapidly becoming an interesting option. > You've probably seent his already, but have a peek at: > http://www.cs.utk.edu/~moore/opinions/ipv6/dubious-assumptions.html I'd be happy to swap IPv6 deployment scenarios some time, and mine are slightly different than Keith's. But it's not all that relevant. In order to be really useful, IPv6 needs to be able to function regardless of the IPv4 status du jour. Example: a couple of RIPE meetings ago they had lots of troubles with the DHCP server. Now I was happily logged in to my server over SSH and tunneling email back and forth, but I was completely unable to access any web pages, even the ones on my own box, because I couldn't access the DNS: I had no IPv4 address, and MacOS didn't support DNS transport over IPv6 at that time. Now if I can run into this kind of trouble without actively looking for it, how are the chances that something similar will happen at times to the ontold millions whom IPv6 will be bestowed upon in the future? >> it is imperative that we make it possible to run >> IPv6-only, as this is the ultimate goal. Implementations that require >> IPv4 for critical functions, even if it's only for a small set of such >> functions, are useless in the long run. > Depends on how long run that will be. If you expect a node to be > deployed for 10 years, probably yes. If it gets replaced or upgraded > in 3 years, there's little chance of IPv4 going away during that time. It's not a question of going away. And how many people are still running Windows 98? Or even 95 for that matter? Old stuff just doesn't go away. >> And just because we update a >> spec doesn't mean people get to have implementations that conform to >> the new version any time soon, so we have to get it right from the >> start if at all possible. > Which is why we should not give people panic attacks about this, but > look at it rationally and carefully. Get it right. No panic attacks, but solid specifications so that people who implement them don't have to come back in a few years to update their stuff for issues that we are aware of *now*. > There will be no IETF last call as this is going for Informational, so > if you really think the text is unjustified (given above), please > state it now (and if possible, suggest alternative that would be more > in line with the earlier context..) I suggested: > Note that in the absense of DNS resolvers reachable over IPv6, either > due to failed discovery and/or lack of configuration, DNS resolvers > reachable over IPv4 may be used, if available. Is there anything wrong with this? I think this captures what we want implementors to do fairly well. We want them to implement whatever DNS discovery we come up with, but if they don't they should at least make it possible to configure IPv6 addresses for DNS resolvers manually. However, if (they didn't implement the discovery mechanism or no IPv6 resolvers were found) and no IPv6 resolvers were configured, IPv4 resolvers can be used. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 11:12:52 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14674 for ; Sat, 17 Apr 2004 11:12:51 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3HE5PaC027128 for ; Sat, 17 Apr 2004 07:05:25 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3HE5PT8027123 for dnsop-outgoing; Sat, 17 Apr 2004 07:05:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3HE5Nja026715 for ; Sat, 17 Apr 2004 07:05:23 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3HE4fr24212; Sat, 17 Apr 2004 17:04:41 +0300 Date: Sat, 17 Apr 2004 17:04:41 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <6DF0E322-9062-11D8-AA90-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola I think this discussion is mostly way out of scope here, so I'll try to resist continuing on-list except for the last part about the actual discovery.. On Sat, 17 Apr 2004, Iljitsch van Beijnum wrote: > > I don't think this is correct. It gives you v6 for services which > > would only be available (or working correctly) using v6. > > Since there are no services that are inherently only possible over > IPv6, the existence of services that are only available over IPv6 means > that someone is running (effectively) IPv6-only. If they were fully > dual-stack then the service would also be available over IPv4. So > usefulness of IPv6 == usefulness of IPv6-only. Wrong. Think of applications which are much simpler with IPv6, or cannot be done easily with IPv4. Such as apps that would need NAT traversal but plugging them to the current client-server model which is used to work around the NAT traversal requirement is not feasible. Pretty much everything can be plugged to v4 with a lot of effort. But at some point someone might actually figure out that doing that makes no sense. > > One could > > imagine a large number of p2p or similar applications falling under > > that category. Remember, our goal is not to deploy IPv6 so that we > > could surf the web using v6... > > Our goal also isn't running IPv6 + IPv4 w/NAT for all eternity. Of course not. > In a > large network, having to run IPv4 everywhere just for the DNS is NOT > cool, as this means having DHCP servers, worrying about subnet sizes > and everything else. If we needed to design v6-only systems, I don't think DNS discovery is coming even close to top of the list of problems we'd need to solve. > In an environment where the set of applications is > limited (I for one only need SSH and HTTP 98% of the time) running > v6-only internally and use proxying to talk to the v4 world is rapidly > becoming an interesting option. And for the rest, 2%? That's the gritty part here. (As well as deploying the infrastructure for the proxies etc.) > > You've probably seent his already, but have a peek at: > > > http://www.cs.utk.edu/~moore/opinions/ipv6/dubious-assumptions.html > > I'd be happy to swap IPv6 deployment scenarios some time, and mine are > slightly different than Keith's. But it's not all that relevant. In > order to be really useful, IPv6 needs to be able to function regardless > of the IPv4 status du jour. Example: a couple of RIPE meetings ago they > had lots of troubles with the DHCP server. Now I was happily logged in > to my server over SSH and tunneling email back and forth, but I was > completely unable to access any web pages, even the ones on my own box, > because I couldn't access the DNS: I had no IPv4 address, and MacOS > didn't support DNS transport over IPv6 at that time. Now if I can run > into this kind of trouble without actively looking for it, how are the > chances that something similar will happen at times to the ontold > millions whom IPv6 will be bestowed upon in the future? Sure, this will happen. But it will be no worse to the mainstream use as IPv4 won't work in any case, so there's little difference. Those who wish to truly avoid v4 are the early deployers in any case, may have had the DNS resolvers configured manually, using DHCPv6-lite, some other mechanism, etc. I'm not arguing that we should delay or avoid specifying DNS discovery; I'm just saying that it isn't our top priority, and folks who think it is are probably thinking of IPv6 deployment in different kind of terms. > >> it is imperative that we make it possible to run > >> IPv6-only, as this is the ultimate goal. Implementations that require > >> IPv4 for critical functions, even if it's only for a small set of such > >> functions, are useless in the long run. > > > Depends on how long run that will be. If you expect a node to be > > deployed for 10 years, probably yes. If it gets replaced or upgraded > > in 3 years, there's little chance of IPv4 going away during that time. > > It's not a question of going away. And how many people are still > running Windows 98? Or even 95 for that matter? Old stuff just doesn't > go away. Such old stuff (of today, say Windows 2003) is very unlikely even supposed to function properly in IPv6-only operation. There's always some old stuff around, but people who aren't switching away from that old stuff aren't expecting the old stuff to function except in the set-ups which have been stable for a long time. > > There will be no IETF last call as this is going for Informational, so > > if you really think the text is unjustified (given above), please > > state it now (and if possible, suggest alternative that would be more > > in line with the earlier context..) > > I suggested: > > > Note that in the absense of DNS resolvers reachable over IPv6, either > > due to failed discovery and/or lack of configuration, DNS resolvers > > reachable over IPv4 may be used, if available. > > Is there anything wrong with this? I think this captures what we want > implementors to do fairly well. We want them to implement whatever DNS > discovery we come up with, but if they don't they should at least make > it possible to configure IPv6 addresses for DNS resolvers manually. > However, if (they didn't implement the discovery mechanism or no IPv6 > resolvers were found) and no IPv6 resolvers were configured, IPv4 > resolvers can be used. This document is not meant as a lever that can be used to show the vendors, "see, we need IPv6 DNS discovery!"; we need truth-in-advertising and the earlier statement is fully correct here: Note that IPv6 DNS resolver discovery is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as IPv6. Teasing apart two major points: 1) DNS resolver discovery is not *required* (in specific scenarios), but it does not hurt either. 2) you can only omit DNS resolver discovery if you're in a dual stack network and you're a dual stack node (if you have v6-only scenario in mind, you need it in any case). In other words, this says "In specific, common scenarios, IPv6 DNS resolver discovery is not required", while your suggestion says "If DNS resolver discovery doesn't work or doesn't exist, you can fall back to v4 as well if that works for you". The former is IMHO much more accurate, but I think the "required" part could be expanded to include a recommendation as well, like: Note that even though IPv6 DNS resolver discovery is a recommended procedure, it is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as IPv6. Would that alleviate your concern? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sat Apr 17 14:28:17 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21590 for ; Sat, 17 Apr 2004 14:28:17 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3HHT20M000463 for ; Sat, 17 Apr 2004 10:29:02 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3HHT2oL000457 for dnsop-outgoing; Sat, 17 Apr 2004 10:29:02 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3HHT0w0000137 for ; Sat, 17 Apr 2004 10:29:01 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3HHSpU27030; Sat, 17 Apr 2004 20:28:51 +0300 Date: Sat, 17 Apr 2004 20:28:51 +0300 (EEST) From: Pekka Savola To: bmanning@vacation.karoshi.com cc: Iljitsch van Beijnum , Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <20040417152348.GC27506@vacation.karoshi.com.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Sat, 17 Apr 2004 bmanning@vacation.karoshi.com wrote: > Does this cover the case where manual configuration is > over-written by one or more automated discovery procedures? > > or to put it another way, > > What is the preference order for service "discovery" when > multiple methods are in play? Methinks we have created an > interesting problem by having competing methods, each rewriting > the "resolv.conf" file as they see fit. End users will not > be pleased. Yes, this is a problem that will need to be addressed w/ discovery methods. It's already being considered in the scope of different DHCPs, and if other discovery methods are adopted, this will need to be considered here explicitly as well. But that seems beyond the scope of the DNS discovery statement itself. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sun Apr 18 05:32:42 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09969 for ; Sun, 18 Apr 2004 05:32:41 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3I8aScL011407 for ; Sun, 18 Apr 2004 01:36:28 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3I8aSBZ011404 for dnsop-outgoing; Sun, 18 Apr 2004 01:36:28 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3I8aQkG011087 for ; Sun, 18 Apr 2004 01:36:26 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3I8ZsL12499; Sun, 18 Apr 2004 11:35:58 +0300 Date: Sun, 18 Apr 2004 11:35:54 +0300 (EEST) From: Pekka Savola To: Mark Andrews cc: dnsop@lists.uoregon.edu Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <200404172213.i3HMD5gg041035@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Sun, 18 Apr 2004, Mark Andrews wrote: > The use of DNAME has always been *independent* of whether > A6/AAAA or nibble/Bitlabels are in use. The choice to use > DNAME is driven by neither of these. It will be driven by > the need to shift a heirachy of zones without having to > redelegate the entire heirachy. I think the current text: In particular one should note that the use of A6 records in the forward tree or Bitlabels in the reverse tree is not recommended [2]. Using DNAME records is not recommended in the reverse tree in conjunction with A6 records; the document did not mean to take a stance on any other use of DNAME records [5]. is good, because it clarifies the intent. Removing it would be worse. Do you agree? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sun Apr 18 06:16:37 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11924 for ; Sun, 18 Apr 2004 06:16:36 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3I9RHcA005667 for ; Sun, 18 Apr 2004 02:27:18 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3I9RHGX005659 for dnsop-outgoing; Sun, 18 Apr 2004 02:27:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3I9RFnR005488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sun, 18 Apr 2004 02:27:16 -0700 (PDT) Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3I9RF1C070753; Sun, 18 Apr 2004 11:27:15 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93ABE00A-911A-11D8-AA90-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: dnsop@lists.uoregon.edu From: Iljitsch van Beijnum Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] Date: Sun, 18 Apr 2004 11:27:14 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.613) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Iljitsch van Beijnum Content-Transfer-Encoding: 7bit On 17-apr-04, at 16:04, Pekka Savola wrote: >> Since there are no services that are inherently only possible over >> IPv6, the existence of services that are only available over IPv6 >> means >> that someone is running (effectively) IPv6-only. If they were fully >> dual-stack then the service would also be available over IPv4. So >> usefulness of IPv6 == usefulness of IPv6-only. > Pretty much everything can be plugged to v4 with a lot of effort. But > at some point someone might actually figure out that doing that makes > no sense. One of the things that makes no sense is to keep using v4 for stuff such as DNS lookups and thereby forcing people to keep v4 in their network. >> In a >> large network, having to run IPv4 everywhere just for the DNS is NOT >> cool, as this means having DHCP servers, worrying about subnet sizes >> and everything else. > If we needed to design v6-only systems, I don't think DNS discovery is > coming even close to top of the list of problems we'd need to solve. What would this list be then? Feel free to reply privately for this. >> In an environment where the set of applications is >> limited (I for one only need SSH and HTTP 98% of the time) running >> v6-only internally and use proxying to talk to the v4 world is rapidly >> becoming an interesting option. > And for the rest, 2%? That's the gritty part here. (As well as > deploying the infrastructure for the proxies etc.) DNS discovery is most relevant to mobile systems. (It's also very useful for non-mobile systems but manual configuration is much more doable for those.) So if I only need v4 2% of the time I can easily solve this by making sure I connect to a v4-only or dual stack network part of the time, while running v6-only some of the time. >> In order to be really useful, IPv6 needs to be able to function >> regardless >> of the IPv4 status du jour. Example: a couple of RIPE meetings ago >> they >> had lots of troubles with the DHCP server. Now I was happily logged in >> to my server over SSH and tunneling email back and forth, but I was >> completely unable to access any web pages, even the ones on my own >> box, >> because I couldn't access the DNS: I had no IPv4 address, and MacOS >> didn't support DNS transport over IPv6 at that time. Now if I can run >> into this kind of trouble without actively looking for it, how are the >> chances that something similar will happen at times to the ontold >> millions whom IPv6 will be bestowed upon in the future? > Sure, this will happen. But it will be no worse to the mainstream use > as IPv4 won't work in any case, so there's little difference. I honestly don't understand how you can say something like this. Obviously not having v4 is nearly always a big problem, but if we can make sure people still get to use IPv6 in those cases, this would be extremely helpful in many cases, even today, for instance in the case where the user can access her email over IPv6. And it provides an incentive to people to deploy dual stack. > I'm not arguing that we should delay or avoid specifying DNS > discovery; I'm just saying that it isn't our top priority, and folks > who think it is are probably thinking of IPv6 deployment in different > kind of terms. I'm not privvy to your personal priority list. The only thing I know is that we are discussing IPv6 DNS resolver discovery *now* so we need to do a goot job at it. >> It's not a question of going away. And how many people are still >> running Windows 98? Or even 95 for that matter? Old stuff just doesn't >> go away. > Such old stuff (of today, say Windows 2003) is very unlikely even > supposed to function properly in IPv6-only operation. That's exactly my point. If a simple, but useful DNS discovery method had been specified several years ago, Windows 2003 might have included it and be able to run v6-only. Let me ask you a question: suppose that someone wants to make a full IPv6 implementation, one that can be expected to work for the next 10 years or so. At which point in time were (or will be) the IPv6 specifications mature enough to base such an implementation on? >>> Note that in the absense of DNS resolvers reachable over IPv6, either >>> due to failed discovery and/or lack of configuration, DNS resolvers >>> reachable over IPv4 may be used, if available. > This document is not meant as a lever that can be used to show the > vendors, "see, we need IPv6 DNS discovery!"; we need > truth-in-advertising and the earlier statement is fully correct here: > Note that IPv6 DNS resolver discovery is not required for dual-stack > nodes in dual-stack networks as IPv6 DNS records can be queried over > IPv4 as well as IPv6. I'm sorry, but I disagree. This text assumes there are nodes which are inherently dual-stack. That is an assumption we can't make. Even the implementor can't make this decision: whether a node runs v4-only, v6-only or dual stack is, and should be, up to the person running the box. If implementors don't want to build a stack that doesn't provide full functionality in a v6-only setup, that's of course their choice, but we should certainly not encourage them to do so. So if you want to keep your text, I think we should add: However, IPv6 DNS resolver discovery or manual configuration is necessary for a node to operate in the absense of reachable IPv4 DNS resolvers, either because of an outage or because the node is configured for IPv6 operation only. > Teasing apart two major points: > 1) DNS resolver discovery is not *required* (in specific scenarios), > but it does not hurt either. Which is a moot point, because: 1. This isn't a standards document 2. The specific scenario the node operates under depends on the operator > 2) you can only omit DNS resolver discovery if you're in a dual stack > network and you're a dual stack node (if you have v6-only scenario in > mind, you need it in any case). > In other words, this says "In specific, common scenarios, IPv6 DNS > resolver discovery is not required", while your suggestion says "If > DNS resolver discovery doesn't work or doesn't exist, you can fall > back to v4 as well if that works for you". > The former is IMHO much more accurate, They're both accurate, the question is what kind of advice implementors are going to read into it. You seem to be saying "it's ok to require IPv4 to be present" while I want to get across "be careful not to unintentionally assume the presence of IPv4". (I would like to go much futher than that, though...) > but I think the "required" part > could be expanded to include a recommendation as well, like: > Note that even though IPv6 DNS resolver discovery is a recommended > procedure, it is not required for dual-stack nodes in dual-stack > networks as IPv6 DNS records can be queried over IPv4 as well as > IPv6. > Would that alleviate your concern? No. See above. Any "not required" reads as "don't bother to include this part". . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Sun Apr 18 07:37:45 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14378 for ; Sun, 18 Apr 2004 07:37:45 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3IAiNF0016107 for ; Sun, 18 Apr 2004 03:44:23 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3IAiNWM016101 for dnsop-outgoing; Sun, 18 Apr 2004 03:44:23 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3IAiLYA015740 for ; Sun, 18 Apr 2004 03:44:22 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3IAi8S13920; Sun, 18 Apr 2004 13:44:13 +0300 Date: Sun, 18 Apr 2004 13:44:08 +0300 (EEST) From: Pekka Savola To: Mark Andrews cc: dnsop@lists.uoregon.edu Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: <200404180942.i3I9gRgg033123@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Sun, 18 Apr 2004, Mark Andrews wrote: > > On Sun, 18 Apr 2004, Mark Andrews wrote: > > > The use of DNAME has always been *independent* of whether > > > A6/AAAA or nibble/Bitlabels are in use. The choice to use > > > DNAME is driven by neither of these. It will be driven by > > > the need to shift a heirachy of zones without having to > > > redelegate the entire heirachy. > > > > I think the current text: > > > > In particular one should note that the use of A6 records in the > > forward tree or Bitlabels in the reverse tree is not recommended [2]. > > Using DNAME records is not recommended in the reverse tree in > > conjunction with A6 records; the document did not mean to take a > > stance on any other use of DNAME records [5]. > > > > is good, because it clarifies the intent. Removing it would be worse. > > Do you agree? > > No. You are doing the same thing RFC 3363 did. You are > placing a restriction on DNAME that SHOULD NOT BE THERE. > There is no reason to place any restriction on DNAME. Read it again; it says: Using DNAME records is not recommended in the reverse tree in conjunction with A6 records; (this is what RFC3363 meant to say about DNAME's, I was told) the document did not mean to take a stance on any other use of DNAME records [5]. (clarifies that RFC3363 didn't mean to restrict DNAME's in any other way.) Based on this, I do not think there is consensus to change this at all. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 19 05:35:09 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29342 for ; Mon, 19 Apr 2004 05:35:09 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J8O5qI029903 for ; Mon, 19 Apr 2004 01:24:05 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3J8O58k029895 for dnsop-outgoing; Mon, 19 Apr 2004 01:24:05 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J8O4ie029785 for ; Mon, 19 Apr 2004 01:24:05 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a5ff:aefb:fee7:dff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2C6DC15210; Mon, 19 Apr 2004 17:24:03 +0900 (JST) Date: Mon, 19 Apr 2004 17:24:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Fri, 16 Apr 2004 12:58:49 +0300 (EEST), >>>>> Pekka Savola said: > There haven't been as many replies as I'd have hoped for, but I think > there is slight preference towards rewording to not say much of > anything about DNAME, along the lines of: > In particular one should note that the use of A6 records in > the forward tree or Bitlabels in the reverse tree is not recommended > . Using DNAME records is not recommended in > the reverse tree in conjunction with A6 records; the document did not > mean to take a stance on any other use of DNAME records target="RFC3364"/>. > Or do we have proposals for different kind of wording? If so, please > send it ASAP. Personally, I'm fine with this wording. I think it reasonably reflects the intention of RFC3363 (as Rob explained), and that's enough for the dns-issues draft. (Whether DNAME itself is a good or bad thing or whether RFC3363 should be revised on this is a separate issue from this draft, IMO). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 19 05:39:41 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29524 for ; Mon, 19 Apr 2004 05:39:40 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J8aRO2003656 for ; Mon, 19 Apr 2004 01:36:27 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3J8aRBR003643 for dnsop-outgoing; Mon, 19 Apr 2004 01:36:27 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J8aQ8W003576 for ; Mon, 19 Apr 2004 01:36:26 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a5ff:aefb:fee7:dff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D438615210; Mon, 19 Apr 2004 17:36:25 +0900 (JST) Date: Mon, 19 Apr 2004 17:36:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: References: <200404161418.i3GEIIgg047274@drugs.dv.isc.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Sat, 17 Apr 2004 10:07:09 +0300 (EEST), >>>>> Pekka Savola said: >> > > Lets be consistant w/ draft-ietf-ipv6-node-requirements-08.txt. >> > > All references to DNAME were removed in the last draft there. >> > > >> > > See Section 5.2 >> > > >> > > Those nodes are NOT RECOMMENDED to support the experimental A6 and >> > > DNAME Resource Records [RFC-3363]. >> > >> > I'm fine with saying DNAME support is not recommended. But did I >> > misunderstand you -- as this appears to exactly the opposite to what >> > you've said in the past? >> >> I must be tired. See the thread starting here >> http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01689.html >> for this issue over in ipv6. Fighting this multiple times >> is a pain. > Oh, your comment was confusing, as > draft-ietf-ipv6-node-requirements-08.txt does not include the comment > you suggest. (Hmm, I've not seen responses from Mark in this thread, and this point may have been clarified already, but) I guess Mark wanted to point out he requested node-requirements-08 remove the part mentioning DNAME and the main editor agreed with him (this is what happened in the thread available at the above URL). And, based on that agreement, he apparently wanted node-requirements and dns-issues to be synchronized. As I already said, however, I personally think the current proposed wording for the dns-issues draft makes much more sense in that it correctly reflects the sense of RFC3363. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 19 06:04:13 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00370 for ; Mon, 19 Apr 2004 06:04:12 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J8veHg001637 for ; Mon, 19 Apr 2004 01:57:41 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3J8veB3001633 for dnsop-outgoing; Mon, 19 Apr 2004 01:57:40 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J8vdF9001559 for ; Mon, 19 Apr 2004 01:57:40 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a5ff:aefb:fee7:dff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F321015210; Mon, 19 Apr 2004 17:57:38 +0900 (JST) Date: Mon, 19 Apr 2004 17:57:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Fri, 9 Apr 2004 18:57:21 +0300 (EEST), >>>>> Pekka Savola said: > Sounds good, added. Thanks. > I've also added note in the next paragraph noting that the prefix > delegator, with case 1, may not actually provide any DDNS service but > just insert a wildcard record, and refer to section 7.2: (Just in case you're waiting for my response - and if so, sorry for the delay) the added text works for me. BTW, > In the first case, managing the reverse DNS (delegation) is simpler > as the DNS server and the prefix delegator are in the same > administrative domain (as there is no need to delegate anything at > all); alternatively, the prefix delegator might forgo DDNS reverse > capability altogether, and use e.g., wildcard records (as described > in Section 7.2). In the other cases, it can be slighly more > difficult, particularly as the site will have to configure the DNS > server to be authorative for the delegated reverse zone, implying ^^^^^^^^^^^this should be "authoritative" though you may have already fixed the typo. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 19 07:04:12 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03291 for ; Mon, 19 Apr 2004 07:04:11 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J9vZBg027063 for ; Mon, 19 Apr 2004 02:57:35 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3J9vZsv027056 for dnsop-outgoing; Mon, 19 Apr 2004 02:57:35 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3J9vYPR026947 for ; Mon, 19 Apr 2004 02:57:34 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a5ff:aefb:fee7:dff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7038A15210; Mon, 19 Apr 2004 18:57:33 +0900 (JST) Date: Mon, 19 Apr 2004 18:57:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= (I've changed the subject since I'm going to this particular issue only). >>>>> On Wed, 7 Apr 2004 11:38:34 +0300 (EEST), >>>>> Pekka Savola said: >> 3. Section 4.4 (The Use of TTL for IPv4 and IPv6 RRs) >> >> example.com. 300 IN MX foo.example.com. >> foo.example.com. 300 IN A 192.0.2.1 >> foo.example.com. 100 IN AAAA 2001:db8::1 >> ... >> ... So, >> in this particular case, there is a window of 200 seconds when >> incomplete information is returned from the cache. >> >> I don't see what's wrong with this. In this case, the lost >> information would be "additional" one (returned in the additional >> section) after all. If the client (probably an SMTP server in this >> case) needs the missing AAAA, it can ask for the missing RR(s) >> separately (otherwise, I'd call this a bug in the client). > You raise a good point. I seem to have been slightly confused here, > thinking that the clients would do somekind of "ANY" or "give me > everything you have about 'name'" queries. > You can do "ANY" query, but that does not give you the right answer > unless the caching resolvers on the path have also queried for both v4 > and v6 records. So, practically, you have to perform explicit queries > for both A and AAAA records. However, there is a case where you do > not need explicit queries but where you could be led astray: querying > for MX record, as the caches may give you nothing (this leads you to > query both records explicitly), full results, or impartial results. > Here I'm worried of impartial results. > Or am I missing something and is there some kind of real application > of "ANY" queries? Does anyone use them e.g. on DNS server or stub > resolver implementations? As a matter of fact, I don't know any DNS server implementations or stub resolvers that rely on "ANY" (or QTYPE=*) queries. I'm even not sure if this is crucial for this discussion... > Let me try to understand your bug example. Would you consider it a > bug that a DNS cache would have cached both A and AAAA records with > different TTLs, and when the first-to-expire expires, the DNS cache > does not re-query the one that expired? No, I don't think it's a bug unless the caching server is the "real client" of the records. This is the case when it tries to send a query to other authoritative servers. > Should it re-query that? No, it doesn't have to re-query. > I mean, if the cache would return records in an additional section > (e.g., when queried for MX record), but would not return all of them > (because some of them had expired), would you consider this a bug? No, I'd call a bug in this case if the "real client" asking a caching DNS server does not re-query for the missing A or AAAA record. To be more specific, consider an SMTP server and a DNS caching server. Also assume there is an outside zone "example.com" to which the SMTP server would want to send e-mail messages and we have different TTLs for the A and AAAA RRs of the host name pointed by MX in the example.com zone: example.com. 300 IN MX foo.example.com. foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 100 IN AAAA 2001:db8::1 When the SMTP server first tries to send an e-mail message to example.com, it asks the caching server for an MX record of "example.com". The caching server receives all the three RRs, caches the RRs, and returns them to the SMTP server (MX in the answer section, and A/AAAA in the additional section). 100 seconds later, the AAAA records expires at the caching server. As I already said, the caching server does not have to re-query for the expired recored (and I don't call it a bug of the caching server if it does not re-query). Then suppose the SMTP server tries to send another message to example.com (before the A and MX RRs expire). It asks the caching server for an MX record of example.com, and the caching server would return the MX (in the answer section) and A (in the additional section) RRs in the cache (but not the AAAA RR). If the SMTP server has IPv6 connectivity and wants to establish an SMTP connection over IPv6 to example.com, then it should make another query for the AAAA RR of "foo.example.com" and send it to the caching server. Otherwise, I'd call the SMTP server buggy. Am I clear enough? > (See below for text update.) >> So, >> >> Therefore, when the same name refers to both A and AAAA records, >> these records should have the same TTL. >> >> I don't see a valid reason for this either. Moreover, I can even >> think of a case we want to use different TTLs for A and AAAA RRsets. >> For example, if I'm going to renumber an IPv6 address of a host while >> keeping IPv4 addresses on that host, I might want to use a shorter TTL >> for the AAAA RRset but a longer, stable TTL for the A RRset. > I think it should be reasonable to suggest that the TTL should be the > same (because that simplifies the operations for those servers > which have to handle the both) unless there are valid reasons (like > the ones you cite) for handling them differently. > As for the current wording I've adopted (this probably requires more > tuning still): I don't see anything obviously wrong in the planned text below (except the paragraph beginning with "So, we assume", since this is not what I meant to say). However, I still don't understand why we should mention this in the first place. Actually, as explained in item 2, "it is impossible to guarantee that in fact we would always get back all the records". Even if we use the same TTL for the A and AAAA RRs in this example, the caching server can still have a "partial" result, e.g., due to packet size issues. On the other hand, we may even want to use different TTL intentionally, as I explained in my first message. Finally, I don't see why the third case below is problematic (BTW: I'm now confused with the wording of "impartial" there. What does this actually mean?) So, at the moment, I don't see the need for this subsection at all. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp > 4.4 The Use of TTL for IPv4 and IPv6 RRs > The behaviour of DNS caching when different TTL values are used for > different records of the same name requires explicit discussion. For > example, let's consider a part of a zone: > example.com. 300 IN MX foo.example.com. > foo.example.com. 300 IN A 192.0.2.1 > foo.example.com. 100 IN AAAA 2001:db8::1 > When a caching resolver asks for the MX record of example.com, it > gets back "foo.example.com". It may also get back either one or both > of the A and AAAA records in the additional section. So, there are > three cases about returning records for the MX in the additional > section: > 1. We get back no A or AAAA records: this is the simplest case, > because the we have to query which information is required > explicitly, guaranteeing that we get all the information we're > interested in. > 2. We get back all the records: this is an optimization as there is > no need to perform more queries, causing lower latency. However, > it is impossible to guarantee that in fact we would always get > back all the records; however, one could try to work in the > direction to try to ensure it as far as possible. > 3. We get impartial results: this is indistinguishable from the > previous case, and problematic as described in the next section. > So, we assume we get back both A and AAAA records of foo.example.com, > or the resolver explicitly asks, in two separate queries, both A and > AAAA records. After 100 seconds, the AAAA record is removed from the > cache because its TTL expired. The cache must re-query the AAAA > record when its TTL expires to avoid the situation where there would > be a window of 200 seconds when incomplete information is returned > from the cache. XXX: if this is not done, is it a bug? > To simplify the situation, it is recommended to use the same TTL for > all the records referring to the same name. However, there are some > scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where > a different strategy is preferable. > More issues with caching and A/AAAA records is presented in the next > section. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 19 16:31:38 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07948 for ; Mon, 19 Apr 2004 16:31:37 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3JJ9bs2027341 for ; Mon, 19 Apr 2004 12:09:37 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3JJ9bEH027337 for dnsop-outgoing; Mon, 19 Apr 2004 12:09:37 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3JJ9YuU026574 for ; Mon, 19 Apr 2004 12:09:35 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3JJ9Nt10069; Mon, 19 Apr 2004 22:09:23 +0300 Date: Mon, 19 Apr 2004 22:09:23 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Mon, 19 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > As a matter of fact, I don't know any DNS server implementations or > stub resolvers that rely on "ANY" (or QTYPE=*) queries. I'm even not > sure if this is crucial for this discussion... OK. > > I mean, if the cache would return records in an additional section > > (e.g., when queried for MX record), but would not return all of them > > (because some of them had expired), would you consider this a bug? > > No, I'd call a bug in this case if the "real client" asking a caching > DNS server does not re-query for the missing A or AAAA record. > > To be more specific, consider an SMTP server and a DNS caching server. > Also assume there is an outside zone "example.com" to which the SMTP > server would want to send e-mail messages and we have different TTLs > for the A and AAAA RRs of the host name pointed by MX in the > example.com zone: > > example.com. 300 IN MX foo.example.com. > foo.example.com. 300 IN A 192.0.2.1 > foo.example.com. 100 IN AAAA 2001:db8::1 > > When the SMTP server first tries to send an e-mail message to > example.com, it asks the caching server for an MX record of > "example.com". The caching server receives all the three RRs, caches > the RRs, and returns them to the SMTP server (MX in the answer > section, and A/AAAA in the additional section). > > 100 seconds later, the AAAA records expires at the caching server. > As I already said, the caching server does not have to re-query for > the expired recored (and I don't call it a bug of the caching server > if it does not re-query). > > Then suppose the SMTP server tries to send another message to > example.com (before the A and MX RRs expire). It asks the caching > server for an MX record of example.com, and the caching server would > return the MX (in the answer section) and A (in the additional > section) RRs in the cache (but not the AAAA RR). > > If the SMTP server has IPv6 connectivity and wants to establish an > SMTP connection over IPv6 to example.com, then it should make another > query for the AAAA RR of "foo.example.com" and send it to the caching > server. Otherwise, I'd call the SMTP server buggy. > > Am I clear enough? Yes, this is clear now. However, I think I have to disagree with the last paragraph a bit. I don't think it's feasible to require you to do special queries in case you have IPv6 connectivity, just in case there would be IPv6 records which had been omitted from the caches. The SMTP servers should not have to have any such code at all; they should just take whatever they are given when they send a MX query and be happy with it. Forcing any IPv6-capable SMTP server to perform a mostly useless AAAA query seems like a waste of time and bits. But as this is the current specification situation, there's not much one can do about it. If you want to be positively sure that you always get all the records, you have to query them explicitly yourself, with the record type you're interested in getting. The things that would help here, though, are at least: 1) if the DNS servers/caches/etc. either sent all the records or no additional records unless they can send everything, 2.a) if the DNS servers/caches/etc. would have identical TTLs for all the protocol versions, or 2.b) if the caches would expire all the records under a hostname (above, foo.example.com) when the first of A/AAAA records expired. This would actually seem to make sense.. To get out of this situation without explicit queries, we'd seemingly have to do 1) and either 2.a) and 2.b). My own personal preference is 1), recommending 2.a) but not requiring it, and requiring/recommending 2.b) as caching implementation technique. > I don't see anything obviously wrong in the planned text below (except > the paragraph beginning with "So, we assume", since this is not what I > meant to say). True, I've reworded that. > However, I still don't understand why we should > mention this in the first place. Actually, as explained in item 2, > "it is impossible to guarantee that in fact we would always get back > all the records". Even if we use the same TTL for the A and AAAA RRs > in this example, the caching server can still have a "partial" result, > e.g., due to packet size issues. On the other hand, we may even want > to use different TTL intentionally, as I explained in my first > message. I think it might be useful to try to describe these TTL issues explicitly, as I their impact hasn't been clearly spelled out wrt. records of different types.. > Finally, I don't see why the third case below is problematic (BTW: I'm > now confused with the wording of "impartial" there. What does this > actually mean?) See above for my belief that we should not have to burden all the SMTP servers in the world to make unnecessary queries just to confirm there was no IPv6 address for the MX record; the steps described in here go a long way in that direction. I've reworded impartial here. As RRsets can't be broken up, it was used to refer to "both A and AAAA records exists, but a cache returned only one kind of them". I couldn't find a better word (suggestions?) but I've reworded it out of these now. I also changed the order of sections 4.4 and 4.5, as TTL appears to be a more specific issue than "impartial" additional data. The text now is: ====== 4.5 The Use of TTL for IPv4 and IPv6 RRs In the previous section, we discussed a danger with queries, potentially leading to omitting records information from the additional section. This section describes another problem leading to omitting records in cached data, highlighted in the IPv4/IPv6 environment. The behaviour of DNS caching when different TTL values are used for different records of the same name requires explicit discussion. For example, let's consider a part of a zone: example.com. 300 IN MX foo.example.com. foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 100 IN AAAA 2001:db8::1 When a caching resolver asks for the MX record of example.com, it gets back "foo.example.com". It may also get back either one or both of the A and AAAA records in the additional section. So, there are three cases about returning records for the MX in the additional section: 1. We get back no A or AAAA records: this is the simplest case, because then we have to query which information is required explicitly, guaranteeing that we get all the information we're interested in. 2. We get back all the records: this is an optimization as there is no need to perform more queries, causing lower latency. However, it is impossible to guarantee that in fact we would always get back all the records (the only way to ensure that is to send a AAAA query for the name after getting the cached reply); however, one could try to work in the direction to try to ensure it as far as possible. 3. We only get back A or AAAA records even if both existed: this is indistinguishable from the previous case, and problematic as described in the next section. So, we assume we get back both A and AAAA records of foo.example.com, or the resolver explicitly asks, in two separate queries, both A and AAAA records. After 100 seconds, the AAAA record is removed from the cache because its TTL expired. It would be useful for the cache to re-query the AAAA record or discard the A record when the shorter TTL (in this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. However, this is not mandated or mentioned by the specification(s). To simplify the situation, it is recommended to use the same TTL for all the records referring to the same name. However, there are some scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where a different strategy is preferable. ======== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 19 16:47:20 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09114 for ; Mon, 19 Apr 2004 16:47:19 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3JJGIWp027052 for ; Mon, 19 Apr 2004 12:16:18 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3JJGI7v027034 for dnsop-outgoing; Mon, 19 Apr 2004 12:16:18 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3JJGGLp026473 for ; Mon, 19 Apr 2004 12:16:17 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3JJGAa10184 for ; Mon, 19 Apr 2004 22:16:10 +0300 Date: Mon, 19 Apr 2004 22:16:10 +0300 (EEST) From: Pekka Savola To: dnsop@lists.uoregon.edu Subject: -05 to be posted soon [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Folks, I've (again) updated the document, and it is at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt Unless I hear voluminous objections in about 8 hours (i.e., next morning my time), I'm going to post the draft. If there are significant issues, I'll delay the posting a day or two. (Especially I'm interested if Jinmei's TTL issue has been adequately addressed.) Thanks! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 20 03:57:53 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29763 for ; Tue, 20 Apr 2004 03:57:53 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3K6SRom016124 for ; Mon, 19 Apr 2004 23:28:27 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3K6SRPu016120 for dnsop-outgoing; Mon, 19 Apr 2004 23:28:27 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3K6SPdd016008 for ; Mon, 19 Apr 2004 23:28:26 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a5ff:aefb:fee7:dff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 422DF15214; Tue, 20 Apr 2004 15:28:25 +0900 (JST) Date: Tue, 20 Apr 2004 15:28:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Mon, 19 Apr 2004 22:09:23 +0300 (EEST), >>>>> Pekka Savola said: > However, I think I have to disagree with the last paragraph a bit. I > don't think it's feasible to require you to do special queries in case > you have IPv6 connectivity, just in case there would be IPv6 records > which had been omitted from the caches. The SMTP servers should not > have to have any such code at all; they should just take whatever they > are given when they send a MX query and be happy with it. Forcing any > IPv6-capable SMTP server to perform a mostly useless AAAA query seems > like a waste of time and bits. > But as this is the current specification situation, there's not much > one can do about it. If you want to be positively sure that you > always get all the records, you have to query them explicitly > yourself, with the record type you're interested in getting. Okay, so I guess my position is not so different than yours...but one thing I'd like to emphasize is that the application (the SMTP server in this case) should not assume anything in the additional section, and should basically have the ability to fetch missing additional data. In that sense, I disagree on your saying that "the SMTP servers should not have to have any such code at all". But at the same time, it's okay for me to mention that it may help if we use the same TTL for A and AAAA RRsets in this type of case. It's just a tip that may optimize the thing, though; I think "recommendation" is a strong word for this. >> However, I still don't understand why we should >> mention this in the first place. Actually, as explained in item 2, >> "it is impossible to guarantee that in fact we would always get back >> all the records". Even if we use the same TTL for the A and AAAA RRs >> in this example, the caching server can still have a "partial" result, >> e.g., due to packet size issues. On the other hand, we may even want >> to use different TTL intentionally, as I explained in my first >> message. > I think it might be useful to try to describe these TTL issues > explicitly, as I their impact hasn't been clearly spelled out wrt. > records of different types.. Okay. >> Finally, I don't see why the third case below is problematic (BTW: I'm >> now confused with the wording of "impartial" there. What does this >> actually mean?) > See above for my belief that we should not have to burden all the SMTP > servers in the world to make unnecessary queries just to confirm there > was no IPv6 address for the MX record; the steps described in here go > a long way in that direction. > I've reworded impartial here. As RRsets can't be broken up, it was > used to refer to "both A and AAAA records exists, but a cache returned > only one kind of them". I couldn't find a better word (suggestions?) > but I've reworded it out of these now. Hmm, the sense was not really clear at least to me with the literal meaning of "impartial". But I'm not an expert on English wording and I don't have a better suggestion, so I'd leave this to you (I mean it's okay if you want to keep it). (Note that the latest version of 05pre still has this term in Section 4.4, which has been Sect. 4.5 so far). The following is my comment on the latest 05pre revision of the draft (MD5 fingerprint is d59264c3f988a8fc132bc88c6c3de557). Notice that I only read Sections 4.4 and 4.5. 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments Consider thes case where the query name is so long, the number of the s/thes/the/ additional records (originated from "glue") is so high, or for other reasons that the response must either be truncated (leading to a retry with TCP) or some of the additional data removed from the reply. It's hard to parse the part "or some of the...from the reply". Do you mean: ...or for other reasons that the response must be truncated (leading to a retry with TCP) or some of the additional data must be removed from the reply. ? In the last paragraph, ... The operational fix for this is having the DNS server implementations return a warning when the administrators create the zones which would result in too much additional data being returned. I think this statement is too strong, since it sounds like this is the only operational fix. I'd suggest to reword this e.g., "An operational fix for this", etc. 4.5 The Use of TTL for IPv4 and IPv6 RRs 3. We only get back A or AAAA records even if both existed: this is indistinguishable from the previous case, and problematic as described in the next section. s/next/previous/ ? As a more essential comment, it's still not clear to me what the problem described in the previous section is...are you particularly referring to the 3rd paragraph of Section 4.4, that is, (e.g.) returning A records to an IPv6-only node? So, we assume we get back both A and AAAA records of foo.example.com, or the resolver explicitly asks, in two separate queries, both A and AAAA records. After 100 seconds, the AAAA record is removed from the cache because its TTL expired. It would be useful for the cache to re-query the AAAA record or discard the A record when the shorter TTL (in this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. However, this is not mandated or mentioned by the specification(s). This paragraph seems to have several problems: 1. it's not clear to me why this paragraph begins with "So,". Do you mean something like this? "In order to discuss the case where we have both A and AAAA records, let's assume we get back both records of foo.example.com, or the resolver explicitly asks, in two separate queries, both A and AAAA records." 2. in this paragraph, you used the term "resolver". But I'm not sure what it exactly specifies, partly because you also used the term "caching resolver" in this section...does the "resolver" mean the "caching resolver" or the (so-called) "stub resolver"? Similarly, if you mean the "caching resolver" in "It would be useful for the cache to..." (I believe you do), then I'd suggest to reword it as "It would be useful for the caching resolver to...". 3. it might be controversial whether "it would be useful for the cache to re-query the AAAA record". This behavior is similar to BIND8's "fetch-glue" feature (though the caching server with fetch-glue being on does not return the missing additional data to the stub resolver during re-fetching it). But ISC has deprecated the feature in BIND9: (from BIND9 ARM) "This is now considered a bad idea and BIND 9 never does it." I don't know the full detail of this discussion, but there should be a clear reason for this. [going to the last paragraph of Section 4.5] To simplify the situation, it is recommended to use the same TTL for all the records referring to the same name. However, there are some scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where a different strategy is preferable. As I already said, "recommended" is too a strong word, IMO. I'd also like to add a note that applications should not make or depend on a particular assumption on the content of the additional section. So, I'd revise this part like this: To simplify the situation, it might help to use the same TTL for all the resource record sets referring to the same name, unless there is a particular reason for not doing so. However, there are some scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where a different strategy is preferable. Thus, applications that use the response should not rely on a particular TTL configuration. For example, even if an application gets a response that only has the A record in the example described above, it should not assume there is no AAAA record for "foo.example.com". Instead, the application should try to fetch the missing records by itself if it needs the record. (Note that I use "resource record set(s)" instead of just "record(s)" where I think more appropriate). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 20 16:50:25 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23421 for ; Tue, 20 Apr 2004 16:50:24 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3KJnESQ018789 for ; Tue, 20 Apr 2004 12:49:15 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3KJnEEW018784 for dnsop-outgoing; Tue, 20 Apr 2004 12:49:14 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3KJnDP5018682 for ; Tue, 20 Apr 2004 12:49:13 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17621; Tue, 20 Apr 2004 15:49:06 -0400 (EDT) Message-Id: <200404201949.PAA17621@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dnsop@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-ipv6-dns-issues-05.txt Date: Tue, 20 Apr 2004 15:49:06 -0400 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Operational Considerations and Issues with IPv6 DNS Author(s) : A. Durand, et al. Filename : draft-ietf-dnsop-ipv6-dns-issues-05.txt Pages : 24 Date : 2004-4-20 This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehaviour, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-dnsop-ipv6-dns-issues-05.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-ietf-dnsop-ipv6-dns-issues-05.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: <2004-4-20160451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsop-ipv6-dns-issues-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160451.I-D@ietf.org> --OtherAccess-- --NextPart-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 22 12:35:48 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09021 for ; Thu, 22 Apr 2004 12:35:48 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3MF60I8011164 for ; Thu, 22 Apr 2004 08:06:00 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3MF60c8011155 for dnsop-outgoing; Thu, 22 Apr 2004 08:06:00 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3MF5xa5011114 for ; Thu, 22 Apr 2004 08:05:59 -0700 (PDT) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3MF5wUB020825; Thu, 22 Apr 2004 08:05:58 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3MF5w9e020824; Thu, 22 Apr 2004 08:05:58 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Apr 2004 08:05:58 -0700 From: David Meyer To: dnsop@lists.uoregon.edu Cc: sra@hactrn.net Subject: [dnsop] please take a look at draft-ietf-dnsop-ipv6-dns-issues-05.txt Message-ID: <20040422150558.GA20804@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: David Meyer Folks, Please have a look and post any comments you may have to the list. We're looking to finish this one up, and your input is essential. Thanks, Dave . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 22 14:25:54 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15996 for ; Thu, 22 Apr 2004 14:25:54 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3MGnsJg008705 for ; Thu, 22 Apr 2004 09:49:54 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3MGnsH6008701 for dnsop-outgoing; Thu, 22 Apr 2004 09:49:54 -0700 (PDT) Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3MGnq35008627 for ; Thu, 22 Apr 2004 09:49:53 -0700 (PDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BGhGS-000669-IF; Thu, 22 Apr 2004 12:41:28 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Subject: [dnsop] Last Call: 'DNS IPv6 transport operational guidelines' to BCP Message-Id: Date: Thu, 22 Apr 2004 12:41:28 -0400 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: The IESG The IESG has received a request from the Domain Name System Operations WG to consider the following document: - 'DNS IPv6 transport operational guidelines ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-05-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-transport-guidelines-0 2.txt . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 22 22:40:54 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21831 for ; Thu, 22 Apr 2004 22:40:53 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3N1CfQt006101 for ; Thu, 22 Apr 2004 18:12:41 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3N1Cfsw006085 for dnsop-outgoing; Thu, 22 Apr 2004 18:12:41 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3N1Cepw005880 for ; Thu, 22 Apr 2004 18:12:40 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3855:cf50:dec5:18f1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BF86415210; Fri, 23 Apr 2004 10:12:38 +0900 (JST) Date: Fri, 23 Apr 2004 10:12:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: David Meyer Cc: dnsop@lists.uoregon.edu, sra@hactrn.net Subject: Re: [dnsop] please take a look at draft-ietf-dnsop-ipv6-dns-issues-05.txt In-Reply-To: <20040422150558.GA20804@1-4-5.net> References: <20040422150558.GA20804@1-4-5.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Fri_Apr_23_10:12:44_2004-1" Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= --Multipart_Fri_Apr_23_10:12:44_2004-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Thu, 22 Apr 2004 08:05:58 -0700, >>>>> David Meyer said: > Please have a look and post any comments you may have to > the list. We're looking to finish this one up, and your > input is essential. At first glance, the 05 revision does not address my last message about "different TTLs for A and AAAA" (attached below). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Fri_Apr_23_10:12:44_2004-1 Content-Type: message/rfc822 Return-Path: X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Tue Apr 20 16:57:04 2004 Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.2.4) for jinmei@localhost (single-drop); Tue, 20 Apr 2004 17:04:15 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [3ffe:501:100f:0:220:edff:fe2b:92c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DDD1A15210 for ; Tue, 20 Apr 2004 16:57:04 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id CEC8B33089 for ; Tue, 20 Apr 2004 16:57:04 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id QAA08776 for ; Tue, 20 Apr 2004 16:57:04 +0900 (JST) Received: from mx.toshiba.co.jp (mx1.toshiba.co.jp [133.199.160.215]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id i3K7v4127222 for ; Tue, 20 Apr 2004 16:57:04 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id QAA27044; Tue, 20 Apr 2004 16:57:03 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3K7v2a3010035 for ; Tue, 20 Apr 2004 16:57:03 +0900 (JST) Received: from darkwing.uoregon.edu (darkwing.uoregon.edu [128.223.142.13]) by inet-tsb5.toshiba.co.jp with ESMTP id i3K7v0Bh005308 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 20 Apr 2004 16:57:01 +0900 (JST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3K6SRom016124 for ; Mon, 19 Apr 2004 23:28:27 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3K6SRPu016120 for dnsop-outgoing; Mon, 19 Apr 2004 23:28:27 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3K6SPdd016008 for ; Mon, 19 Apr 2004 23:28:26 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a5ff:aefb:fee7:dff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 422DF15214; Tue, 20 Apr 2004 15:28:25 +0900 (JST) Date: Tue, 20 Apr 2004 15:28:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-UIDL: i>>>> On Mon, 19 Apr 2004 22:09:23 +0300 (EEST), >>>>> Pekka Savola said: > However, I think I have to disagree with the last paragraph a bit. I > don't think it's feasible to require you to do special queries in case > you have IPv6 connectivity, just in case there would be IPv6 records > which had been omitted from the caches. The SMTP servers should not > have to have any such code at all; they should just take whatever they > are given when they send a MX query and be happy with it. Forcing any > IPv6-capable SMTP server to perform a mostly useless AAAA query seems > like a waste of time and bits. > But as this is the current specification situation, there's not much > one can do about it. If you want to be positively sure that you > always get all the records, you have to query them explicitly > yourself, with the record type you're interested in getting. Okay, so I guess my position is not so different than yours...but one thing I'd like to emphasize is that the application (the SMTP server in this case) should not assume anything in the additional section, and should basically have the ability to fetch missing additional data. In that sense, I disagree on your saying that "the SMTP servers should not have to have any such code at all". But at the same time, it's okay for me to mention that it may help if we use the same TTL for A and AAAA RRsets in this type of case. It's just a tip that may optimize the thing, though; I think "recommendation" is a strong word for this. >> However, I still don't understand why we should >> mention this in the first place. Actually, as explained in item 2, >> "it is impossible to guarantee that in fact we would always get back >> all the records". Even if we use the same TTL for the A and AAAA RRs >> in this example, the caching server can still have a "partial" result, >> e.g., due to packet size issues. On the other hand, we may even want >> to use different TTL intentionally, as I explained in my first >> message. > I think it might be useful to try to describe these TTL issues > explicitly, as I their impact hasn't been clearly spelled out wrt. > records of different types.. Okay. >> Finally, I don't see why the third case below is problematic (BTW: I'm >> now confused with the wording of "impartial" there. What does this >> actually mean?) > See above for my belief that we should not have to burden all the SMTP > servers in the world to make unnecessary queries just to confirm there > was no IPv6 address for the MX record; the steps described in here go > a long way in that direction. > I've reworded impartial here. As RRsets can't be broken up, it was > used to refer to "both A and AAAA records exists, but a cache returned > only one kind of them". I couldn't find a better word (suggestions?) > but I've reworded it out of these now. Hmm, the sense was not really clear at least to me with the literal meaning of "impartial". But I'm not an expert on English wording and I don't have a better suggestion, so I'd leave this to you (I mean it's okay if you want to keep it). (Note that the latest version of 05pre still has this term in Section 4.4, which has been Sect. 4.5 so far). The following is my comment on the latest 05pre revision of the draft (MD5 fingerprint is d59264c3f988a8fc132bc88c6c3de557). Notice that I only read Sections 4.4 and 4.5. 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments Consider thes case where the query name is so long, the number of the s/thes/the/ additional records (originated from "glue") is so high, or for other reasons that the response must either be truncated (leading to a retry with TCP) or some of the additional data removed from the reply. It's hard to parse the part "or some of the...from the reply". Do you mean: ...or for other reasons that the response must be truncated (leading to a retry with TCP) or some of the additional data must be removed from the reply. ? In the last paragraph, ... The operational fix for this is having the DNS server implementations return a warning when the administrators create the zones which would result in too much additional data being returned. I think this statement is too strong, since it sounds like this is the only operational fix. I'd suggest to reword this e.g., "An operational fix for this", etc. 4.5 The Use of TTL for IPv4 and IPv6 RRs 3. We only get back A or AAAA records even if both existed: this is indistinguishable from the previous case, and problematic as described in the next section. s/next/previous/ ? As a more essential comment, it's still not clear to me what the problem described in the previous section is...are you particularly referring to the 3rd paragraph of Section 4.4, that is, (e.g.) returning A records to an IPv6-only node? So, we assume we get back both A and AAAA records of foo.example.com, or the resolver explicitly asks, in two separate queries, both A and AAAA records. After 100 seconds, the AAAA record is removed from the cache because its TTL expired. It would be useful for the cache to re-query the AAAA record or discard the A record when the shorter TTL (in this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. However, this is not mandated or mentioned by the specification(s). This paragraph seems to have several problems: 1. it's not clear to me why this paragraph begins with "So,". Do you mean something like this? "In order to discuss the case where we have both A and AAAA records, let's assume we get back both records of foo.example.com, or the resolver explicitly asks, in two separate queries, both A and AAAA records." 2. in this paragraph, you used the term "resolver". But I'm not sure what it exactly specifies, partly because you also used the term "caching resolver" in this section...does the "resolver" mean the "caching resolver" or the (so-called) "stub resolver"? Similarly, if you mean the "caching resolver" in "It would be useful for the cache to..." (I believe you do), then I'd suggest to reword it as "It would be useful for the caching resolver to...". 3. it might be controversial whether "it would be useful for the cache to re-query the AAAA record". This behavior is similar to BIND8's "fetch-glue" feature (though the caching server with fetch-glue being on does not return the missing additional data to the stub resolver during re-fetching it). But ISC has deprecated the feature in BIND9: (from BIND9 ARM) "This is now considered a bad idea and BIND 9 never does it." I don't know the full detail of this discussion, but there should be a clear reason for this. [going to the last paragraph of Section 4.5] To simplify the situation, it is recommended to use the same TTL for all the records referring to the same name. However, there are some scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where a different strategy is preferable. As I already said, "recommended" is too a strong word, IMO. I'd also like to add a note that applications should not make or depend on a particular assumption on the content of the additional section. So, I'd revise this part like this: To simplify the situation, it might help to use the same TTL for all the resource record sets referring to the same name, unless there is a particular reason for not doing so. However, there are some scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where a different strategy is preferable. Thus, applications that use the response should not rely on a particular TTL configuration. For example, even if an application gets a response that only has the A record in the example described above, it should not assume there is no AAAA record for "foo.example.com". Instead, the application should try to fetch the missing records by itself if it needs the record. (Note that I use "resource record set(s)" instead of just "record(s)" where I think more appropriate). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html --Multipart_Fri_Apr_23_10:12:44_2004-1-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 23 07:19:25 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28173 for ; Fri, 23 Apr 2004 07:19:24 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3NAE7wT029576 for ; Fri, 23 Apr 2004 03:14:07 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3NAE7f5029572 for dnsop-outgoing; Fri, 23 Apr 2004 03:14:07 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3NAE5bt029173 for ; Fri, 23 Apr 2004 03:14:05 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3NADsQ27473; Fri, 23 Apr 2004 13:13:54 +0300 Date: Fri, 23 Apr 2004 13:13:54 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Hi, Thanks for the insistence. I think this should address your concerns.. Working copies at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre-diff.html http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre.txt (I've only changed what you're commenting, and what Iljitsch was saying about DNS resolver discovery on v6-only networks.) On Tue, 20 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > But as this is the current specification situation, there's not much > > one can do about it. If you want to be positively sure that you > > always get all the records, you have to query them explicitly > > yourself, with the record type you're interested in getting. > > Okay, so I guess my position is not so different than yours...but one > thing I'd like to emphasize is that the application (the SMTP server > in this case) should not assume anything in the additional section, > and should basically have the ability to fetch missing additional > data. In that sense, I disagree on your saying that "the SMTP servers > should not have to have any such code at all". > > But at the same time, it's okay for me to mention that it may help if > we use the same TTL for A and AAAA RRsets in this type of case. It's > just a tip that may optimize the thing, though; I think > "recommendation" is a strong word for this. I'm not sure if I fully agree with this but as I don't have a strong opinion, I've just taken what you say. > Hmm, the sense was not really clear at least to me with the literal > meaning of "impartial". But I'm not an expert on English wording and > I don't have a better suggestion, so I'd leave this to you (I mean > it's okay if you want to keep it). (Note that the latest version of > 05pre still has this term in Section 4.4, which has been Sect. 4.5 so > far). I reworded that to "missing some RRsets". > additional records (originated from "glue") is so high, or for other > reasons that the response must either be truncated (leading to a > retry with TCP) or some of the additional data removed from the > reply. > > It's hard to parse the part "or some of the...from the reply". Do you > mean: > > ...or for other reasons that the response must be truncated (leading > to a retry with TCP) or some of the additional data must be removed > from the reply. > ? Yes, changed. > In the last paragraph, > ... The operational fix > for this is having the DNS server implementations return a warning > when the administrators create the zones which would result in too > much additional data being returned. > > I think this statement is too strong, since it sounds like this is the > only operational fix. I'd suggest to reword this e.g., "An > operational fix for this", etc. Agree, changed. > 4.5 The Use of TTL for IPv4 and IPv6 RRs > > 3. We only get back A or AAAA records even if both existed: this is > indistinguishable from the previous case, and problematic as > described in the next section. > > s/next/previous/ ? OK > As a more essential comment, it's still not clear to me what the > problem described in the previous section is...are you particularly > referring to the 3rd paragraph of Section 4.4, that is, (e.g.) > returning A records to an IPv6-only node? Yes, that's the problem. I can't think of ways to make it clearer. (I'd also like to get to the situation where every v6 enabled node that would prefer to use v6 if possible wouldn't have to do an explicit query for AAAA records every time it's sending mail...) > So, we assume we get back both A and AAAA records of foo.example.com, > or the resolver explicitly asks, in two separate queries, both A and > AAAA records. After 100 seconds, the AAAA record is removed from the > cache because its TTL expired. It would be useful for the cache to > re-query the AAAA record or discard the A record when the shorter TTL > (in this case, for the AAAA record) expires; this would avoid the > situation where there would be a window of 200 seconds when > incomplete information is returned from the cache. However, this is > not mandated or mentioned by the specification(s). > > This paragraph seems to have several problems: > > 1. it's not clear to me why this paragraph begins with "So,". Do you > mean something like this? > "In order to discuss the case where we have both A and AAAA > records, let's assume we get back both records of foo.example.com, > or the resolver explicitly asks, in two separate queries, both A > and AAAA records." Not quite. The target might have both A and AAAA records, but the resolving host might only get back one set of these. We discussed the other case in previous section, so rewording this to: As the third case was considered in the previous section, we assume we get back both A and AAAA records of foo.example.com, or the stub resolver explicitly asks, in two separate queries both A and AAAA records. [...] > 2. in this paragraph, you used the term "resolver". But I'm not sure > what it exactly specifies, partly because you also used the term > "caching resolver" in this section...does the "resolver" mean the > "caching resolver" or the (so-called) "stub resolver"? Similarly, > if you mean the "caching resolver" in "It would be useful for the > cache to..." (I believe you do), then I'd suggest to reword it as > "It would be useful for the caching resolver to...". In the above paragraph, "resolver" meant the stub resolver. Reworded. I don't think we can get much more by honing the terminology as stub resolvers can also include caching, but changed to like: After 100 seconds, the AAAA record is removed from the cache(s) because its TTL expired. It would be useful for the caching resolvers to discard the A record when the shorter TTL (in this case, for the AAAA record) expires; [...] > 3. it might be controversial whether "it would be useful for the cache > to re-query the AAAA record". This behavior is similar to BIND8's > "fetch-glue" feature (though the caching server with fetch-glue > being on does not return the missing additional data to the stub > resolver during re-fetching it). But ISC has deprecated the > feature in BIND9: (from BIND9 ARM) "This is now considered a bad > idea and BIND 9 never does it." I don't know the full detail of > this discussion, but there should be a clear reason for this. OK, I'm fine with dropping re-querying unless there are other opinions; I'll just keep the discarding part. (See above.) > [going to the last paragraph of Section 4.5] > To simplify the situation, it is recommended to use the same TTL for > all the records referring to the same name. However, there are some > scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where > a different strategy is preferable. > > As I already said, "recommended" is too a strong word, IMO. I'd also > like to add a note that applications should not make or depend on a > particular assumption on the content of the additional section. So, > I'd revise this part like this: > > To simplify the situation, it might help to use the same TTL for > all the resource record sets referring to the same name, unless > there is a particular reason for not doing so. However, there are > some scenarios (e.g., when renumbering IPv6 but keeping IPv4 > intact) where a different strategy is preferable. > > Thus, applications that use the response should not rely on a > particular TTL configuration. For example, even if an application > gets a response that only has the A record in the example described > above, it should not assume there is no AAAA record for > "foo.example.com". Instead, the application should try to fetch > the missing records by itself if it needs the record. > > (Note that I use "resource record set(s)" instead of just "record(s)" > where I think more appropriate). I don't think "recommends" is too strong, but I took you suggestion. (I also changed some "record(s)" to "RRset(s)" elsewhere in the document where that is appropriate.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 23 14:04:32 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23983 for ; Fri, 23 Apr 2004 14:04:31 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3NGhLw0029753 for ; Fri, 23 Apr 2004 09:43:21 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3NGhLin029749 for dnsop-outgoing; Fri, 23 Apr 2004 09:43:21 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3NGhKRr029641 for ; Fri, 23 Apr 2004 09:43:20 -0700 (PDT) Received: from orodruin.hactrn.net (pcp01379627pcs.levtwn01.pa.comcast.net [68.81.95.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "orodruin.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 81A882B6 for ; Fri, 23 Apr 2004 12:43:14 -0400 (EDT) Received: from orodruin.hactrn.net (localhost [IPv6:::1]) by orodruin.hactrn.net (Postfix) with ESMTP id 98B883D for ; Fri, 23 Apr 2004 16:43:03 +0000 (GMT) Date: Fri, 23 Apr 2004 12:43:02 -0400 From: Rob Austein To: dnsop@lists.uoregon.edu Subject: Re: DNS resolver discovery text [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt] In-Reply-To: References: <4.3.2.7.2.20040416075456.02a9c248@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 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: <20040423164303.98B883D@orodruin.hactrn.net> Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Rob Austein At Sat, 17 Apr 2004 10:29:22 +0300 (EEST), Pekka Savola wrote: > On Fri, 16 Apr 2004, Ralph Droms wrote: > > Also - I finally got around to reviewing why the DHCP option is > > called "DNS Recursive Name Server". Turns out RFC 1035 refers to > > "recursive server" (top of page 7) and "recursive service" (several > > places), so we used the name "DNS Recursive Name Server" for the option. > > It might be appropriate to retitle this section to be "Obtaining a > > List of DNS Recursive Servers". > > I changed this as well, even though I think "resolvers" is a better > word for this, and already being used in other documents. If others > have arguments about this, please speak up ASAP. Sorry not to have caught this question sooner. Short answer: Ralph was right, the correct term is "recursive name server". That's the closest thing we have to standard term for a name server supporting recursive service (ie, an entity which accepts DNS messages with QR=0, RD=1 and replies with messages with QR=1, RA=1). "Resolver" just means an entity which sends messages with QR=0 and receives messages with QR=1. "Resolver" without further qualification does not specify the query mode in which the resolver operates (recursive or iterative). Name server just means an entity which receives messages with QR=0 and replies with messages with QR=1. An entity which both sends and receives both queries and responses is both a name server and a resolver (hence much of the confusion), but, at the conceptual level, it's a name server glued back to back with a resolver, with communciation between the two to handle recursive mode queries. "Recursive server", or, more properly, "recursive name server", means a name server which offers recursive service, ie, a name server which a recursive-mode resolver might expect to do something useful if sent a query with RD=1. Please also see the discussion in draft-ietf-dnsext-dnssec-intro, which not only goes into a bit more detail but also tries to expand this terminology to cope with the joys of DNSSEC. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 26 08:55:36 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16990 for ; Mon, 26 Apr 2004 08:55:36 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3QBR89g003265 for ; Mon, 26 Apr 2004 04:27:08 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3QBR8VN003264 for dnsop-outgoing; Mon, 26 Apr 2004 04:27:08 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3QBR64Y003251 for ; Mon, 26 Apr 2004 04:27:07 -0700 (PDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:2834:ea71:b127:d17f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BF56915210; Mon, 26 Apr 2004 20:27:04 +0900 (JST) Date: Mon, 26 Apr 2004 20:27:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Fri, 23 Apr 2004 13:13:54 +0300 (EEST), >>>>> Pekka Savola said: > Thanks for the insistence. I think this should address your > concerns.. Thanks for your patience. The 06pre revision basically looks fine, and I can live with it. However, IMO it could use further clarification on missing records in the additional section. As someone has already pointed out in this list (if I remember correctly), the level of the problem of missing additional records differs between "glue" records and other additional data. The "glue" case: consider a zone delegation with the following configuration: child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN A 192.0.2.2 ... ns.child.example.com. IN A 192.0.2.X ns.child.example.com. IN AAAA 2001:db8::1 ns.child.example.com. IN AAAA 2001:db8::2 ... ns.child.example.com. IN AAAA 2001:db8::Y (where X and Y are some large numbers) when a caching resolver tries to resolve a name under child.example.com, it will get the NS record from the parent zone (example.com.) and the glue A and AAAA RRset. If either or both RRsets must be removed from the additional section and the caching resolver cannot get an appropriate RRset for transport available for the resolver, this is a critical problem; there is no other workaround for this problem. (The problem can happen even without AAAA (or A), and in that sense, this is not specific to IPv6. But adding AAAA can increase the risk of missing additional data, so this is a kind of IPv6-related problem.) On the other hand, in the case of other additional data, just like described in the example of Section 4.5, the problem is not critical; the final user (application) of the missing record can issue another query to fetch it. Even though it makes additional delay or consumption of network resource, at least we have a workaround. So, the desirable logic in Sections 4.4 and 4.5 is, IMO, as follows: - Section 4.4 + there are two types of problems caused by missing additional data. + one of the problems is critical. the other can cause suboptimal results, but there are workarounds + for both problems, a protocol fix (EDNS0) and an operational fix can be considered. + for the non critical problem, the application should be careful to not make the problem critical (perhaps we should move the last paragraph of Section 4.5 here) (other considerations, such as the one described in the second paragraph of the current document) - Section 4.5 different TTLs for A and AAAA can cause a similar problem as the non-critical one described in Section 4.4. Using the same TTL might be useful to minimize the problematic cases. Still, applications should be careful enough. Again, I can live with the current text in 06pre. I'd leave it to you whether to adopt the revised logic. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Mon Apr 26 16:46:24 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18305 for ; Mon, 26 Apr 2004 16:46:23 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3QJQ7TH008041 for ; Mon, 26 Apr 2004 12:26:07 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3QJQ70r008036 for dnsop-outgoing; Mon, 26 Apr 2004 12:26:07 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3QJQ5ar007972 for ; Mon, 26 Apr 2004 12:26:06 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13153; Mon, 26 Apr 2004 15:26:02 -0400 (EDT) Message-Id: <200404261926.PAA13153@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dnsop@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt Date: Mon, 26 Apr 2004 15:26:02 -0400 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Requiring DNS IN-ADDR Mapping Author(s) : D. Senie Filename : draft-ietf-dnsop-inaddr-required-05.txt Pages : 5 Date : 2004-4-26 Mapping of addresses to names has been a feature of DNS. Many sites, implement it, many others don't. Some applications attempt to use it as a part of a security strategy. The goal of this document is to encourage proper deployment of address to name mappings, and provide guidance for their use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-inaddr-required-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-dnsop-inaddr-required-05.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-ietf-dnsop-inaddr-required-05.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: <2004-4-26150356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsop-inaddr-required-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsop-inaddr-required-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-26150356.I-D@ietf.org> --OtherAccess-- --NextPart-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 27 11:59:10 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08927 for ; Tue, 27 Apr 2004 11:59:09 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3REQZLj003490 for ; Tue, 27 Apr 2004 07:26:35 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3REQZtA003486 for dnsop-outgoing; Tue, 27 Apr 2004 07:26:35 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3REQXCF003366 for ; Tue, 27 Apr 2004 07:26:33 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3REQNX16775; Tue, 27 Apr 2004 17:26:23 +0300 Date: Tue, 27 Apr 2004 17:26:23 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Mon, 26 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > So, the desirable logic in Sections 4.4 and 4.5 is, IMO, as follows: > > - Section 4.4 > + there are two types of problems caused by missing additional > data. > + one of the problems is critical. the other can cause suboptimal > results, but there are workarounds > + for both problems, a protocol fix (EDNS0) and an operational fix > can be considered. > + for the non critical problem, the application should be careful to > not make the problem critical (perhaps we should move the last > paragraph of Section 4.5 here) > (other considerations, such as the one described in the second > paragraph of the current document) > > - Section 4.5 > different TTLs for A and AAAA can cause a similar problem as the > non-critical one described in Section 4.4. Using the same TTL might > be useful to minimize the problematic cases. Still, applications > should be careful enough. Agreed. I've updated the text a bit, trying to make this clearer: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre-diff.html http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre.txt Please see if these reflect to what you had in mind; I'm hoping of submitting this within a day. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 27 12:42:05 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11073 for ; Tue, 27 Apr 2004 12:42:04 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3RFIm0f005749 for ; Tue, 27 Apr 2004 08:18:48 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3RFImWB005747 for dnsop-outgoing; Tue, 27 Apr 2004 08:18:48 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3RFIlFI005714 for ; Tue, 27 Apr 2004 08:18:47 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:55f5:b9b3:5cfe:65b3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E83A515210; Wed, 28 Apr 2004 00:18:45 +0900 (JST) Date: Wed, 28 Apr 2004 00:18:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by darkwing.uoregon.edu id i3RFImFI005731 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Content-Transfer-Encoding: 8bit >>>>> On Tue, 27 Apr 2004 17:26:23 +0300 (EEST), >>>>> Pekka Savola said: > I've updated the text a bit, trying to make this clearer: > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre-diff.html > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre.txt > Please see if these reflect to what you had in mind; I'm hoping of > submitting this within a day. From a quick check, I suspect you typed the keyboard too fast, because I could not understand the following part In other words, there are two kinds of additional data: the kind that must be included (all RRsets) no matter what (an example of this is below), and the kind which could be omitted in full or in part, but could cause nonoptimal results (an example of this is in the next section): child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN AAAA 2001:db8::Y I'm even not sure if this is a complete set of paragraphs you intended to add... Another minor nit: Additionally, to avoid the case where an application would not get an address at all due to non-critical additional data being omitted, the applications should be able to query the specific records of the desired protocol, not just rely getting all the required RRsets in the additional section. I guess "rely getting" should actually be "rely on getting". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 27 16:24:08 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27457 for ; Tue, 27 Apr 2004 16:24:08 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3RJJjdX008477 for ; Tue, 27 Apr 2004 12:19:45 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3RJJjuR008473 for dnsop-outgoing; Tue, 27 Apr 2004 12:19:45 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3RJJh5b008362 for ; Tue, 27 Apr 2004 12:19:43 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3RJJW121441; Tue, 27 Apr 2004 22:19:32 +0300 Date: Tue, 27 Apr 2004 22:19:32 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Wed, 28 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Tue, 27 Apr 2004 17:26:23 +0300 (EEST), > >>>>> Pekka Savola said: > > > I've updated the text a bit, trying to make this clearer: > > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre-diff.html > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre.txt > > > Please see if these reflect to what you had in mind; I'm hoping of > > submitting this within a day. > > From a quick check, I suspect you typed the keyboard too fast, because > I could not understand the following part > > In other words, there are two kinds of additional data: the kind that > must be included (all RRsets) no matter what (an example of this is > below), and the kind which could be omitted in full or in part, but > could cause nonoptimal results (an example of this is in the next > section): > > child.example.com. IN NS ns.child.example.com. > ns.child.example.com. IN A 192.0.2.1 > ns.child.example.com. IN AAAA 2001:db8::Y > > I'm even not sure if this is a complete set of paragraphs you intended > to add... Hmm. I can find no problems with this. What may be confusing is at the end I said next _section_, not next paragraph, and the example I quoted from you relates to the first case. I tried to reword it for clarity: ======= In other words, there are two kinds of additional data: 1. "critical" additional data; this must be included (all the possible RRsets) in all scenarios, and 2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as well. An example of the latter are A/AAAA records in conjunction of MX records as shown in the next section; an example of the former is shown below: child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN AAAA 2001:db8::Y In the case of too much additional data, [...] ======= Is this better? > Another minor nit: > > Additionally, to avoid the case where an application would not get an > address at all due to non-critical additional data being omitted, the > applications should be able to query the specific records of the > desired protocol, not just rely getting all the required RRsets in > the additional section. > > I guess "rely getting" should actually be "rely on getting". Yep. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 27 22:20:59 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17835 for ; Tue, 27 Apr 2004 22:20:58 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3S04GEc015078 for ; Tue, 27 Apr 2004 17:04:16 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3S04Fmc015077 for dnsop-outgoing; Tue, 27 Apr 2004 17:04:15 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3S04DZ3015054 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 27 Apr 2004 17:04:15 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i3S03gLV030412 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Apr 2004 20:03:42 -0400 Date: Tue, 27 Apr 2004 20:03:42 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Internet-Drafts@ietf.org cc: i-d-announce@ietf.org, Subject: Re: [dnsop] I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt In-Reply-To: <200404261926.PAA13153@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Dean Anderson This draft was already discussed and rejected. I note that the draft 04 has been deleted from the IETF site. Instead of addressing any of the many previous issues addressed against the 04 draft, as demonstrated by reviewing the archives of that discussion, it simply rehashes the same wrong claims made by the 04 draft. Indeed, it was pointed out that it does not accurately state ARIN's policy on the subject. This was just one of _many_ problems, but probably the easiest to fix. It is practically an insult to resubmit this draft in its present form. So, why is it coming up again? Can we finally kill this once and for all? --Dean ***In fact, according to Leslie Nobile, ARIN is considering dropping in-addr support in the future, and has gone so far as to engage its attorney's to research the question of whether it is obligated to provide the service. Their lawyers say they are not obligated. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 28 04:01:12 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29912 for ; Wed, 28 Apr 2004 04:01:12 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3S6WNMB011692 for ; Tue, 27 Apr 2004 23:32:23 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3S6WNkQ011691 for dnsop-outgoing; Tue, 27 Apr 2004 23:32:23 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3S6WLHp011665 for ; Tue, 27 Apr 2004 23:32:22 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:55f5:b9b3:5cfe:65b3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5BB8A15210; Wed, 28 Apr 2004 15:32:21 +0900 (JST) Date: Wed, 28 Apr 2004 15:32:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Tue, 27 Apr 2004 22:19:32 +0300 (EEST), >>>>> Pekka Savola said: > ======= > In other words, there are two kinds of additional data: > 1. "critical" additional data; this must be included (all the > possible RRsets) in all scenarios, and > 2. "courtesy" additional data; this could be sent in full, with only > a few RRsets, or with no RRsets, and can be fetched separately as > well. > An example of the latter are A/AAAA records in conjunction of MX > records as shown in the next section; an example of the former is > shown below: > child.example.com. IN NS ns.child.example.com. > ns.child.example.com. IN A 192.0.2.1 > ns.child.example.com. IN AAAA 2001:db8::Y > In the case of too much additional data, [...] > ======= > Is this better? Yes, but I still have a couple of concerns: 1. it's not very clear how the first and second paragraphs relate each other with the phrase 'In other words'. I guess you intended to emphasize that the following sentence in the first paragraph However, note that if too much additional information that is not strictly necessary would be added, one should remove unnecessary information instead of setting TC bit for this "courtesy" information [19]. is the second one (item 2) in the classification of the second paragraph. However, the first paragraph does not seem to talk about the "critical" kind of additional data, so it is a little bit strange to see "In other words" at the beginning of the second paragraph. Additionally, the first paragraph contains supplemental description which is not directly related to the classification in the second paragraph: the fact that RRsets cannot be broken up. This also causes the confusion. 2. it is confusing to use "2001:db8::Y" without explaining what Y means. In this context, I guess you could simply use an arbitrary hex value, e.g., "2001:db8::2". ------------ end of concerns ------------ So, I'd totally revise the beginning of this section (including the first and second paragraphs) as follows: Consider the case where the query name is so long, the number of the additional records (originated from "glue") is so high, or for other reasons that the entire response would not fit in a single UDP packet. In some cases, the responder truncates the response with the TC bit being set (leading to a retry with TCP), in order for the querier to get the entire response later. However, note that if too much additional information that is not strictly necessary would be added, one should remove unnecessary information instead of setting TC bit for this "courtesy" information [19]. Also notice that there are two kinds of additional data: 1. "critical" additional data; this must be included (all the possible RRsets) in all scenarios, and 2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as well. Meanwhile, resource record sets (RRsets) are never "broken up", so if a name has 4 A records and 5 AAAA records, you can either return all 9, all 4 A records, all 5 AAAA records or nothing. Notice that for the "critical" additional data all the latter three cases can be critical. In other words, there are two kinds of additional data: the kind that must be included (all RRsets) no matter what (an example of this is below), and the kind which could be omitted in full or in part, but could cause nonoptimal results (an example of this is in the next section): An example of the "courtesy" additional data is A/AAAA records in conjunction of MX records as shown in the next section; an example of the "critical" additional data is shown below: child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN AAAA 2001:db8::2 (where the lack of either A or AAAA RRsets can be critical) ------------- One additional comment: reconsidering the entire context, I guess the first sentence of the following paragraph should be clarified: In the case of too much additional data, it might be tempting to not return the AAAA records if the transport for DNS query was IPv4, or not return the A records, if the transport was IPv6. to, e.g., In the case of too much "courtesy" additional data, ... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 28 05:19:00 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02092 for ; Wed, 28 Apr 2004 05:18:59 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3S7rkQh027053 for ; Wed, 28 Apr 2004 00:53:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3S7rkjv027052 for dnsop-outgoing; Wed, 28 Apr 2004 00:53:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3S7riaE026985 for ; Wed, 28 Apr 2004 00:53:44 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3S7rXi00886; Wed, 28 Apr 2004 10:53:33 +0300 Date: Wed, 28 Apr 2004 10:53:33 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Wed, 28 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > So, I'd totally revise the beginning of this section (including the > first and second paragraphs) as follows: I agree with you. I've taken almost all of what you suggest, with a few touches; the most important of them were: - remove the mostly redundant "In other words" paragraph, integrate it with the earlier numbered list. - add an explicit note that it would be better to omit all of courtesy additional data (now that we have a semantic difference) rather than returning only some RRsets. - I didn't understand what you wrote about the all "all the latter three cases", so I reworded that. - some minor changes. (See below for text.) > One additional comment: reconsidering the entire context, I guess the > first sentence of the following paragraph should be clarified: > > In the case of too much additional data, it might be tempting to not > return the AAAA records if the transport for DNS query was IPv4, or > not return the A records, if the transport was IPv6. > > to, e.g., > > In the case of too much "courtesy" additional data, ... Did we (as WG) already agree that it's better to set TC bit than return only some RRsets of critical additional data? I'd love that kind of resulution, but for now, I put "(whether courtesy or critical)" there. If folks have strong feelings of this, let's start a new thread explicitly only about this. In any case, I've updated the documents at the same locations, and included the current section 4.4. below. ===== 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments Consider the case where the query name is so long, the number of the additional records (originated from "glue") is so high, or for other reasons that the entire response would not fit in a single UDP packet. In some cases, the responder truncates the response with the TC bit being set (leading to a retry with TCP), in order for the querier to get the entire response later. However, note that if too much additional information that is not strictly necessary would be added, one should remove unnecessary information instead of setting TC bit for this "courtesy" information [19]. Also notice that there are two kinds of additional data: 1. "critical" additional data; this must be included (all the possible RRsets) in all scenarios, and 2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as well, but which could lead to non-optimal results. Meanwhile, resource record sets (RRsets) are never "broken up", so if a name has 4 A records and 5 AAAA records, you can either return all 9, all 4 A records, all 5 AAAA records or nothing. Notice that for the "critical" additional data getting all the RRsets can be critical. An example of the "courtesy" additional data is A/AAAA records in conjunction of MX records as shown in the next section; an example of the "critical" additional data is shown below (where the lack of either A or AAAA RRsets can be critical): child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN AAAA 2001:db8::1 In the case of too much additional data (whether courtesy or critical), it might be tempting to not return the AAAA records if the transport for DNS query was IPv4, or not return the A records, if the transport was IPv6. However, this breaks the model of independence of DNS transport and resource records, as noted in Section 1.2. This temptation would have significant problems in multiple areas. Remember that often the end-node, which will be using the records, is not the same one as the node requesting them from the authoritative DNS server (or even a caching resolver). So, whichever version the requestor ("the middleman") uses makes no difference to the ultimate user of the records. This might result in e.g., inappropriately returning A records to an IPv6-only node, going through a translation, or opening up another IP-level session (e.g., a PDP context [20]). The problem of too much additional data seems to be an operational one: the zone administrator entering too many records which will be returned either truncated or missing some RRsets to the users. A protocol fix for this is using EDNS0 [40] to signal the capacity for larger UDP packet sizes, pushing up the relevant threshold. Further, DNS server implementations should rather omit courtesy additional data completely rather than including only some RRsets. An operational fix for this is having the DNS server implementations return a warning when the administrators create the zones which would result in too much additional data being returned. Additionally, to avoid the case where an application would not get an address at all due to non-critical additional data being omitted, the applications should be able to query the specific records of the desired protocol, not just rely on getting all the required RRsets in the additional section. ==== . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 28 08:43:25 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12534 for ; Wed, 28 Apr 2004 08:43:25 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SBSv4q000734 for ; Wed, 28 Apr 2004 04:28:57 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3SBSvk4000733 for dnsop-outgoing; Wed, 28 Apr 2004 04:28:57 -0700 (PDT) Received: from tachyon.jinmei.org (kame207.kame.net [203.178.141.207]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SBSrD7000681 for ; Wed, 28 Apr 2004 04:28:56 -0700 (PDT) Received: from ocean.jinmei.org (unknown [2001:200:0:4819:1036:dc74:13f8:73e0]) by tachyon.jinmei.org (Postfix) with ESMTP id 258D6355E4; Wed, 28 Apr 2004 20:28:45 +0900 (JST) Date: Wed, 28 Apr 2004 20:28:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= >>>>> On Wed, 28 Apr 2004 10:53:33 +0300 (EEST), >>>>> Pekka Savola said: >> So, I'd totally revise the beginning of this section (including the >> first and second paragraphs) as follows: > I agree with you. > I've taken almost all of what you suggest, with a few touches; the > most important of them were: > - remove the mostly redundant "In other words" paragraph, integrate > it with the earlier numbered list. Ah, that should have been removed from the proposed text of mine. I was not careful enough. Removing this is of course fine. > - add an explicit note that it would be better to omit all of > courtesy additional data (now that we have a semantic difference) > rather than returning only some RRsets. Okay. I'm not sure if it is a good practice to remove the entire RRsets, but I don't oppose to suggesting that. > - I didn't understand what you wrote about the all "all the > latter three cases", so I reworded that. Okay. Perhaps the confusion came from that I intended to use the word "critical" for "critically bad" whereas you seem to have intended to use the same word for "critically important". I'm fine with rewording that part, but then in the following sentence (where the lack of either A or AAAA RRsets can be critical): it might be better to say "where getting both the A and AAAA RRsets is critical". >> One additional comment: reconsidering the entire context, I guess the >> first sentence of the following paragraph should be clarified: >> >> In the case of too much additional data, it might be tempting to not >> return the AAAA records if the transport for DNS query was IPv4, or >> not return the A records, if the transport was IPv6. >> >> to, e.g., >> >> In the case of too much "courtesy" additional data, ... > Did we (as WG) already agree that it's better to set TC bit than > return only some RRsets of critical additional data? I'd love that > kind of resulution, but for now, I put "(whether courtesy or > critical)" there. If folks have strong feelings of this, let's start > a new thread explicitly only about this. What I wanted to say is that in the critical case (particularly in the case of the glue for a delegation), it might make sense to organize the additional section based on the transport. In fact, if the respondiner is going to return a delegation to a caching (or recursive?) resolver using IPv4 transport, it is probably better to prefer A RRset (as glue) to AAAA. I basically support your opinion, though. As the draft says, it should be better to not combine the content with transport, based on the basic model of DNS. Also, we can even construct a case where the querier that receives the delegation in the above example can be just a "middle-node" and the real "user" exists behind the node. (e.g., there is a simple DNS forwarder to help IPv4<->IPv6 translation, which does not act as a recursive resolver - though this might be a tricky example). We could probably describe the subtle points, but this might be a minor detail, so, as a result, I can live with the current wording of yours. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 28 11:32:30 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21735 for ; Wed, 28 Apr 2004 11:32:30 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SDAnm9019866 for ; Wed, 28 Apr 2004 06:10:49 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3SDAnlS019864 for dnsop-outgoing; Wed, 28 Apr 2004 06:10:49 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SDAluh019807 for ; Wed, 28 Apr 2004 06:10:48 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3SDAaT06128; Wed, 28 Apr 2004 16:10:36 +0300 Date: Wed, 28 Apr 2004 16:10:36 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dnsop@lists.uoregon.edu Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Hi, I posted -06 document, which appears to be good for now. On Wed, 28 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > - add an explicit note that it would be better to omit all of > > courtesy additional data (now that we have a semantic difference) > > rather than returning only some RRsets. > > Okay. I'm not sure if it is a good practice to remove the entire > RRsets, but I don't oppose to suggesting that. OK. (There are certainly arguments both ways, but my main point was that the integrity of _all_ the information should be most important, except if there is no other choice.) > > - I didn't understand what you wrote about the all "all the > > latter three cases", so I reworded that. > > Okay. Perhaps the confusion came from that I intended to use the word > "critical" for "critically bad" whereas you seem to have intended to > use the same word for "critically important". I'm fine with rewording > that part, but then in the following sentence > > (where the lack of > either A or AAAA RRsets can be critical): > > it might be better to say "where getting both the A and AAAA RRsets is > critical". Changed. > >> One additional comment: reconsidering the entire context, I guess the > >> first sentence of the following paragraph should be clarified: > >> > >> In the case of too much additional data, it might be tempting to not > >> return the AAAA records if the transport for DNS query was IPv4, or > >> not return the A records, if the transport was IPv6. > >> > >> to, e.g., > >> > >> In the case of too much "courtesy" additional data, ... > > > Did we (as WG) already agree that it's better to set TC bit than > > return only some RRsets of critical additional data? I'd love that > > kind of resulution, but for now, I put "(whether courtesy or > > critical)" there. If folks have strong feelings of this, let's start > > a new thread explicitly only about this. > > What I wanted to say is that in the critical case (particularly in the > case of the glue for a delegation), it might make sense to organize > the additional section based on the transport. In fact, if the > respondiner is going to return a delegation to a caching (or > recursive?) resolver using IPv4 transport, it is probably better to > prefer A RRset (as glue) to AAAA. > > I basically support your opinion, though. As the draft says, it > should be better to not combine the content with transport, based on > the basic model of DNS. Also, we can even construct a case where the > querier that receives the delegation in the above example can be just > a "middle-node" and the real "user" exists behind the node. (e.g., > there is a simple DNS forwarder to help IPv4<->IPv6 translation, which > does not act as a recursive resolver - though this might be a tricky > example). > > We could probably describe the subtle points, but this might be a > minor detail, so, as a result, I can live with the current wording of > yours. There are tradeoffs each way whether to expand these right now or not. It seems to me that in order to do that, we'd have to gain WG consensus on the approach to go forward, and that's always difficult and time-consuming.. so I've avoided doing that for now. I'll consider posting a separate thread on the subject to gauge opinions when we get into the "waiting for IESG evaluation" stage. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 28 17:09:21 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20936 for ; Wed, 28 Apr 2004 17:09:21 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SJS0q3002851 for ; Wed, 28 Apr 2004 12:28:00 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3SJS0iC002844 for dnsop-outgoing; Wed, 28 Apr 2004 12:28:00 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SJRv43002744 for ; Wed, 28 Apr 2004 12:27:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10829; Wed, 28 Apr 2004 15:27:55 -0400 (EDT) Message-Id: <200404281927.PAA10829@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dnsop@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-ipv6-dns-issues-06.txt Date: Wed, 28 Apr 2004 15:27:55 -0400 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Operational Considerations and Issues with IPv6 DNS Author(s) : A. Durand, et al. Filename : draft-ietf-dnsop-ipv6-dns-issues-06.txt Pages : 25 Date : 2004-4-28 This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehaviour, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-dnsop-ipv6-dns-issues-06.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-ietf-dnsop-ipv6-dns-issues-06.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: <2004-4-28152914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsop-ipv6-dns-issues-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28152914.I-D@ietf.org> --OtherAccess-- --NextPart-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 28 18:54:02 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01041 for ; Wed, 28 Apr 2004 18:54:02 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SLWPmZ014802 for ; Wed, 28 Apr 2004 14:32:25 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3SLWPkq014797 for dnsop-outgoing; Wed, 28 Apr 2004 14:32:25 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3SLWOYD014740 for ; Wed, 28 Apr 2004 14:32:24 -0700 (PDT) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3SLWH5G022815; Wed, 28 Apr 2004 14:32:17 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3SLWGbh022814; Wed, 28 Apr 2004 14:32:16 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 28 Apr 2004 14:32:16 -0700 From: David Meyer To: dnsop@lists.uoregon.edu Cc: Alain.Durand@sun.com, johani@autonomica.se, psavola@funet.fi Subject: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt Message-ID: <20040428213216.GA22767@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: David Meyer Folks, This note starts the WG Last Call (WGLC) for comments on draft-ietf-dnsop-ipv6-dns-issues-06.txt, "Operational Considerations and Issues with IPv6 DNS". It can be found on http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-06.txt Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. This WGLC will end on 12 May 2004 at 1500 PDT (UTC/GMT-7). Thanks, Dave & Rob . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 11:42:28 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09928 for ; Thu, 29 Apr 2004 11:42:27 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TELH3i026406 for ; Thu, 29 Apr 2004 07:21:17 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3TELHGh026397 for dnsop-outgoing; Thu, 29 Apr 2004 07:21:17 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TELEJa026352 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 29 Apr 2004 07:21:16 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i3TELD7x007724 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 29 Apr 2004 10:21:14 -0400 Date: Thu, 29 Apr 2004 10:21:13 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Dean Anderson Am I preaching to the choir, or do people disagree with me? It would be good to let your opinions be known. Otherwise, we might allow further misleading and false claims about whether in-addr is required. In-addr is not required, nor will this draft (despite its misleading name) change that. It should also not be allowed to mislead people on the policies of other organizations, nor should it be allowed to promote bad practices by applications or otherwise mislead people as to the purpose and utility of in-addr. --Dean On Tue, 27 Apr 2004, Dean Anderson wrote: > This draft was already discussed and rejected. I note that the draft 04 > has been deleted from the IETF site. > > Instead of addressing any of the many previous issues addressed against > the 04 draft, as demonstrated by reviewing the archives of that > discussion, it simply rehashes the same wrong claims made by the 04 draft. > > Indeed, it was pointed out that it does not accurately state ARIN's policy > on the subject. This was just one of _many_ problems, but probably the > easiest to fix. It is practically an insult to resubmit this draft in its > present form. > > So, why is it coming up again? > > Can we finally kill this once and for all? > > --Dean > > ***In fact, according to Leslie Nobile, ARIN is considering dropping > in-addr support in the future, and has gone so far as to engage its > attorney's to research the question of whether it is obligated to provide > the service. Their lawyers say they are not obligated. > > > > > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 12:37:27 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12742 for ; Thu, 29 Apr 2004 12:37:26 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TEbhKU009340 for ; Thu, 29 Apr 2004 07:37:43 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3TEbhg1009337 for dnsop-outgoing; Thu, 29 Apr 2004 07:37:43 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TEbfGO009165 for ; Thu, 29 Apr 2004 07:37:42 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TEb5o30678; Thu, 29 Apr 2004 17:37:05 +0300 Date: Thu, 29 Apr 2004 17:37:05 +0300 (EEST) From: Pekka Savola To: Dean Anderson cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Thu, 29 Apr 2004, Dean Anderson wrote: > Am I preaching to the choir, or do people disagree with me? > > It would be good to let your opinions be known. Yes, I disagree. > Otherwise, we might allow further misleading and false claims about > whether in-addr is required. In-addr is not required, nor will this draft > (despite its misleading name) change that. It should also not be allowed > to mislead people on the policies of other organizations, nor should it be > allowed to promote bad practices by applications or otherwise mislead > people as to the purpose and utility of in-addr. The document should be revised to take out all the upper-case keywords and bogus things like: Regional Registries and any Local Registries to whom they delegate SHOULD establish and convey a policy to those to whom they delegate blocks that IN-ADDR mappings are required. Policies SHOULD require those receiving delegations to provide IN-ADDR service and/or delegate to downstream customers. .. even if this would be a good practice, it's not an IETF business to set these requirements or so it would seem to me. On the other hand, it's fine to discuss the tradeoffs of in-addr mappings, why it would make sense to have them (or why not), how they are set up properly, etc. -- all of this is what (IMHO) the document should be doing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 15:08:53 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20503 for ; Thu, 29 Apr 2004 15:08:52 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3THwEWj028606 for ; Thu, 29 Apr 2004 10:58:14 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3THwE8O028601 for dnsop-outgoing; Thu, 29 Apr 2004 10:58:14 -0700 (PDT) Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3THwCJk028534 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 29 Apr 2004 10:58:13 -0700 (PDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/02/24/sjaenick) with ESMTP id i3THwAai008707 for ; Thu, 29 Apr 2004 19:58:10 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i3THwAg00103 for ; Thu, 29 Apr 2004 19:58:10 +0200 (MEST) Message-Id: <200404291758.i3THwAg00103@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@lists.uoregon.edu Subject: Re: [dnsop] I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt In-reply-to: Your message of "Thu, 29 Apr 2004 10:21:13 EDT." 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: <99.1083261488.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 29 Apr 2004 19:58:09 +0200 From: Peter Koch Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Peter Koch Dean Anderson wrote: > Am I preaching to the choir, or do people disagree with me? Some do, count me in. > whether in-addr is required. In-addr is not required, nor will this draft > (despite its misleading name) change that. It should also not be allowed Please look into the document, the title was changed whereas the filename and the announcement text continued to say "require". In the document there are still some "requirements" - and, btw, non-ASCII characters - that I feel should be ``diplomatized'', but I fully support the general direction of that document. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 15:34:56 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23176 for ; Thu, 29 Apr 2004 15:34:56 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TIHRlA028009 for ; Thu, 29 Apr 2004 11:17:27 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3TIHRiH028008 for dnsop-outgoing; Thu, 29 Apr 2004 11:17:27 -0700 (PDT) Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TIHOde027938 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 29 Apr 2004 11:17:26 -0700 (PDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/02/24/sjaenick) with ESMTP id i3TIHNQx010556 for ; Thu, 29 Apr 2004 20:17:24 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i3TIHNr00209 for ; Thu, 29 Apr 2004 20:17:23 +0200 (MEST) Message-Id: <200404291817.i3TIHNr00209@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@lists.uoregon.edu Subject: Re: [dnsop] I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt In-reply-to: Your message of "Thu, 29 Apr 2004 17:37:05 +0300." 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: <200.1083262641.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 29 Apr 2004 20:17:23 +0200 From: Peter Koch Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Peter Koch Pekka Savola wrote: > The document should be revised to take out all the upper-case keywords use of RFC 2119 keywords in documents not specifying protocols or processes is a tightrope walk anyway, but as long as the weaker forms like SHOULD or RECOMMENDED are used they are OK for a BCP. > Regional Registries and any Local Registries to whom they delegate > SHOULD establish and convey a policy to those to whom they delegate > blocks that IN-ADDR mappings are required. Policies SHOULD require > those receiving delegations to provide IN-ADDR service and/or > delegate to downstream customers. > > .. even if this would be a good practice, it's not an IETF business to > set these requirements or so it would seem to me. The IETF also suggests/recommends certain network ingress filters although that's not its core business. However, I agree that the term "required" here again is too strong. Highly RECOMMENDing should be sufficient, not more but also not less. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 16:38:43 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28018 for ; Thu, 29 Apr 2004 16:38:42 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TJLIHW014294 for ; Thu, 29 Apr 2004 12:21:18 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3TJLIcE014291 for dnsop-outgoing; Thu, 29 Apr 2004 12:21:18 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TJLHVI014158 for ; Thu, 29 Apr 2004 12:21:17 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 5003) id 13950D4C; Thu, 29 Apr 2004 15:21:12 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B826B1050; Thu, 29 Apr 2004 15:21:09 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1582407; Thu, 29 Apr 2004 15:21:09 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20040428213216.GA22767@1-4-5.net> References: <20040428213216.GA22767@1-4-5.net> Date: Thu, 29 Apr 2004 15:21:09 -0400 To: David Meyer From: Edward Lewis Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt Cc: dnsop@lists.uoregon.edu, Alain.Durand@sun.com, johani@autonomica.se, psavola@funet.fi Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_02_03 version=2.43-arin1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Edward Lewis Regarding the last call for: >http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-06.txt Section 1.3 Besides maintaining "at least one...IPv4", the section should also recommend making "at least one" available for IPv6 once v6 is available. I think that would even it out. I'd also like to see some statement regarding what happens when IPv4 dies. (Okay, y'all can stop laughing now.) Maybe like "maintain v4 until there's a recommendation to retire it. This kind of issue (an exit strategy) seems to be quite often glossed over. It's not that I want to see an exit strategy, but to at least mention in the document that a reader 15 years from now ought to be planning for one, whether it comes or not. But to draw a finer and more sane point, DNS really isn't about servers, it's about zones. I would recommend stating that each zone be made available authoritatively (master or slave) on each (v4, v6) transport. Section 2.3 When you say "challenge" in the first paragraph, do you mean tedious or tricky? I.e., is it just a pain because of the volume of octets or is it not straightforward? Section 4.1 One pothole I stepped into falls roughly in this category. I have a name server running on a section of network that is IPv4 only. To bring the server's zones up on IPv6, I used another machine on a different section of network. The A record for the name pointed to one machine, the AAAA to the other. This works okay for DNS, but I had a problem when I did an "ssh" to the box. Instead of winding up at the A box, I was on the AAAA box. I nearly edited the wrong /etc/named.conf. The recommendation is that, if you use service names in addition to host names, you only use the service names within the service mentioned. And - use the host name when ssh'ing. Top of page 17 (second line), grammer error: "However, when stronger form of security is used" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 17:33:37 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04122 for ; Thu, 29 Apr 2004 17:33:37 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TKEtsc004653 for ; Thu, 29 Apr 2004 13:14:55 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3TKEtBf004652 for dnsop-outgoing; Thu, 29 Apr 2004 13:14:55 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TKEsBM004603 for ; Thu, 29 Apr 2004 13:14:54 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3TKErMu029483 for ; Thu, 29 Apr 2004 14:14:53 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HWY007NL88TD6@edgemail1.Central.Sun.COM> for dnsop@lists.uoregon.edu; Thu, 29 Apr 2004 14:14:53 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HWY00CS588RE1@mail.sun.net> for dnsop@lists.uoregon.edu; Thu, 29 Apr 2004 14:14:53 -0600 (MDT) Date: Thu, 29 Apr 2004 13:14:50 -0700 From: Alain Durand Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt In-reply-to: To: Edward Lewis Cc: psavola@funet.fi, dnsop@lists.uoregon.edu, David Meyer , johani@autonomica.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20040428213216.GA22767@1-4-5.net> Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Alain Durand Content-Transfer-Encoding: 7BIT On Apr 29, 2004, at 12:21 PM, Edward Lewis wrote: > Regarding the last call for: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues >> -06.txt > > Section 1.3 > > Besides maintaining "at least one...IPv4", the section should also > recommend making "at least one" available for IPv6 once v6 is > available. I think that would even it out. Actually, the whole section 1.2 and 1.3 are a repeat of draft-ietf-dnsop-ipv6-transport-guidelines-02 that is now in the RFCeditor queue, so we might as well delete those two sections and simply point to the RFC to be. - Alain. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 19:10:48 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09738 for ; Thu, 29 Apr 2004 19:10:47 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TLxEwc005613 for ; Thu, 29 Apr 2004 14:59:14 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3TLxEQm005607 for dnsop-outgoing; Thu, 29 Apr 2004 14:59:14 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3TLxCjs005483 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 29 Apr 2004 14:59:13 -0700 (PDT) Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i3TLx31C048509; Thu, 29 Apr 2004 23:59:04 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <20040428213216.GA22767@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7024FC38-9A28-11D8-84EA-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: dnsop@lists.uoregon.edu From: Iljitsch van Beijnum Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt Date: Thu, 29 Apr 2004 23:59:07 +0200 To: Edward Lewis X-Mailer: Apple Mail (2.613) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Iljitsch van Beijnum Content-Transfer-Encoding: 7bit On 29-apr-04, at 21:21, Edward Lewis wrote: > I'd also like to see some statement regarding what happens when IPv4 > dies. How is v4 ever going to die when everyone is forced to keep running v4 nameservers? > (Okay, y'all can stop laughing now.) Maybe like "maintain v4 until > there's a recommendation to retire it. This kind of issue (an exit > strategy) seems to be quite often glossed over. It's not that I want > to see an exit strategy, but to at least mention in the document that > a reader 15 years from now ought to be planning for one, whether it > comes or not. I think we all agree that flag day approaches on a network that has the scale of the internet aren't going to fly. But in reality, requiring v4 nameservers now and at some time reversing this and requiring v6 nameservers instead is a flag day approach. As long as there is a single IPv6-holdout somewhere on the net, this isn't going to work. The inevitable conclusion is that the only people who really know whether a zone should be served by IPv4 nameservers, IPv6 nameservers or both, are the people running that zone. So they should be the ones making this decision. Sure, some dire "without v4 servers bad things will happen" warnings are in order, but DNS administrators are supposed to be adults and as such have the inalienable right to make their own mistakes. But I'm not in a hurry, all of this will work out in due course. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 29 23:50:28 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22189 for ; Thu, 29 Apr 2004 23:50:27 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3U2YgqN006630 for ; Thu, 29 Apr 2004 19:34:42 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3U2Yg3a006628 for dnsop-outgoing; Thu, 29 Apr 2004 19:34:42 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3U2Yfnp006550 for ; Thu, 29 Apr 2004 19:34:41 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 5003) id 4153199F; Thu, 29 Apr 2004 22:34:36 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id C600B9C4; Thu, 29 Apr 2004 22:34:35 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1583594; Thu, 29 Apr 2004 22:34:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <7024FC38-9A28-11D8-84EA-000A95CD987A@muada.com> References: <20040428213216.GA22767@1-4-5.net> <7024FC38-9A28-11D8-84EA-000A95CD987A@muada.com> Date: Thu, 29 Apr 2004 22:34:32 -0400 To: Iljitsch van Beijnum From: Edward Lewis Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt Cc: Edward Lewis , dnsop@lists.uoregon.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Edward Lewis The issue I'm picking on here is rather small. Perhaps what I should suggest is wording that says "regardless of what is in a zone, there should be a server for it available on all network layers in common use." "In common use" is to be left open to interpretation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 30 03:39:43 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00894 for ; Fri, 30 Apr 2004 03:39:42 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3U6fpt4021299 for ; Thu, 29 Apr 2004 23:41:51 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3U6fpqq021297 for dnsop-outgoing; Thu, 29 Apr 2004 23:41:51 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3U6fnma021257 for ; Thu, 29 Apr 2004 23:41:49 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3U6fef12284; Fri, 30 Apr 2004 09:41:40 +0300 Date: Fri, 30 Apr 2004 09:41:40 +0300 (EEST) From: Pekka Savola To: Edward Lewis cc: David Meyer , , , Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola Thanks for the feedback -- inline.. On Thu, 29 Apr 2004, Edward Lewis wrote: > Section 1.3 [on the summary of transport guidelines] Omitted for now; please bring this up about the transport guidelines document, and let's then reflect that in here. > Section 2.3 > > When you say "challenge" in the first paragraph, do you mean tedious or tricky? > I.e., is it just a pain because of the volume of octets or is it not > straightforward? It is not straightforward because the users who are using 6to4 probably don't have ISPs which would be willing to do anything to provide delegation path delegation, so alternative means would have to be used. I reworded "challenge" to "not straightforward and pracically impossible". Or would you suggest something else? > Section 4.1 > > One pothole I stepped into falls roughly in this category. I have a > name server running on a section of network that is IPv4 only. To > bring the server's zones up on IPv6, I used another machine on a > different section of network. The A record for the name pointed to > one machine, the AAAA to the other. This works okay for DNS, but I > had a problem when I did an "ssh" to the box. Instead of winding up > at the A box, I was on the AAAA box. I nearly edited the wrong > /etc/named.conf. > > The recommendation is that, if you use service names in addition to > host names, you only use the service names within the service > mentioned. And - use the host name when ssh'ing. This seems so obvious to me that I'm having trouble figuring out how to put it :) .. but I added at the end of the second paragraph: (Obviously, when wanting to reach a specific node, one should use the hostname rather than a service name.) > Top of page 17 (second line), grammer error: > > "However, when stronger form of security is used" What was the error? I added "a" in front of "stronger". Not sure if that was it.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 30 03:57:08 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01613 for ; Fri, 30 Apr 2004 03:57:08 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3U6UkIX015266 for ; Thu, 29 Apr 2004 23:30:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3U6UkKl015265 for dnsop-outgoing; Thu, 29 Apr 2004 23:30:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3U6Ui5C015213 for ; Thu, 29 Apr 2004 23:30:45 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3U6USv12149; Fri, 30 Apr 2004 09:30:28 +0300 Date: Fri, 30 Apr 2004 09:30:28 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Edward Lewis , , David Meyer , Subject: DNS transport guidelines [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Thu, 29 Apr 2004, Alain Durand wrote: > On Apr 29, 2004, at 12:21 PM, Edward Lewis wrote: > > > Regarding the last call for: > >> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues > >> -06.txt > > > > Section 1.3 > > > > Besides maintaining "at least one...IPv4", the section should also > > recommend making "at least one" available for IPv6 once v6 is > > available. I think that would even it out. > > Actually, the whole section 1.2 and 1.3 are a repeat of > draft-ietf-dnsop-ipv6-transport-guidelines-02 > that is now in the RFCeditor queue, so we might as well delete those > two sections and simply > point to the RFC to be. It's still in IETF Last Call, so would probably change. Ed, can you suggest an appropriate change to the draft-ietf-dnsop-ipv6-transport-guidelines-02 and let's reflect that accordingly in draft-ietf-dnsop-ipv6-dns-issues-06.txt. (IMHO, it's still worth keeping in a summary of draft-ietf-dnsop-ipv6-transport-guidelines-02 in draft-ietf-dnsop-ipv6-dns-issues-06.txt, because let's be honest -- an average john doe isn't going to read it in any case :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 30 11:50:51 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10538 for ; Fri, 30 Apr 2004 11:50:50 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3UEKm6m017124 for ; Fri, 30 Apr 2004 07:20:48 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3UEKmlf017122 for dnsop-outgoing; Fri, 30 Apr 2004 07:20:48 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3UEKlAT017084 for ; Fri, 30 Apr 2004 07:20:47 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 5003) id A9CCADB0; Fri, 30 Apr 2004 10:20:41 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id BE89FDB5; Fri, 30 Apr 2004 10:20:40 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1585322; Fri, 30 Apr 2004 10:20:40 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 30 Apr 2004 10:20:39 -0400 To: Pekka Savola From: Edward Lewis Subject: Re: DNS transport guidelines [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt] Cc: Alain Durand , Edward Lewis , , David Meyer , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Edward Lewis At 9:30 +0300 4/30/04, Pekka Savola wrote: >Ed, can you suggest an appropriate change to the >draft-ietf-dnsop-ipv6-transport-guidelines-02 and let's reflect that >accordingly in draft-ietf-dnsop-ipv6-dns-issues-06.txt. In another reply I had (part of) this, which I think is balanced as far as v4-v6, doesn't mandate "v4 forever", and is fuzzy enough to be re-interpreted later: # Regardless of what is in a zone, there should be a server for it available # on all network layers, e.g., IPv4 and IPv6, in common use. A zone's contents # should appear the same on all servers, hence, no matter what network layer # used to query the servers, the contents of the answer is substantially the # same. "In common use" - means that even if you don't have a v4 infrastructure anymore, you should consider asking someone with one to server your zones for you on a v4-enabled server. "Substantially" - because of the glue question and the truncation issue in DNS, you can't specify that the answer "is" the same. Another case to consider is the the query type any. If my v4 recursive server does not share the same memory (RAM) as my v6 server, chances are strong that the caches in the two will differ over time. QTYPE ANY queries ask for "what you have" about a name, not the complete data at the name (as far as an authoritative server is concerned). It's reasonable to consider that the exact responses from the two servers will differ, regardless of the fact that they are on different network layers. >(IMHO, it's still worth keeping in a summary of >draft-ietf-dnsop-ipv6-transport-guidelines-02 in >draft-ietf-dnsop-ipv6-dns-issues-06.txt, because let's be honest -- an >average john doe isn't going to read it in any case :) I've got the feeling I'm going to need to try again at the wording, I'm running up on a meeting deadline. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 30 12:59:54 2004 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14502 for ; Fri, 30 Apr 2004 12:59:53 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3UFtKco002522 for ; Fri, 30 Apr 2004 08:55:20 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i3UFtK7h002519 for dnsop-outgoing; Fri, 30 Apr 2004 08:55:20 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i3UFtI4o002435 for ; Fri, 30 Apr 2004 08:55:18 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3UFtIMu025320 for ; Fri, 30 Apr 2004 09:55:18 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HWZ00JF4QW5OG@edgemail1.Central.Sun.COM> for dnsop@lists.uoregon.edu; Fri, 30 Apr 2004 09:55:18 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HWZ00LYRQW1XL@mail.sun.net> for dnsop@lists.uoregon.edu; Fri, 30 Apr 2004 09:55:15 -0600 (MDT) Date: Fri, 30 Apr 2004 08:55:13 -0700 From: Alain Durand Subject: Re: DNS transport guidelines [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt] In-reply-to: To: Edward Lewis Cc: Pekka Savola , dnsop@lists.uoregon.edu, David Meyer , johani@autonomica.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Alain Durand Content-Transfer-Encoding: 7BIT On Apr 30, 2004, at 7:20 AM, Edward Lewis wrote: > # Regardless of what is in a zone, there should be a server for it > available > # on all network layers, e.g., IPv4 and IPv6, in common use. A zone's > contents > # should appear the same on all servers, hence, no matter what network > layer > # used to query the servers, the contents of the answer is > substantially the > # same. > > "In common use" - means that even if you don't have a v4 > infrastructure anymore, you should consider asking someone with one to > server your zones for you on a v4-enabled server. I think this is already covered in the current text which does not say that you need to 'own' all DNS servers for your zone. > "Substantially" - because of the glue question and the truncation > issue in DNS, you can't specify that the answer "is" the same. > > Another case to consider is the the query type any. If my v4 > recursive server does not share the same memory (RAM) as my v6 server, > chances are strong that the caches in the two will differ over time. > QTYPE ANY queries ask for "what you have" about a name, not the > complete data at the name (as far as an authoritative server is > concerned). It's reasonable to consider that the exact responses from > the two servers will differ, regardless of the fact that they are on > different network layers. Thank you for this clarification I now understand you point. We might want to add text that only focus on those issues. This is an operational issue that is somehow different from the one described in the transport guideline document. I think it should go into the ipv6-dns-issues document, which is the one you commented on first, so I withdraw my previous comment. - Alain. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html