From ipv6-bounces@ietf.org Wed Dec 1 02:54:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12882 for ; Wed, 1 Dec 2004 02:54:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZPPC-0001NJ-Ue for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 03:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZPGQ-0008A9-3A; Wed, 01 Dec 2004 02:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZOyk-0001bw-Hn for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 02:32:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02445 for ; Wed, 1 Dec 2004 02:32:45 -0500 (EST) Received: from ns.64translator.com ([202.214.123.16] helo=mail.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZP3y-0000qf-4M for ipv6@ietf.org; Wed, 01 Dec 2004 02:38:13 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.11/8.12.6) with ESMTP id iB17VkW2071241 for ; Wed, 1 Dec 2004 16:31:46 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp147.64translator.com [10.21.32.147]) by bahamas.64translator.com (8.12.9p2/8.12.9) with SMTP id iB17VjEn012085 for ; Wed, 1 Dec 2004 16:31:46 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Wed, 1 Dec 2004 16:31:45 +0900 From: Yukiyo Akisada To: ipv6@ietf.org Message-Id: <20041201163145.603a1c39.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Dec 2004 02:50:47 -0500 Subject: question about router behavior X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Hi, all. I have a question about a router behavior. rfc2461 and 2461bis assume that the router can stop packet forwarding without disabling to send RA. draft-ietf-ipv6-2461bis-01.txt 6.2.5. Ceasing To Be An Advertising Interface ------------------------------------------------------------------------ 2555 Note that system management may disable a router's IP forwarding 2556 capability (i.e., changing the system from being a router to being a 2557 host), a step that does not necessarily imply that the router's 2558 interfaces stop being advertising interfaces. In such cases, 2559 subsequent Router Advertisements MUST set the Router Lifetime field 2560 to zero. ------------------------------------------------------------------------ But if a router stops packet forwarding, it should be a host. draft-ietf-ipv6-2461bis-01.txt 2. TERMINOLOGY 2.1. General ------------------------------------------------------------------------ 229 router - a node that forwards IP packets not explicitly 238 addressed to itself. 239 240 host - any node that is not a router. ------------------------------------------------------------------------ And rfc2461 and 2461bis also says the host never send RA. draft-ietf-ipv6-2461bis-01.txt 6.2.4. Sending Unsolicited Router Advertisements ------------------------------------------------------------------------ 2496 A host MUST NOT send Router Advertisement messages at any time. ------------------------------------------------------------------------ I think, when the router stops packet forwarding, the router also should stop sending RA as like as other 3 cases specified in section 6.2.5. draft-ietf-ipv6-2461bis-01.txt 6.2.5. Ceasing To Be An Advertising Interface ------------------------------------------------------------------------ 2527 An interface may cease to be an advertising interface, through 2528 actions of system management such as: 2529 2530 - changing the AdvSendAdvertisements flag of an enabled interface 2539 from TRUE to FALSE, or 2540 2541 - administratively disabling the interface, or 2542 2543 - shutting down the system. ------------------------------------------------------------------------ What is the difference from other 3 situations? Thanks. ---- Yukiyo Akisada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 1 03:42:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02471 for ; Wed, 1 Dec 2004 03:42:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZQ9X-0002OY-N1 for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 03:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZQ0B-0002AO-4f; Wed, 01 Dec 2004 03:38:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZPpS-0000OP-EU for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 03:27:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01672 for ; Wed, 1 Dec 2004 03:27:13 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZPuj-00026D-NJ for ipv6@ietf.org; Wed, 01 Dec 2004 03:32:42 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DBAD93606; Wed, 1 Dec 2004 09:26:39 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11150-05; Wed, 1 Dec 2004 09:26:39 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 0D13235D9; Wed, 1 Dec 2004 09:26:39 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZPos-0000ns-Jt; Wed, 01 Dec 2004 09:26:38 +0100 Date: Wed, 1 Dec 2004 09:26:38 +0100 From: Juergen Schoenwaelder To: wu.wenming@zte.com.cn Message-ID: <20041201082638.GA2158@james> Mail-Followup-To: wu.wenming@zte.com.cn, ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org Subject: Re: Issue about RFC3595 - Textual Conventions for IPv6 Flow Label X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Wed, Dec 01, 2004 at 10:07:17AM +0800, wu.wenming@zte.com.cn wrote: > That is only my trivial suggestion of redefinition semantics for 0xFFFFF. > After all, 0xFFFFF has been a valid value of flow label. Originally, I just > think only 20-bits is enough. The TC does not change flow label semantics. The value range of the IPv6FlowLabel TC is 0..1048575 which equals 0..0xfffff. The value range of the IPv6FlowLabelOrAny is -1 | 0..1048575, that is this TC adds a special value which is outside of the range of the possible flow label values. The encodings of -1 and 1048575 are surely different in BER. > To say the least, Flow label TC need really a wildcard?? In a application, > a wildcard could be represented by FlowLabelValue>0 or FlowLabelValue<>0. > Thus, it may not redefine the semantics of "0-0xFFFFF". If you define a filter which matches packet headers, it is usually a good idea to have a wildcard value which says "do not match this header". The IPv6FlowLabelOrAny TC is exactly for this purpose. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 1 04:15:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05079 for ; Wed, 1 Dec 2004 04:15:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZQfE-0003C2-UX for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 04:20:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZQYZ-000100-At; Wed, 01 Dec 2004 04:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZQUS-0007Yx-FI for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 04:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04558 for ; Wed, 1 Dec 2004 04:09:35 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZQZZ-000339-Ml for ipv6@ietf.org; Wed, 01 Dec 2004 04:15:04 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.1/8.13.1/Debian-17) with ESMTP id iB199JQj003875; Wed, 1 Dec 2004 11:09:19 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.1/8.13.1/Submit) id iB199JSn003872; Wed, 1 Dec 2004 11:09:19 +0200 Date: Wed, 1 Dec 2004 11:09:19 +0200 Message-Id: <200412010909.iB199JSn003872@burp.tkv.asdf.org> From: Markku Savela To: Yukiyo.Akisada@jp.yokogawa.com In-reply-to: <20041201163145.603a1c39.Yukiyo.Akisada@jp.yokogawa.com> (message from Yukiyo Akisada on Wed, 1 Dec 2004 16:31:45 +0900) References: <20041201163145.603a1c39.Yukiyo.Akisada@jp.yokogawa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: question about router behavior X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > I have a question about a router behavior. > rfc2461 and 2461bis assume that > the router can stop packet forwarding without disabling to send RA. Perhaps, so that one could have a configuration with multiple routers, one advertising only as default router, and no prefixes. And, another that would advertise the prefixes, but have router lifetime = 0 (e.g., is not a default router). There is also "preferred route option", a router that is not default router (lifetime = 0), but still routes some specificic prefixes. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From mailman-bounces@ietf.org Wed Dec 1 09:45:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04584 for ; Wed, 1 Dec 2004 09:45:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZVoq-0001VY-TY for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 09:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSkA-000857-5T for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 06:33:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipv6-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:53:49 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipv6-web-archive@ietf.org: List Password // URL ---- -------- ipv6@ietf.org azsube https://www1.ietf.org/mailman/options/ipv6/ipv6-web-archive%40ietf.org From ipv6-bounces@ietf.org Wed Dec 1 10:13:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08554 for ; Wed, 1 Dec 2004 10:13:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZWG1-00025p-T0 for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 10:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSo6-0004az-1o; Wed, 01 Dec 2004 06:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZRwE-000532-VZ for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 05:42:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11149 for ; Wed, 1 Dec 2004 05:42:21 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZS1W-0004xR-Eg for ipv6@ietf.org; Wed, 01 Dec 2004 05:47:52 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB1AfLpN178362; Wed, 1 Dec 2004 10:41:30 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB1AfRDc254318; Wed, 1 Dec 2004 10:41:28 GMT Received: from zurich.ibm.com (sig-9-145-249-118.de.ibm.com [9.145.249.118]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA92390; Wed, 1 Dec 2004 11:41:19 +0100 Message-ID: <41AD9FD4.2030503@zurich.ibm.com> Date: Wed, 01 Dec 2004 11:41:24 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Mark Andrews References: <200412010050.iB10oUJo077250@drugs.dv.isc.org> In-Reply-To: <200412010050.iB10oUJo077250@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Mark, I don't think "wait and see" is a cop-out, actually. Since these addresses are by definition useless on the Internet in general, I think local pragmatic decision taking is the best way to find out what we *should* recommend. It's not obvious to me that a typical corporate deployment of ULAs will need any reverse lookup at all. It may simply be a non-problem (apart from the load problem that as112 addresses as I understand it). Brian Mark Andrews wrote: >>Mark, >> >>At 03:16 PM 11/29/2004, Mark Andrews wrote: >> >> >>> Section 4.4 DNS Issues >>> >>> This sections appears to be a real cop out. >>> >>> It is perfectly natural for clients to want to make queries and >>> have these addresses returned from the DNS. >> >>There is a wide range of views on what is appropriate for putting these >>addresses in the global DNS. For now, I think the best way to move this >>document forward is to leave it as is and wait until we have operational >>experience. Once there is some operational experience it would be good if >>V6OPS or DNSOPS wrote a document about the best way to do it. >> >>Bob > > > I think there is plenty of IPv4 experience that translates to > this area. This is basically saying that the as112 should be > the default treatment for these reverse zones. > > See http://www.as112.net/ > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 1 12:22:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28857 for ; Wed, 1 Dec 2004 12:22:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYGV-0005I2-HJ for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 12:27:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZX3c-000261-Pe; Wed, 01 Dec 2004 11:10:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZUd4-0002Us-PX for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 08:34:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27597 for ; Wed, 1 Dec 2004 08:34:44 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZUiP-00009F-45 for ipv6@ietf.org; Wed, 01 Dec 2004 08:40:17 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id AEFA867503 for ; Wed, 1 Dec 2004 13:34:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB1DY7l3037689; Thu, 2 Dec 2004 00:34:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412011334.iB1DY7l3037689@drugs.dv.isc.org> To: Brian E Carpenter From: Mark Andrews In-reply-to: Your message of "Wed, 01 Dec 2004 11:41:24 BST." <41AD9FD4.2030503@zurich.ibm.com> Date: Thu, 02 Dec 2004 00:34:07 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a > Mark, > > I don't think "wait and see" is a cop-out, actually. Since these > addresses are by definition useless on the Internet in general, > I think local pragmatic decision taking is the best way to find > out what we *should* recommend. It's not obvious to me that > a typical corporate deployment of ULAs will need any reverse > lookup at all. It may simply be a non-problem (apart from the load > problem that as112 addresses as I understand it). > > Brian It's not a question of how many sites will populate the reverse zones. It's a question of how many sites will *not* setup the reverse zone and how many applications will make a reverse lookup on these addresses. You are arguing above that most sites won't setup the reverse zone. This is the situation where you need the preconfigured reverse zones the most. It costs real money to absorb the load. Money for servers. Money for bandwidth to the servers. > Mark Andrews wrote: > >>Mark, > >> > >>At 03:16 PM 11/29/2004, Mark Andrews wrote: > >> > >> > >>> Section 4.4 DNS Issues > >>> > >>> This sections appears to be a real cop out. > >>> > >>> It is perfectly natural for clients to want to make queries and > >>> have these addresses returned from the DNS. > >> > >>There is a wide range of views on what is appropriate for putting these > >>addresses in the global DNS. For now, I think the best way to move this > >>document forward is to leave it as is and wait until we have operational > >>experience. Once there is some operational experience it would be good if > >>V6OPS or DNSOPS wrote a document about the best way to do it. > >> > >>Bob > > > > > > I think there is plenty of IPv4 experience that translates to > > this area. This is basically saying that the as112 should be > > the default treatment for these reverse zones. > > > > See http://www.as112.net/ > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 1 12:36:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01482 for ; Wed, 1 Dec 2004 12:36:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYUg-00063t-1e for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 12:42:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXZG-0000yF-PO; Wed, 01 Dec 2004 11:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZW5K-0004NQ-4Z for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 10:08:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07493 for ; Wed, 1 Dec 2004 10:08:00 -0500 (EST) Received: from can20.de ([213.203.199.216] helo=can20.can20.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZWAU-0001xd-UD for ipv6@ietf.org; Wed, 01 Dec 2004 10:13:33 -0500 Received: from Kermit.nt.fh-koeln.de (kermit.nt.FH-Koeln.DE [139.6.16.71]) by can20.can20.de (can20.can20.de) with ESMTP id E93F9109802E for ; Wed, 1 Dec 2004 16:07:49 +0100 (CET) From: Achim Marikar To: ipv6@ietf.org Content-Type: text/plain Message-Id: <1101913661.1996.92.camel@Kermit.nt.fh-koeln.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 01 Dec 2004 16:07:41 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: Questions about geographical dependent addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@marikar.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hello, I am writing my diploma thesis in information engineering at the university of applied sciences in Cologne. One of the subjects of my thesis is to develop an IPv6 address format which provides geographical localisation capabilities to VoIP and other applications. A localisation seems to be necessary for the Internet, otherwise so many people would not work on a localisation for Internet users (geopriv,ecrit, etc.). In my opinion it would be necessary to assign a user to an area code (or to an emergency call centre.) As the IPv6 addresses have enough space to map an area code, I don't understand why it is never be implemented. In my opinion the 64 bits interface ID is too long. If stateful autoconfiguration, static addresses or the privacy extension are used, it is not possible to get the MAC-address of the interface through the interface ID. A duplicate address detection is still necessary. So it would be possible to reduce the interface ID to clear space for the area code. Wouldn't it be the easiest way to map a reliable area code which is validated by the provider? Also Nomadic users could be located through their care of address. Thanks for comments, Achim Marikar -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 1 12:42:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02863 for ; Wed, 1 Dec 2004 12:42:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYZw-0006SK-R6 for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 12:47:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXmT-0006jc-R3; Wed, 01 Dec 2004 11:56:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZWlu-0000Od-N6 for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 10:52:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15222 for ; Wed, 1 Dec 2004 10:52:00 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZWrE-0002wk-MD for ipv6@ietf.org; Wed, 01 Dec 2004 10:57:33 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB1FpT5M260992; Wed, 1 Dec 2004 15:51:29 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB1FpYfh055944; Wed, 1 Dec 2004 15:51:34 GMT Received: from zurich.ibm.com (sig-9-145-132-53.de.ibm.com [9.145.132.53]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA52374; Wed, 1 Dec 2004 16:51:27 +0100 Message-ID: <41ADE87C.1080402@zurich.ibm.com> Date: Wed, 01 Dec 2004 16:51:24 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Mark Andrews References: <200412011334.iB1DY7l3037689@drugs.dv.isc.org> In-Reply-To: <200412011334.iB1DY7l3037689@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit > It costs real money to absorb the load. Well understood. But it will be a while before this goes mainstream. Brian Mark Andrews wrote: >>Mark, >> >>I don't think "wait and see" is a cop-out, actually. Since these >>addresses are by definition useless on the Internet in general, >>I think local pragmatic decision taking is the best way to find >>out what we *should* recommend. It's not obvious to me that >>a typical corporate deployment of ULAs will need any reverse >>lookup at all. It may simply be a non-problem (apart from the load >>problem that as112 addresses as I understand it). >> >> Brian > > > It's not a question of how many sites will populate the reverse > zones. It's a question of how many sites will *not* setup the > reverse zone and how many applications will make a reverse > lookup on these addresses. > > You are arguing above that most sites won't setup the reverse > zone. This is the situation where you need the preconfigured > reverse zones the most. > > It costs real money to absorb the load. Money for servers. > Money for bandwidth to the servers. > > >>Mark Andrews wrote: >> >>>>Mark, >>>> >>>>At 03:16 PM 11/29/2004, Mark Andrews wrote: >>>> >>>> >>>> >>>>> Section 4.4 DNS Issues >>>>> >>>>> This sections appears to be a real cop out. >>>>> >>>>> It is perfectly natural for clients to want to make queries and >>>>> have these addresses returned from the DNS. >>>> >>>>There is a wide range of views on what is appropriate for putting these >>>>addresses in the global DNS. For now, I think the best way to move this >>>>document forward is to leave it as is and wait until we have operational >>>>experience. Once there is some operational experience it would be good if >>>>V6OPS or DNSOPS wrote a document about the best way to do it. >>>> >>>>Bob >>> >>> >>> I think there is plenty of IPv4 experience that translates to >>> this area. This is basically saying that the as112 should be >>> the default treatment for these reverse zones. >>> >>> See http://www.as112.net/ >>> >>>-- >>>Mark Andrews, ISC >>>1 Seymour St., Dundas Valley, NSW 2117, Australia >>>PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org >>> >>>-------------------------------------------------------------------- >>>IETF IPv6 working group mailing list >>>ipv6@ietf.org >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>-------------------------------------------------------------------- >>> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 1 17:56:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05856 for ; Wed, 1 Dec 2004 17:56:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZdTs-0007f9-ML for ipv6-web-archive@ietf.org; Wed, 01 Dec 2004 18:01:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZcTJ-0005xS-7B; Wed, 01 Dec 2004 16:57:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbvu-0006rZ-Jm for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 16:22:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25964 for ; Wed, 1 Dec 2004 16:22:41 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZc1F-0004pm-VZ for ipv6@ietf.org; Wed, 01 Dec 2004 16:28:17 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 20BAB67502 for ; Wed, 1 Dec 2004 21:22:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB1LM0m1040771; Thu, 2 Dec 2004 08:22:02 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412012122.iB1LM0m1040771@drugs.dv.isc.org> To: Brian E Carpenter From: Mark Andrews In-reply-to: Your message of "Wed, 01 Dec 2004 16:51:24 BST." <41ADE87C.1080402@zurich.ibm.com> Date: Thu, 02 Dec 2004 08:22:00 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 > > It costs real money to absorb the load. > > Well understood. But it will be a while before this goes mainstream. The point is that we really will want to legitimise what as112 will have to do. To tell the users of these addresses that they SHOULD / MUST configure their nameservers to cover atleast the ULA addresses they can route to (not only their own addresses). To tell ISP's that they can configure their caching servers to respond to any queries that leak from their clients. To tell those that don't use ULA's that they can configure their servers to answer these queries and that they won't cause problems. To tell users of ULA's that it is safe for them to setup their own versions of C.F.IP6.ARPA and D.F.IP6.ARPA. To make it legitimate for nameserver vendors to pre-configure there servers to block these zones with appropriate knobs to turn them off. Mark > Brian > > Mark Andrews wrote: > >>Mark, > >> > >>I don't think "wait and see" is a cop-out, actually. Since these > >>addresses are by definition useless on the Internet in general, > >>I think local pragmatic decision taking is the best way to find > >>out what we *should* recommend. It's not obvious to me that > >>a typical corporate deployment of ULAs will need any reverse > >>lookup at all. It may simply be a non-problem (apart from the load > >>problem that as112 addresses as I understand it). > >> > >> Brian > > > > > > It's not a question of how many sites will populate the reverse > > zones. It's a question of how many sites will *not* setup the > > reverse zone and how many applications will make a reverse > > lookup on these addresses. > > > > You are arguing above that most sites won't setup the reverse > > zone. This is the situation where you need the preconfigured > > reverse zones the most. > > > > It costs real money to absorb the load. Money for servers. > > Money for bandwidth to the servers. > > > > > >>Mark Andrews wrote: > >> > >>>>Mark, > >>>> > >>>>At 03:16 PM 11/29/2004, Mark Andrews wrote: > >>>> > >>>> > >>>> > >>>>> Section 4.4 DNS Issues > >>>>> > >>>>> This sections appears to be a real cop out. > >>>>> > >>>>> It is perfectly natural for clients to want to make queries and > >>>>> have these addresses returned from the DNS. > >>>> > >>>>There is a wide range of views on what is appropriate for putting these > >>>>addresses in the global DNS. For now, I think the best way to move this > >>>>document forward is to leave it as is and wait until we have operational > >>>>experience. Once there is some operational experience it would be good i > f > >>>>V6OPS or DNSOPS wrote a document about the best way to do it. > >>>> > >>>>Bob > >>> > >>> > >>> I think there is plenty of IPv4 experience that translates to > >>> this area. This is basically saying that the as112 should be > >>> the default treatment for these reverse zones. >>> > >>> See http://www.as112.net/ > >>> > >>>-- > >>>Mark Andrews, ISC > >>>1 Seymour St., Dundas Valley, NSW 2117, Australia > >>>PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > >>> > >>>-------------------------------------------------------------------- > >>>IETF IPv6 working group mailing list > >>>ipv6@ietf.org > >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >>>-------------------------------------------------------------------- > >>> > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 03:33:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19654 for ; Thu, 2 Dec 2004 03:33:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZmUJ-0003fE-J4 for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 03:38:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZlwS-00050t-S4; Thu, 02 Dec 2004 03:03:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZeLS-0003DJ-9c for ipv6@megatron.ietf.org; Wed, 01 Dec 2004 18:57:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12730 for ; Wed, 1 Dec 2004 18:57:11 -0500 (EST) Received: from ns.64translator.com ([202.214.123.16] helo=mail.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZeQh-0000yA-Jo for ipv6@ietf.org; Wed, 01 Dec 2004 19:02:50 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.11/8.12.6) with ESMTP id iB1NuGCK076290; Thu, 2 Dec 2004 08:56:16 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp147.64translator.com [10.21.32.147]) by bahamas.64translator.com (8.12.9p2/8.12.9) with SMTP id iB1NuFEn018454; Thu, 2 Dec 2004 08:56:16 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Thu, 2 Dec 2004 08:56:13 +0900 From: Yukiyo Akisada To: msa@burp.tkv.asdf.org Message-Id: <20041202085613.26acf82d.Yukiyo.Akisada@jp.yokogawa.com> In-Reply-To: <200412010909.iB199JSn003872@burp.tkv.asdf.org> References: <20041201163145.603a1c39.Yukiyo.Akisada@jp.yokogawa.com> <200412010909.iB199JSn003872@burp.tkv.asdf.org> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Dec 2004 03:03:54 -0500 Cc: ipv6@ietf.org Subject: Re: question about router behavior X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi, Markku. Thanks for your comment. On Wed, 1 Dec 2004 11:09:19 +0200 Markku Savela wrote: > > I have a question about a router behavior. > > rfc2461 and 2461bis assume that > > the router can stop packet forwarding without disabling to send RA. > > Perhaps, so that one could have a configuration with multiple routers, one > advertising only as default router, and no prefixes. And, another that > would advertise the prefixes, but have router lifetime = 0 (e.g., is > not a default router). > > There is also "preferred route option", a router that is not default > router (lifetime = 0), but still routes some specificic prefixes. But in these case, the another router advertising lifetime=0 doesn't need to stop packet forwarding functionality. Especially, the latter case needs to use packet forwarding functionality. These cases are realizable if routers change only RA configuration. How do you think about this? Thank you. ---- Yukiyo Akisada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 04:55:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24787 for ; Thu, 2 Dec 2004 04:55:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZnlb-0005LU-ND for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 05:00:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZmfk-0007qx-Rh; Thu, 02 Dec 2004 03:50:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZmEi-0000FS-Pt for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 03:22:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18851 for ; Thu, 2 Dec 2004 03:22:46 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZmKA-0003Qo-KW for ipv6@ietf.org; Thu, 02 Dec 2004 03:28:29 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB28Mbv08269; Thu, 2 Dec 2004 10:22:38 +0200 (EET) X-Scanned: Thu, 2 Dec 2004 10:21:40 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iB28LelF025002; Thu, 2 Dec 2004 10:21:40 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00GBBehp; Thu, 02 Dec 2004 10:21:38 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB28LWa01645; Thu, 2 Dec 2004 10:21:32 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Dec 2004 10:21:21 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Dec 2004 10:21:21 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Dec 2004 10:21:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Dec 2004 10:21:20 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4322CD@esebe056.ntc.nokia.com> Thread-Topic: Questions about geographical dependent addresses Thread-Index: AcTXzTJ8VYsbEtPgTEO9n1UF4rFYjQAepxoA To: , X-OriginalArrivalTime: 02 Dec 2004 08:21:20.0719 (UTC) FILETIME=[E73F75F0:01C4D847] X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Subject: RE: Questions about geographical dependent addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Achim, You might want to review these drafts: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-07.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-07.txt and the discussions in this WG on this topic. John > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Achim Marikar > Sent: 01 December, 2004 17:08 > To: ipv6@ietf.org > Subject: Questions about geographical dependent addresses >=20 >=20 >=20 > Hello, >=20 > I am writing my diploma thesis in information engineering at the > university of applied sciences in Cologne. One of the subjects of my > thesis is to develop an IPv6 address format which provides=20 > geographical > localisation capabilities to VoIP and other applications.=20 >=20 > A localisation seems to be necessary for the Internet,=20 > otherwise so many > people would not work on a localisation for Internet users > (geopriv,ecrit, etc.). In my opinion it would be necessary to assign a > user to an area code (or to an emergency call centre.) >=20 > As the IPv6 addresses have enough space to map an area code, I don't > understand why it is never be implemented. In my opinion the 64 bits > interface ID is too long. If stateful autoconfiguration, static > addresses or the privacy extension are used, it is not possible to get > the MAC-address of the interface through the interface ID. A duplicate > address detection is still necessary. So it would be possible=20 > to reduce > the interface ID to clear space for the area code. >=20 > Wouldn't it be the easiest way to map a reliable area code which is > validated by the provider?=20 > Also Nomadic users could be located through their care of address. >=20 > Thanks for comments, >=20 > Achim Marikar=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 11:36:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06572 for ; Thu, 2 Dec 2004 11:36:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZu1f-0000IO-OM for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 11:41:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZqFy-00065i-9M; Thu, 02 Dec 2004 07:40:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZqCI-0003L1-10; Thu, 02 Dec 2004 07:36:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09123; Thu, 2 Dec 2004 07:36:32 -0500 (EST) Message-Id: <200412021236.HAA09123@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 02 Dec 2004 07:36:32 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ra-mo-flags-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Considerations on M and O Flags of IPv6 Router Advertisement Author(s) : S. Park, et al. Filename : draft-ietf-ipv6-ra-mo-flags-00.txt Pages : 12 Date : 2004-12-1 This document clarifies the processing and behaviour of a host for the M and O flags of IPv6 Router Advertisement and proposes a solution for invoking the DHCPv6 service based on administrator policy in conjunction with new host variables for the M and O flags. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ra-mo-flags-00.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-ipv6-ra-mo-flags-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ra-mo-flags-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-2080427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ra-mo-flags-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ra-mo-flags-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-2080427.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Thu Dec 2 14:15:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19587 for ; Thu, 2 Dec 2004 14:15:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZwVb-0004Zz-IQ for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 14:20:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZury-0001Xj-2B; Thu, 02 Dec 2004 12:35:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZqRC-0003rv-Vx for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 07:51:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10730 for ; Thu, 2 Dec 2004 07:51:57 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZqWi-0001Fs-Nk for ipv6@ietf.org; Thu, 02 Dec 2004 07:57:42 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB2CohVQ160076; Thu, 2 Dec 2004 12:50:49 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB2CoobL280422; Thu, 2 Dec 2004 12:50:50 GMT Received: from zurich.ibm.com (sig-9-146-220-200.de.ibm.com [9.146.220.200]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA32624; Thu, 2 Dec 2004 13:50:41 +0100 Message-ID: <41AF0FA6.20609@zurich.ibm.com> Date: Thu, 02 Dec 2004 13:50:46 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ipv6@ietf.org References: <3CF661B1787ABF41A869BE20108F8D6D4322CD@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D4322CD@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: Re: Questions about geographical dependent addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Achim, >>A localisation seems to be necessary for the Internet, >>otherwise so many >>people would not work on a localisation for Internet users >>(geopriv,ecrit, etc.). No, this doesn't follow. The fact that there are commercial motivations for geolocation or possible invasions of privacy using geolocation doesn't mean it's *necessary*. In fact, in many cases it may be highly undesirable. Preventing any possibility of geolocation might be more desirable than allowing it, depending on circumstances. ... >>As the IPv6 addresses have enough space to map an area code, I don't >>understand why it is never be implemented. Because IP routing works by topology, not by geography. There is no particular reason why logically adjacent address blocks would be geographically adjacent. Therefore, the concept of "area code" is simply meaningless in the IP context. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 15:39:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27741 for ; Thu, 2 Dec 2004 15:39:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZxpY-0006VD-0n for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 15:45:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZuwM-00057r-SM; Thu, 02 Dec 2004 12:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZrF0-0005Go-Dv for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 08:43:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17849 for ; Thu, 2 Dec 2004 08:43:24 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZrKW-0003Zs-Ga for ipv6@ietf.org; Thu, 02 Dec 2004 08:49:10 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB2DgrSZ313516; Thu, 2 Dec 2004 13:42:53 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB2DgweW074512; Thu, 2 Dec 2004 13:42:58 GMT Received: from zurich.ibm.com (sig-9-146-220-200.de.ibm.com [9.146.220.200]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA77822; Thu, 2 Dec 2004 14:42:49 +0100 Message-ID: <41AF1BDD.9070102@zurich.ibm.com> Date: Thu, 02 Dec 2004 14:42:53 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 References: <200411182014.PAA01264@ietf.org> In-Reply-To: <200411182014.PAA01264@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: fenner@research.att.com, duerst@w3.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit I have to wonder whether we shouldn't go further, and RECOMMEND the _ format and deprecate the % format in the scoping architecture. Annoying for implementers, but then we could get cut-and-paste ability. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 17:00:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03840 for ; Thu, 2 Dec 2004 17:00:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZz63-0008Tf-0V for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 17:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZuxr-0006WB-Mf; Thu, 02 Dec 2004 12:41:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZs8V-0000e6-1R for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 09:40:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22900 for ; Thu, 2 Dec 2004 09:40:45 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZsE2-0004oc-DE for ipv6@ietf.org; Thu, 02 Dec 2004 09:46:31 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.6165600; Thu, 02 Dec 2004 09:39:40 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: From: Brian Haberman Date: Thu, 2 Dec 2004 09:39:39 -0500 X-Mailer: Apple Mail (2.619) X-esp: ESP<9>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<4> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 94375f06b91351a23b2e62bbf6b5a18c Subject: Draft Minutes of IPv6 WG meeting X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0192818403==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f3de74e534ea82d41273d2b8504db1c --===============0192818403== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--862871429; protocol="application/pkcs7-signature" --Apple-Mail-3--862871429 Content-Type: multipart/mixed; boundary=Apple-Mail-2--862871610 --Apple-Mail-2--862871610 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, Attached are the first draft of the minutes from the IPv6 WG meeting in Washington. Many thanks to Mat Ford for scribing. Please review and provide comments/clarifications/etc on the mailing list. Regards, Brian --Apple-Mail-2--862871610 Content-Type: text/plain; x-unix-mode=0644; name="ipv6wg_minutes.txt" Content-Disposition: attachment; filename=ipv6wg_minutes.txt Content-Transfer-Encoding: quoted-printable IP Version 6 WG (ipv6)=0D =0D Thursday, November 11 at 0900-1130=0D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D =0D Chair(s):=0D Robert Hinden =0D Brian Haberman =0D =0D Agenda:=0D =0D - Agenda Bashing Haberman 04 Minutes=0D =0D dupont - requests time to speak about getting /16 prefix allocated for = crypto generated id's.=0D hinden - if we have time=0D =0D haberman - tahi interop test announcement - similar structure to = previous tahi tests, some new things for ike, nemo, etc. more info at = tahi web page.=0D =0D - Document Status Haberman 01 Minute=0D http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html=0D= =0D no issues or comments on document status=0D =0D - Milestone Updates Hinden 10 Minutes=0D =0D http://www.ietf.org/html.charters/ipv6-charter.html=0D chairs have worked with ADs to update charter milestones. the = things-done list is bigger than the to-do list :).=0D hope to get outstanding work done within next couple of ietf meetings.=0D= =0D - Node Information Queries Hinden 10 Minutes=0D - Goal: determine direction of the work=0D =0D last draft is -10, now shipping in several implementations. need to get = this published. was consensus after vienna provided some clarifications = on privacy addresses are made. plan was to make those changes and then = submit as PS. is there anyone interested working on this? author hasn't = been active lately.=0D =0D no questions/comments=0D =0D - Privacy Addresses v2 Krishnan 15 Minutes=0D - Goal: Progress as Draft Standard=0D - draft-ietf-ipv6-privacy-addrs-v2-01.txt=0D =0D what's new? - see slides=0D =0D hinden - agrees there are no interop issues, nor is the new algorithm = better or worse, but the issues which caused the community to switch = don't relate to this. there is no reason for implementors to change. the = goal is not to get people to change code to comply with this. need to = make this clear in doc.=0D =0D krishnan - has change pending that may require code changes=0D =0D hinden - well we can't do that, but let's discuss it when you present = the change=0D =0D greg daley - we already understand well what well-distributed random = numbers are. just need references to docs that explain that.=0D =0D krishnan - does have reference=0D =0D open issues=0D - per-prefix knobs (will break backwards compatibility)=0D =0D ralph droms - how does it break backwards compatibility?=0D author - not required in previous version of rfc3041=0D thaler - don't make it a must, make it a may or a should and then it is = a non-issue=0D savola - this is connected to next issues regarding ULAs, so should = discuss these together=0D hain - this is no different to changing the default of generate or not. = if you get per-prefix knobs, nodes that do that don't break older = implementations. just means that older nodes are doing something = different. =0D nordmark - is there any possibility that the tie-breaker rules in = RFC3848 has any interaction with this?=0D hain - if you don't have one of these suffixes then tie-breaker won't = take effect.=0D thaler - longest-prefix match is last rule, so this comes in first. = prefix doesn't matter until you've looked at every other rule there is.=0D= =0D - isatap and rfc2526 downref=0D thaler - don't have problem with new text. avoiding isatap addrs isn't = really a MUST.=0D =0D - unique local addresses=0D do they need temp addrs?=0D =0D daley - don't treat them differently, at least don't explicitly exclude=0D= hinden - yes, they're just unicast prefixes, don't treat them = differently=0D hain - agrees shouldn't consider them to be different, but there is a = strong bias for operators to not want random values to show up in their = internal network. so probably don't want to do this in the ULA case. = per-prefix knobs solves this problem.=0D carpenter - ULAs special? yes and no. in large company they're not = special at all. outside that company those addrs are a bug. should be = prefix specific and then ULA is just a special prefix.=0D nordmark - agrees=0D thaler - only concern about per-prefix knobs is that hosts won't know = their prefix until they get RA, so how does host get configured?=0D krishnan - it is configured on host, hasn't thought about how this is = administered.=0D savola - assume many enterprises will want to use ULAs for local = communication only, but might still want to generate temp addrs for = global communication. therefore recommend that by default ULAs don't = generate temp addrs. but then you need normative ref to something that = defines ULA.=0D hinden - might be better to put text in ULA doc as this doc is going to = DS.=0D hain - are you considering lifetime support?=0D krishnan - higher lifetime is bound to RA, but max for temp addr is = independent of that.=0D hain - per-prefix knobs might require per-prefix temp valid lifetime=0D thaler - pleas make clear that prefix doesn't need to be subnet prefix = but something shorter could be used=0D hinden - that would work well for regular unicast addresses as well=0D =0D -02 version has been submitted, but hasn't been published yet. ULA text = is in there.=0D =0D -64-bit IID only?=0D will add clarifying text to say that IIDs don't have to be 64 bit, but = this text only applies to 64-bit IIDs.=0D =0D Any other issues?=0D droms - if there will be another rev and opportunity to comment, then he = has new text that doesn't need to be discussed here=0D krishnan - there will be another rev=0D =0D =0D - IPv6 over PPP v2 Varada 10 Minutes=0D - Goal: Progress as Draft Standard=0D - draft-ietf-ipv6-over-ppp-v2-01.txt=0D =0D no changes since last -01 rev was released in June=0D =0D is in last call now=0D =0D one editorial change planned, unless further comments come in=0D =0D please review and make any comments on the mailing list soon.=0D =0D savola - i have provided feedback a couple of times, but has not gone = anywhere other than author contacting me off list. what i see as = problematic is that DAD can be disabled under certain circumstances, but = doesn't say how implementations figure out whether these circumstances = are met.=0D =0D haberman - will take action to talk to author to see what's going on = with those comments.=0D =0D - AD feedback on 2462 update Jinmei 20 Minutes=0D - Goal: Resolve AD comments=0D - draft-ietf-ipv6-rfc2462bis-06.txt=0D =0D WGLC completed in July 2004, new rev -06 published in August=0D submitted to IESG in Sept, AD review finished in Oct=0D two major issues=0D - M/O flag clarification=0D - confusing wording regarding 'stateful' vs dhcpv6=0D would like to confirm mailing list consensus in this meeting=0D =0D M/O flag behaviour=0D - proposed resolution - describe details on flags in separate PS doc=0D - (draft-daniel-ipv6-ra-mo-flags-01.txt, just adopted as WG work item)=0D= =0D stateful vs dhcpv6=0D - wording used as part of the 'O' flag, clarify why we use 'stateful' = while RFC3736 calls it 'stateless', ugly but didn't want to introduce = radical change - AD comment - it's just confusing=0D proposed resolution - remove 'stateful' and just use dhcpv6 instead, = should be ok if we agree with the previous change, RFC2462bis won't use = the phrase of 'other stateful config' for the O flag. additional effects = - 2461bis and M/O doc will need to be modified.=0D =0D nordmark - 2461 uses 'stateful' in 4 or 5 places. if we change name of O = flag to 'other config' then we're fine. replace 'stateful' with dhcpv6 = as appropriate in 2461bis.=0D =0D droms - agrees with nordmark.=0D =0D other minor issues=0D - change on the 'A' flag=0D what happens if value of A flag changes over time=0D answer: nothing - should be pretty clear in section 5.5.3.=0D =0D droms - can't think of situation were previously advertised prefix = becomes unavailable for autonomous auto-config, but just wants to be = clear that this is being prohibited by this=0D =0D nordmark - prefixes should time out for SAAD. receiving a prefix means = nothing. this needs to be clarified=0D =0D tatuya - this doesn't seem to be a substantial issue=0D =0D nordmark - if setting A flag off doesn't result in prefixes timing out = for SAAD, then there is a problem, right?=0D =0D wasserman - if previously advertised prefix is re-advertised without A = flag, then don't stop using previously configured address. but if = lifetime times out, then you have to stop using the addr. needs = clarifications for implementors.=0D =0D hain - agrees with margaret. during multi6 discussion there was some = talk about prefixes in the RA used to determine whether this is the same = link, so there might be a reason for RAs to turn up with A flag off = (just to serve as link determinants).=0D =0D krishnan - thinks this is already clear from current text.=0D =0D daley - DNA is looking at link identification. link identification using = prefixes might be a product of DNA design team. there may be some = subtleties here. people may be relying on what they believe existing = behaviour to be, so clarification may be useful here.=0D =0D tatuya - let's confirm consensus on mailing list, if changes are = required then he will make them in next rev.=0D =0D other issues=0D terminology ordering - alphabetical or 'as is'?=0D wasserman - it's fine as it is=0D =0D need ref to addr-arch in LL conf - will do=0D =0D inconsistent wording regarding DAD section. just a wording issue - = replace lowercase 'must' with 'should' to avoid possible confusion.=0D =0D next steps=0D verify proposed resolutions to issues are OK. several positive responses = and no negative ones on list. so WG agreeing on course of action.=0D =0D revised draft will be issued including further clarifications and = changes and discussed above.=0D snapshot is available at = http://www.jinmei.org/draft-ietf-ipv6-rfc262bis-07beta1.txt=0D =0D hold it waiting for 2461bis? another AD comment=0D proceed to IETF LC anyway?=0D =0D Daley - has this already completed WG LC?=0D Tatuya - Yes. Initial AD review has also been done.=0D =0D Chairs - will send to IESG with 2461bis when that is ready.=0D =0D =0D =0D Router selection draft update - dave thaler=0D =0D draft -05 passed wg last call, submitted to IESG=0D several editorial nits, and 2 technical ones=0D draft-06 addresses all but 1 issue=0D editorial nits are available on issues list for this draft=0D all included in -06=0D =0D implicit deletion (issue from Thomas Narten)=0D - delete all routes if router lifetime -> 0?=0D - no, requires explicit deletion of each route, therefore no change in = -06=0D current behaviour is also consistent with Prefix Info Opts=0D Narten - when I made comment, I had notion that default router that = stops being router, doesn't make sense to forward traffic to it any = more. =0D nordmark - there might be a useful distinction between default router =3D = send me packet and i'll send it off where i can, and being a good router = for default...=0D thaler - draft addresses this already, there is some discussion and an = example or two=0D thaler - interpreation of router lifetime is lifetime of presence of = router in default router list=0D some discussion between narten and thaler that went too fast for me to = catch, but sounded like agreement :)=0D =0D last two issues are separate on issues list, but turn out to be the same = issue=0D 24 dynamic routes (alex zinin), 27 end-to-end reachability (steve = bellovin)=0D =0D zinin has submitted text=0D =0D savola - isn't this issue also in basic RA? are we trying to fix a = specific case of a more generic problem here? is this the right place to = fix this? maybe as this is a PS while ND is going for DS, but fixing it = in ND might be more appropriate as that is where the problem is.=0D =0D thaler - that's true=0D =0D nordmark - redirects should take care of this. introducing = more-specifics makes this more complex.=0D =0D thaler - having two on-link routers that don't co-operate can be made to = work with this.=0D =0D wasserman - doesn't think this is reasonable text. agrees that routers = dumping tables to hosts is obviously brain-dead, but this doesn't seem = like it makes sense.=0D =0D thaler - clarifies=0D =0D wasserman - this still seems over-constrained. why MUST routers have = this level of state complexity?=0D =0D thaler - zinin said that not doing route-damping in this scenrio is a = 'recipe for disaster'=0D =0D savola - operationally this damping-feature is not called for. not = typically implemented in IGPs. doesn't see the use here. does see the = benefit of only advertising a prefix if link is up.=0D =0D nordmark - two routers on link that don't co-operate is a scenario where = this doesn't help, so what are we really solving with this.=0D =0D arturo azcorra - involved in research project working on home-gateways. = thinks home gateway will typically have capabilities for routing, = security=0D =0D savola - what about damping?=0D =0D azcorra - don't know=0D =0D hinden - being a backup or master tied to state of uplink is = well-understood concept and there is lots of experience about that. = doesn't want to tie this to route-damping. if you're going to do this, = make sure it's stable - a general statement would help here, but the = proposed text is too prescriptive.=0D =0D pascal thubert - does MAY correspond to point 1 and point 2? point 2 = explicity excludes some potentially useful functionality.=0D =0D krishnan - this only usefully applies to home gateways, so don't need = damping=0D =0D savola - could be two home routers, then it might be useful. operational = status of link only goes so far.=0D =0D thaler - this is the 'better than nothing' case. authors have no = preference. sounds like there is rough consensus to keep the first = sentence, change point1 to SHOULD and remove point2.=0D =0D no objections=0D =0D - Multi6 Update Nordmark 20 Minutes=0D - Progress update=0D =0D WG is at:=0D identify proposals for further development - recharter=0D =0D soliman - have there been any discussions about failure discovery and = propagating that to the site=0D nordmark - there is a draft that talks about how to detect working path. = ipv6 transport protocols to give positive advice to L3 probes. also = link-layer indicators. there isn't anything about routers telling hosts = that prefixes aren't working.=0D =0D itojun - is the Design Team aware that the L3 shim is basically a = host-based NAT?=0D =0D nordmark - there have been exchanges about this on the multi6 list. = depends what you mean by NAT. this is 1:1 mapping across whole system, = which is not what NAT does. =0D =0D hinden - clarification - so IPsec would work?=0D =0D nordmark - yes=0D =0D itojun - presentation at app area meeting is required because you have = broken something at L3?=0D =0D nordmark - no, the issue is that if apps today are doing caching or = referalls then they won't get benefit of the existence of multiple other = locators. so apps need to switch to using FQDN or keep track of full = list of IP locators - this is the message that apps area needs to hear.=0D= =0D hinden - this is really cool stuff, good job. in last slide, this = provides multihoming to small sites that would never run BGP. People who = run BGP have a solution today. don't lose the benefits for small sites = by focussing on large sites.=0D =0D nordmark - issue is middle-ground where providing some policy tweaks = might reduce pressure for small sites to go to the BGP solution. is = there something easy that can be done to widen applicability.=0D =0D savola - of course small v4 sites solution is to use NAT.=0D =0D huston - BGP is BGP. the issue about why do it this way as distinct from = the way it is done with IPv4 is related to fundamental considerations = about the scalability of BGP. BGP won't handle the load if multihoming = for small sites gets popular.=0D =0D soliman - do you need this if you have mobileipv6?=0D =0D nordmark - interactions with mobility have to be considered. =0D =0D jason schiller - need a mechanism for doing multihoming for small orgs.=0D= =0D hinden - does this have characteristic that people who deploy it get to = be multihomed, or does it require other people to play ball too?=0D =0D nordmark - peers don't have to be multihomed, but have to implement = protocol to produce multihoming benefits. has been suggested that for = transition reasons a proxy might be a nice way to go, but that proxy = turns out to have nat-like characteristics.=0D =0D bagnulo - need to upgrade both hosts to preserve established = communications through outages, but there are other problems that are = solved without needing to upgrade peers.=0D =0D carpenter - full benefits needs both hosts to have code in their stacks, = but there is no flag-day. deployment is 'creeping'. conscious choice not = to solve mobility problem in multi6 - keen to keep these two problems = orthogonal.=0D =0D pascal hubert - could this replace nemo or mip route optimisation? = doesn't know, but both groups should keep track of what each other are = doing going forward. route-projection concept may be useful for multi6 = for example. lot of synergies to be gained, even if requirements are not = shared.=0D =0D =0D =0D - Address Selection for multihoming Matsumoto 10 Minutes=0D - Goal: Informational=0D - draft-arifumi-multi6-sas-policy-dist-00.txt=0D =0D same slides as were presented to multi6 mtg yesterday.=0D =0D thaler - src and dst come from common prefix. RFC3484 rule number 7? = says prefer longest-prefix match. don't see any other rule to override = that, so you'd get the desired behaviour already. these examples don't = seem to require this mechanism.=0D =0D hain - the issue is where end node is talking with someone *beyond* ISP = B. these examples don't show that.=0D =0D droms - initial example also needs prefix C added to WGP-A network that = has no more bits in common to prefixes A and B.=0D =0D thaler - right, but router selection draft also deals with this. =0D =0D droms - there are cases where the router selection draft isn't enough=0D =0D soliman - even if you construct a case where router selection draft = isn't enough, it doesn't seem practical. please come back with a = practical example.=0D =0D hain - case 2 is already a practical example.=0D =0D soliman - why isn't router selection sufficient=0D =0D hain - this is a different approach to the same problem that may be = desirable in some circumstances=0D =0D thaler - agrees with hain that router selection can't help here.=0D =0D soliman - but if you configure routers correctly router selection does = work=0D =0D hain - 'correctly' is a relative term, if you have two provider = provisioned routers that you have no control over, they are configured = according to each providers definition of 'correct', that may not be = useful=0D =0D tatuya - be more specific about prefix C that causes the problem - this = will help to clarify the problem and the need for the solution=0D =0D thaler - agrees this is a problem. not convinced this is the best way to = solve it.=0D =0D hinden - chairs view is that this needs more consideration and = discussion before there is any need for WG to consider what to do.=0D =0D =0D =0D =0D - Anycast Analysis Chairs 10 Minutes=0D - Goal: determine direction of the work=0D - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt=0D =0D basic problem is that there are disagreements on content of document in = IESG. chairs have discussed with ADs and asked them to return doc to WG = so that issues can be addressed. will go into 'AD-is-watching' state.=0D =0D also have another anycast BCP document that is being considered for = adoption by grow WG. this is dealing with IPv4 anycast BCP at the = moment. input on IPv6 anycast is appreciated.=0D =0D savola - it is useful to clarify somewhere that the role of anycast in = ipv6 specs may be slightly different than what people expect. but the = issue is that now that we have this document on 'shared-unicast', what = should the ipv6 wg be documenting? is it right to do this work here now = given that scope might change significantly?=0D =0D lindquist - this might be better in the grow WG - it's not IPv6 specific = - it's operational.=0D =0D haberman - need to decide this as a group - will have this discussion on = the mailing list after people have had time to digest work of itojun, = kurtis and new anycast mailing list.=0D =0D kitamura - is setting up anycast mailing list. issue is different from = current situation with anycast. don't care if itojun's work goes to BCP = in this WG or not - will start discussion anyway.=0D =0D hinden - another WG to focus on this may be a good idea=0D =0D lindquist - this is good work that needs to be done, wasn't trying to = prevent it being done.=0D --Apple-Mail-2--862871610-- --Apple-Mail-3--862871429 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjAyMTQzOTQwWjAjBgkqhkiG9w0B CQQxFgQUAO2P/XBHlbP1D9SdrJdoJOOx3ioweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAz7dkoYb109X3iA9Dh9zmdr1WF30nR1rgdyexRJz6tPXJUTT39i+UigyWc9v8CIonOeEz o8AYvpw+YISuHnR5u6KIKhiLdTkeo0HI0ZZ1/1PApqDnQ2Ej6ht2D+nRc8FFF0O6RLIMG5gpdScs gVi8tl9pQ8f21OsUegsu9Lmkc8vrynlB45JsOZaIfXpoUt3GEsRn581NazpqyJ1dSpbdhHrbWfKG 4GvNnxv5wwTkweStbSZS30ORZLsfUd9dcXahn7r0HFg2VQw3jwnRAMnbbHRb0amf6Yjrr4ddoUzk RklskS3bNAXcdUuIABaAV4efSIk2jLQ4OkKCB1DxD6VxEwAAAAAAAA== --Apple-Mail-3--862871429-- --===============0192818403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0192818403==-- From ipv6-bounces@ietf.org Thu Dec 2 17:22:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06024 for ; Thu, 2 Dec 2004 17:22:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzQX-0000dt-3D for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 17:27:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZywO-0001MU-Et; Thu, 02 Dec 2004 16:56:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZxt1-0004zP-0N for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 15:49:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28368 for ; Thu, 2 Dec 2004 15:49:08 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZxyb-0006g1-25 for ipv6@ietf.org; Thu, 02 Dec 2004 15:54:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB2KJua22383; Thu, 2 Dec 2004 12:19:56 -0800 X-mProtect: <200412022019> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdYU0dhY; Thu, 02 Dec 2004 12:19:54 PST Message-Id: <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 02 Dec 2004 12:48:20 -0800 To: Brian E Carpenter From: Bob Hinden In-Reply-To: <41AF1BDD.9070102@zurich.ibm.com> References: <200411182014.PAA01264@ietf.org> <41AF1BDD.9070102@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: fenner@research.att.com, duerst@w3.org, IPv6 Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Brian, At 05:42 AM 12/02/2004, Brian E Carpenter wrote: >I have to wonder whether we shouldn't go further, and RECOMMEND >the _ format and deprecate the % format in the scoping architecture. > >Annoying for implementers, but then we could get cut-and-paste ability. I agree that getting "cut and paste" is a big usability win. Does "_" create any other problems? Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 21:22:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28027 for ; Thu, 2 Dec 2004 21:22:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3BS-0006Fe-MV for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 21:28:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0Q9-0004G6-UK; Thu, 02 Dec 2004 18:31:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZyzF-0002BV-4Q for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 16:59:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03694 for ; Thu, 2 Dec 2004 16:59:38 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZz4q-0008O6-H9 for ipv6@ietf.org; Thu, 02 Dec 2004 17:05:29 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 51FF13606; Thu, 2 Dec 2004 22:59:06 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03194-03; Thu, 2 Dec 2004 22:59:05 +0100 (CET) Received: from james (I9451.i.pppool.de [85.73.148.81]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 327803605; Thu, 2 Dec 2004 22:59:05 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZyyg-00013t-TX; Thu, 02 Dec 2004 22:59:06 +0100 Date: Thu, 2 Dec 2004 22:59:06 +0100 From: Juergen Schoenwaelder To: Brian E Carpenter Message-ID: <20041202215906.GA4031@james> Mail-Followup-To: Brian E Carpenter , IPv6 , fenner@research.att.com, duerst@w3.org References: <200411182014.PAA01264@ietf.org> <41AF1BDD.9070102@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41AF1BDD.9070102@zurich.ibm.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: fenner@research.att.com, duerst@w3.org, IPv6 Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Thu, Dec 02, 2004 at 02:42:53PM +0100, Brian E Carpenter wrote: > I have to wonder whether we shouldn't go further, and RECOMMEND > the _ format and deprecate the % format in the scoping architecture. > > Annoying for implementers, but then we could get cut-and-paste ability. Are we sure this is worth the effort it takes? So far, I have not seen a real-world report that zone ids are indeed needed in URIs. This _might_ come up in the future - but do we really expect to change all the already existing code for the reason that the % does not fit easily into URIs? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 21:27:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28491 for ; Thu, 2 Dec 2004 21:27:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3GR-0006OS-93 for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 21:33:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0RA-0004Pm-7b; Thu, 02 Dec 2004 18:32:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZz1q-0002sV-KR for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 17:02:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03959 for ; Thu, 2 Dec 2004 17:02:20 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZz7R-0008Uq-H0 for ipv6@ietf.org; Thu, 02 Dec 2004 17:08:10 -0500 Received: from [10.0.1.21] (h0030653af4da.ne.client2.attbi.com[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2004120222014501100gm2qoe>; Thu, 2 Dec 2004 22:01:46 +0000 Mime-Version: 1.0 X-Sender: jeanjour@mail.comcast.net Message-Id: In-Reply-To: <41AF0FA6.20609@zurich.ibm.com> References: <3CF661B1787ABF41A869BE20108F8D6D4322CD@esebe056.ntc.nokia.com> <41AF0FA6.20609@zurich.ibm.com> Date: Thu, 2 Dec 2004 16:53:04 -0500 To: Brian E Carpenter , ipv6@ietf.org From: John Day Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: Re: Questions about geographical dependent addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Geographical is a possible topology according to all of my topology books. As every map projection illustrates by constructing a topology between the map and the physical world. Whether that topology and a particular graph have a topological relation is a different matter. A network in and of itself has no topology. At 13:50 +0100 12/2/04, Brian E Carpenter wrote: >Achim, > >>>A localisation seems to be necessary for the Internet, otherwise so many >>>people would not work on a localisation for Internet users >>>(geopriv,ecrit, etc.). > >No, this doesn't follow. The fact that there are commercial >motivations for geolocation or possible invasions of privacy >using geolocation doesn't mean it's *necessary*. In fact, in >many cases it may be highly undesirable. Preventing any >possibility of geolocation might be more desirable than >allowing it, depending on circumstances. > >... >>>As the IPv6 addresses have enough space to map an area code, I don't >>>understand why it is never be implemented. > >Because IP routing works by topology, not by geography. There is no >particular reason why logically adjacent address blocks would be >geographically adjacent. Therefore, the concept of "area code" >is simply meaningless in the IP context. > > Brian > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 21:47:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00291 for ; Thu, 2 Dec 2004 21:47:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3Za-0006w5-1J for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 21:53:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0SX-0004ye-6c; Thu, 02 Dec 2004 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZzPL-00076e-EV for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 17:26:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06965 for ; Thu, 2 Dec 2004 17:26:36 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzUw-0000mb-4C for ipv6@ietf.org; Thu, 02 Dec 2004 17:32:27 -0500 Received: from jurassic.eng.sun.com ([129.146.82.166]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iB2MQa6O028057; Thu, 2 Dec 2004 14:26:36 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iB2MQZJ9138069; Thu, 2 Dec 2004 14:26:36 -0800 (PST) Message-ID: <41AF96D9.7060000@sun.com> Date: Thu, 02 Dec 2004 14:27:37 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Draft Minutes of IPv6 WG meeting X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit > nordmark - peers don't have to be multihomed, but have to implement > protocol to produce multihoming benefits. has been suggested that for > transition reasons a proxy might be a nice way to go, but that proxy > turns out to have nat-like characteristics. > > bagnulo - need to upgrade both hosts to preserve established > communications through outages, but there are other problems that are > solved without needing to upgrade peers. Once I Marcelo reminded me I retracted part of my statement. I don't know if you want to capture that my adding my clarification, or by editing the item above to be what I meant. If the former it would make sense to add: nordmark - You're right. One can get multihoming benefits while the communication is established without requiring the peer to implement the protocol. But if you want the multihoming benefit for established connections, both ends need to implement the protocol. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 21:53:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00851 for ; Thu, 2 Dec 2004 21:53:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3fU-00077J-4T for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 21:59:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0Su-00056a-Pw; Thu, 02 Dec 2004 18:34:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZzUV-0007nJ-2m for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 17:31:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07690 for ; Thu, 2 Dec 2004 17:31:56 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZza4-0000y1-6D for ipv6@ietf.org; Thu, 02 Dec 2004 17:37:47 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C7FCE677F4 for ; Thu, 2 Dec 2004 22:31:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB2MVK9n014935; Fri, 3 Dec 2004 09:31:20 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412022231.iB2MVK9n014935@drugs.dv.isc.org> To: Bob Hinden From: Mark Andrews In-reply-to: Your message of "Thu, 02 Dec 2004 12:48:20 -0800." <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> Date: Fri, 03 Dec 2004 09:31:20 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: fenner@research.att.com, duerst@w3.org, Brian E Carpenter , IPv6 Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 > Brian, > > At 05:42 AM 12/02/2004, Brian E Carpenter wrote: > >I have to wonder whether we shouldn't go further, and RECOMMEND > >the _ format and deprecate the % format in the scoping architecture. > > > >Annoying for implementers, but then we could get cut-and-paste ability. > > I agree that getting "cut and paste" is a big usability win. Does "_" > create any other problems? You mean apart from it being part of some character sets. > Bob > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 21:56:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01115 for ; Thu, 2 Dec 2004 21:56:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3hl-0007CU-QQ for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 22:01:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0Sy-00057j-J6; Thu, 02 Dec 2004 18:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZzV2-0007nq-Fj for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 17:32:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07729 for ; Thu, 2 Dec 2004 17:32:29 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzae-0000zG-Fb for ipv6@ietf.org; Thu, 02 Dec 2004 17:38:20 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 166D1677F1 for ; Thu, 2 Dec 2004 22:32:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB2MVwf9014995; Fri, 3 Dec 2004 09:31:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412022231.iB2MVwf9014995@drugs.dv.isc.org> From: Mark Andrews In-reply-to: Your message of "Fri, 03 Dec 2004 09:31:20 +1100." Date: Fri, 03 Dec 2004 09:31:58 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: fenner@research.att.com, duerst@w3.org, Brian E Carpenter , Bob Hinden , IPv6 Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb > > > Brian, > > > > At 05:42 AM 12/02/2004, Brian E Carpenter wrote: > > >I have to wonder whether we shouldn't go further, and RECOMMEND > > >the _ format and deprecate the % format in the scoping architecture. > > > > > >Annoying for implementers, but then we could get cut-and-paste ability. > > > > I agree that getting "cut and paste" is a big usability win. Does "_" > > create any other problems? > > You mean apart from it being part of some character sets. Missed a not. You mean apart from it not being part of some character sets. > > Bob > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 22:00:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01598 for ; Thu, 2 Dec 2004 22:00:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3m0-0007LA-1e for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 22:06:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0Ta-0005Wk-Fv; Thu, 02 Dec 2004 18:35:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZzuJ-0008NS-0i for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 17:58:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10350 for ; Thu, 2 Dec 2004 17:58:36 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzzu-0001gd-3t for ipv6@ietf.org; Thu, 02 Dec 2004 18:04:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB2MSn505582; Thu, 2 Dec 2004 14:28:49 -0800 X-mProtect: <200412022228> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdeShV4L; Thu, 02 Dec 2004 14:28:47 PST Message-Id: <6.1.2.0.2.20041202144444.03680338@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 02 Dec 2004 14:57:12 -0800 To: Mark Andrews From: Bob Hinden In-Reply-To: <200412022231.iB2MVK9n014935@drugs.dv.isc.org> References: <200412022231.iB2MVK9n014935@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: fenner@research.att.com, duerst@w3.org, Brian E Carpenter , Bob Hinden , IPv6 Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Mark, > > I agree that getting "cut and paste" is a big usability win. Does "_" > > create any other problems? > > You mean apart from it being part of some character sets. I was asking if it might be special in any other operating systems, CLI's, parsers, shells, etc., where it would have to be quoted or otherwise changed. It is only worth considering this change if "cut and paste" works directly. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 22:06:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02151 for ; Thu, 2 Dec 2004 22:06:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3s6-0007V7-2o for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 22:12:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0bC-0006mS-AJ; Thu, 02 Dec 2004 18:42:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca01q-0003Zp-Q8 for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 18:06:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11121 for ; Thu, 2 Dec 2004 18:06:23 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca07T-0001rc-2G for ipv6@ietf.org; Thu, 02 Dec 2004 18:12:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB2MbFN20250; Thu, 2 Dec 2004 14:37:15 -0800 X-mProtect: <200412022237> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdzv3w9c; Thu, 02 Dec 2004 14:37:13 PST Message-Id: <6.1.2.0.2.20041202145718.037253c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 02 Dec 2004 15:05:41 -0800 To: Mark Andrews From: Bob Hinden In-Reply-To: <200412012122.iB1LM0m1040771@drugs.dv.isc.org> References: <200412012122.iB1LM0m1040771@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Mark, At 01:22 PM 12/01/2004, Mark Andrews wrote: > > > It costs real money to absorb the load. > > > > Well understood. But it will be a while before this goes mainstream. > > The point is that we really will want to legitimise what > as112 will have to do. To tell the users of these addresses > that they SHOULD / MUST configure their nameservers to cover > atleast the ULA addresses they can route to (not only their > own addresses). To tell ISP's that they can configure their > caching servers to respond to any queries that leak from > their clients. To tell those that don't use ULA's that they > can configure their servers to answer these queries and that > they won't cause problems. > > To tell users of ULA's that it is safe for them to setup > their own versions of C.F.IP6.ARPA and D.F.IP6.ARPA. > > To make it legitimate for nameserver vendors to pre-configure > there servers to block these zones with appropriate knobs > to turn them off. I think what you are proposing is a good idea, but it is out of scope for the ULA draft itself. It would be good if you put it into a new internet draft that described this and the general issues regarding putting ULAs in the global DNS. DNSOPS is a probably a better venue as there are more DNS experts there than in IPv6, but the first step is to produce the draft. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 22:29:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04418 for ; Thu, 2 Dec 2004 22:29:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca4E8-000848-Q0 for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 22:35:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca2z9-0006lF-SD; Thu, 02 Dec 2004 21:15:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0Pi-000451-Hp for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 18:31:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14337 for ; Thu, 2 Dec 2004 18:31:03 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca0VJ-0002SY-Ni for ipv6@ietf.org; Thu, 02 Dec 2004 18:36:55 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 95A7167502 for ; Thu, 2 Dec 2004 23:30:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB2NUUBb027940; Fri, 3 Dec 2004 10:30:31 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412022330.iB2NUUBb027940@drugs.dv.isc.org> To: Bob Hinden From: Mark Andrews In-reply-to: Your message of "Thu, 02 Dec 2004 15:05:41 -0800." <6.1.2.0.2.20041202145718.037253c0@mailhost.iprg.nokia.com> Date: Fri, 03 Dec 2004 10:30:30 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 > Mark, > > At 01:22 PM 12/01/2004, Mark Andrews wrote: > > > > > It costs real money to absorb the load. > > > > > > Well understood. But it will be a while before this goes mainstream. > > > > The point is that we really will want to legitimise what > > as112 will have to do. To tell the users of these addresses > > that they SHOULD / MUST configure their nameservers to cover > > atleast the ULA addresses they can route to (not only their > > own addresses). To tell ISP's that they can configure their > > caching servers to respond to any queries that leak from > > their clients. To tell those that don't use ULA's that they > > can configure their servers to answer these queries and that > > they won't cause problems. > > > > To tell users of ULA's that it is safe for them to setup > > their own versions of C.F.IP6.ARPA and D.F.IP6.ARPA. > > > > To make it legitimate for nameserver vendors to pre-configure > > there servers to block these zones with appropriate knobs > > to turn them off. > > I think what you are proposing is a good idea, but it is out of scope for > the ULA draft itself. It would be good if you put it into a new internet > draft that described this and the general issues regarding putting ULAs in > the global DNS. DNSOPS is a probably a better venue as there are more DNS > experts there than in IPv6, but the first step is to produce the draft. > > Bob The section deals with how ULA's interact with the DNS. This sort of detail needs to be there otherwise it will not be read. One can argue whether auto configuring nameservers needs to be there but the gist of the rest does. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 2 23:50:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09642 for ; Thu, 2 Dec 2004 23:50:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca5UT-0001AD-H0 for ipv6-web-archive@ietf.org; Thu, 02 Dec 2004 23:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3te-0007t4-IB; Thu, 02 Dec 2004 22:14:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca19l-0003I9-0F for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 19:18:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18383 for ; Thu, 2 Dec 2004 19:18:37 -0500 (EST) Received: from widefw.sm.sony.co.jp ([133.138.0.3] helo=nebula.sm.sony.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca1FM-0003en-Az for ipv6@ietf.org; Thu, 02 Dec 2004 19:24:30 -0500 Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.12.11/8.12.11) with ESMTP id iB30I0kg028322; Fri, 3 Dec 2004 09:18:01 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.12.11/8.12.8) id iB30I6gM025024; Thu, 2 Dec 2004 16:18:06 -0800 (PST) Date: Thu, 2 Dec 2004 16:18:06 -0800 (PST) From: Atsushi Onoe Message-Id: <200412030018.iB30I6gM025024@nest.sm.sony.co.jp> To: bob.hinden@nokia.com In-Reply-To: Your message of "Thu, 02 Dec 2004 12:48:20 -0800" <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> References: <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> X-Mailer: Cue version 0.8 (041124-1839/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: fenner@research.att.com, duerst@w3.org, brc@zurich.ibm.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > I agree that getting "cut and paste" is a big usability win. Does "_" > create any other problems? There were >100 e-mails on the ipng ML at December 1999 about the representation. Actually we considered the all possible characters. One reason to reject '_' was that it should be used for . Atsushi Onoe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 01:07:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14990 for ; Fri, 3 Dec 2004 01:07:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca6gZ-0002jV-AR for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 01:12:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3uh-0008T9-Qz; Thu, 02 Dec 2004 22:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca1jb-0005Iv-7t for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 19:55:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21783 for ; Thu, 2 Dec 2004 19:55:39 -0500 (EST) Received: from [61.134.1.142] (helo=pub.xaonline.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ca1p6-0004UB-Sl for ipv6@ietf.org; Thu, 02 Dec 2004 20:01:32 -0500 Received: from noneigu0dyydpe([218.80.215.132]) by pub.xaonline.com(AIMC 2.9.5.2) with SMTP id jma41afe59f; Fri, 03 Dec 2004 08:53:40 +0800 Message-ID: <000c01c4d8d2$ba9bf010$32c1060a@noneigu0dyydpe> From: "liqunhui" To: Date: Fri, 3 Dec 2004 08:54:51 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.2 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: question about ipv6 interface id X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2096876580==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. --===============2096876580== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C4D915.C0531EF0" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C4D915.C0531EF0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGkNCkNvdWxkIGFueWJvZHkgdGVsbCBtZSB3aHkgd2UgbmVlZCBhIDY0Yml0IGZpeGVkIGxlbmd0 aCBpbnRlcmZhY2UgaWQ/IGFuZCBkbyB3ZSByZWFsbHkgbmVlZCBhIG5ldHdvcmsgdGhhdCBjb250 YWlucyBzbyBtYW55IGhvc3RzPw0KDQpJZiByb3V0ZXIgYWR2ZXJ0aXNlIGEgcHJlZml4IHdoaWNo IGlzIGxvbmdlciB0aGFuIDY0Yml0LHRoZW4gdGhlIHBvc3NpYmlsaXR5IG9mIGFkZHJlc3MgZHVw bGljYXRpb24gaXMgaW5jcmVhc2luZy5mb3IgZXhhbXBsZSAsaXQgd2lsbCBvdmVyd3JpdGUgNTYg Yml0cyBvZiB0aGUgNjRiaXQgaW50ZXJmYWNlIGlkIHdoZW4gcm91dGVyIGFkdmVydGlzZSBhIDEy MGJpdCBsZW5ndGggcHJlZml4LnNvIG9ubHkgOCBiaXRzIGlzIGxlZnQgZm9yIGludGVyZmFjZSBp ZC5ob3cgY2FuIHdlIGRlYWwgd2l0aCB0aGlzPw0KDQpUaGFua3MNCg0KbGlxdW5odWk= ------=_NextPart_000_0009_01C4D915.C0531EF0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5oaTwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPkNvdWxkIGFueWJvZHkgdGVsbCBtZSB3aHkgd2UgbmVlZCBhIDY0 Yml0IGZpeGVkIGxlbmd0aCANCmludGVyZmFjZSBpZD8gYW5kIGRvIHdlIHJlYWxseSBuZWVkIGEg bmV0d29yayB0aGF0IGNvbnRhaW5zIHNvIG1hbnkgDQpob3N0cz88L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JZiBy b3V0ZXIgYWR2ZXJ0aXNlIGEgcHJlZml4IHdoaWNoIGlzIGxvbmdlciB0aGFuIDY0Yml0LHRoZW4g DQp0aGUgcG9zc2liaWxpdHkgb2YgYWRkcmVzcyBkdXBsaWNhdGlvbiBpcyBpbmNyZWFzaW5nLmZv ciBleGFtcGxlICxpdCB3aWxsIA0Kb3ZlcndyaXRlIDU2IGJpdHMgb2YgdGhlIDY0Yml0IGludGVy ZmFjZSBpZCB3aGVuIHJvdXRlciBhZHZlcnRpc2UgYSAxMjBiaXQgDQpsZW5ndGggcHJlZml4LnNv IG9ubHkgOCBiaXRzIGlzIGxlZnQgZm9yIGludGVyZmFjZSBpZC5ob3cgY2FuIHdlIGRlYWwgd2l0 aCANCnRoaXM/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+bGlxdW5odWk8L0ZP TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0009_01C4D915.C0531EF0-- --===============2096876580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2096876580==-- From ipv6-bounces@ietf.org Fri Dec 3 01:32:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16931 for ; Fri, 3 Dec 2004 01:32:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca75P-0003IN-5x for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 01:38:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca4bd-0005Zy-Td; Thu, 02 Dec 2004 22:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3LE-0001Hz-H5 for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 21:38:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29263 for ; Thu, 2 Dec 2004 21:38:38 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3Qr-0006eQ-GU for ipv6@ietf.org; Thu, 02 Dec 2004 21:44:30 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 04847A7ADE; Thu, 2 Dec 2004 21:38:08 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB32c7o05915; Thu, 2 Dec 2004 18:38:07 -0800 (PST) Message-Id: <200412030238.iB32c7o05915@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Mark_Andrews@isc.org Date: Thu, 2 Dec 2004 18:38:06 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: duerst@w3.org, ipv6@ietf.org, brc@zurich.ibm.com, bob.hinden@nokia.com Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >> I agree that getting "cut and paste" is a big usability win. Does "_" >> create any other problems? > > You mean apart from it [not] being part of some character sets. I'm sorry, I have to plead ignorance; I thought all character sets (other than EBCDIC) were supersets of US-ASCII. If we need to use another character, "-" / "." / "_" / "~" / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" is the set of characters that can be used without changing the URI or IRI specs. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 01:38:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17482 for ; Fri, 3 Dec 2004 01:38:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca7AX-0003QI-6m for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 01:43:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca4bh-0005al-CV; Thu, 02 Dec 2004 22:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3Qn-0002XH-EP for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 21:44:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29874 for ; Thu, 2 Dec 2004 21:44:23 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca3WR-0006pb-DM for ipv6@ietf.org; Thu, 02 Dec 2004 21:50:15 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id AB65767503 for ; Fri, 3 Dec 2004 02:43:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB32hjJH031898; Fri, 3 Dec 2004 13:43:45 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412030243.iB32hjJH031898@drugs.dv.isc.org> To: Bill Fenner From: Mark Andrews In-reply-to: Your message of "Thu, 02 Dec 2004 18:38:06 -0800." <200412030238.iB32c7o05915@windsor.research.att.com> Date: Fri, 03 Dec 2004 13:43:45 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: duerst@w3.org, ipv6@ietf.org, brc@zurich.ibm.com, bob.hinden@nokia.com Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > > >> I agree that getting "cut and paste" is a big usability win. Does "_" > >> create any other problems? > > > > You mean apart from it [not] being part of some character sets. > > I'm sorry, I have to plead ignorance; I thought all character sets > (other than EBCDIC) were supersets of US-ASCII. > > If we need to use another character, "-" / "." / "_" / "~" / > "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" > is the set of characters that can be used without changing the > URI or IRI specs. > > Bill underscore maps to right-arrow (left-arrow). Its been a long time since I used the character set in question. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 03:21:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10442 for ; Fri, 3 Dec 2004 03:21:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca8mg-0005VA-4b for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 03:27:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca7JL-0005t9-Dj; Fri, 03 Dec 2004 01:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca53I-0008Ex-VF for ipv6@megatron.ietf.org; Thu, 02 Dec 2004 23:28:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07943 for ; Thu, 2 Dec 2004 23:28:14 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca58y-0000ho-15 for ipv6@ietf.org; Thu, 02 Dec 2004 23:34:08 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 9FACB67502 for ; Fri, 3 Dec 2004 04:27:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB34RfTY056218; Fri, 3 Dec 2004 15:27:41 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412030427.iB34RfTY056218@drugs.dv.isc.org> From: Mark Andrews In-reply-to: Your message of "Fri, 03 Dec 2004 10:30:30 +1100." <200412022330.iB2NUUBb027940@drugs.dv.isc.org> Date: Fri, 03 Dec 2004 15:27:41 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be > The section deals with how ULA's interact with the DNS. > This sort of detail needs to be there otherwise it will not > be read. One can argue whether auto configuring nameservers > needs to be there but the gist of the rest does. Some text. Changing the NS records to point to BLACKHOLE-1.IANA.ORG and BLACKHOLE-2.IANA.ORG is one possible change for the example zones. --- draft-ietf-ipv6-unique-local-addr-08.txt Mon Nov 29 23:58:52 2004 +++ draft-ietf-ipv6-unique-local-addr-08.txt.new Fri Dec 3 15:22:43 2004 @@ -469,19 +469,51 @@ 4.4 DNS Issues - At the present time AAAA and PTR records for locally assigned local - IPv6 addresses are not recommended to be installed in the global DNS. - The operational issues relating to this are beyond the scope of this - document. - - For background on this recommendation, the concern about adding AAAA - and PTR records to the global DNS for locally assigned local IPv6 - addresses stems from the lack of complete assurance that the prefixes - are unique. There is a small possibility that the same PTR record - might be registered by two different organizations. Due to this - concern, adding AAAA records is thought to be unwise because matching - PTR records can not be registered + Sites using ULAs need to ensure that reverse DNS queries for ULAs do not + leak out of the site(s) using the ULAa. This is best ensured by + configuring the sites DNS servers to serve both C.F.IP6.ARPA and + D.F.IP6.ARPA in addition to anymore specific zones under these used for + local reverse lookups. + Leaking reverse queries will put extreme loads on the infrastructure + servers and has in the past required sacrificial servers to be + deployed to absorb the load cause by leaking queries. + + e.g. + The following "empty" zones will prevent queries leaking from the + zone. + + C.F.IP6.ARPA: + C.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. . ( + 1 7200 3600 604800 3600 ) + C.F.IP6.ARPA. 3600 IN NS C.F.IP6.ARPA. + C.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX + C.F.IP6.ARPA. 3600 IN NS ::1 + + D.F.IP6.ARPA: + D.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. . ( + 1 7200 3600 604800 3600 ) + D.F.IP6.ARPA. 3600 IN NS D.F.IP6.ARPA. + D.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX + C.F.IP6.ARPA. 3600 IN NS ::1 + + Multiple sites connecting using ULAs may want maintain common + C.F.IP6.ARPA and D.F.IP6.ARPA zones and use them delegate more specific + zones. It is not expected that centrally addresses will have delegations + in the global DNS tree. + + Advertising locally assigned ULA AAAA records in the global DNS is + MUST NOT occur as they are not globally unique and will lead + to unexpected connections. + + Advertising centrally assigned ULA AAAA records in the global DNS is + not encouraged at this point in time as not all applications recover + well from attempting to reach a non-reachable addresses. + + Populating the reverse zones with appropriate PTR records is at the + site's disgression. One should note that many applications will not + accept a PTR record without the associated AAAA record also being + available. Supplying this may require a split DNS configuration. 4.5 Application and Higher Level Protocol Issues -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 04:12:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14259 for ; Fri, 3 Dec 2004 04:12:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca9a1-0006av-MA for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 04:18:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca88i-0002nq-Gu; Fri, 03 Dec 2004 02:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca6Xf-0003wk-2c for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 01:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14860 for ; Fri, 3 Dec 2004 01:03:42 -0500 (EST) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ca6dL-0002fj-09 for ipv6@ietf.org; Fri, 03 Dec 2004 01:09:35 -0500 Received: (qmail 3602 invoked by uid 417); 3 Dec 2004 06:03:39 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 3 Dec 2004 06:03:39 -0000 Received: from XPNERICK ([132.70.219.59]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 02 Dec 2004 23:03:36 -0700 Message-ID: <002f01c4d8fd$af87e1e0$0401a8c0@ttitelecom.com> From: "EricLKlein" To: ipv6@ietf.org References: <1101913661.1996.92.camel@Kermit.nt.fh-koeln.de> Date: Fri, 3 Dec 2004 08:02:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Subject: Re: Questions about geographical dependent addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit As I recall we had a rather long discussion about this last year. The conclusions were that in most cases geographical dependencies were more problems then they were worth. Examples that stuck in my mind had to do with cruise ships docking at new locations and needing to reregister all addresses (as NAT is not valid in IPv6) or mobile users who are roaming and needing to get new addresses so that "home" features would be a problem (authenticating to your bank account with a new IP address, etc). I would suggest checking the archives as this went on for several months. Eric ----- Original Message ----- From: "Achim Marikar" To: Sent: 01 December, 2004 5:07 PM Subject: Questions about geographical dependent addresses > > Hello, > > I am writing my diploma thesis in information engineering at the > university of applied sciences in Cologne. One of the subjects of my > thesis is to develop an IPv6 address format which provides geographical > localisation capabilities to VoIP and other applications. > > A localisation seems to be necessary for the Internet, otherwise so many > people would not work on a localisation for Internet users > (geopriv,ecrit, etc.). In my opinion it would be necessary to assign a > user to an area code (or to an emergency call centre.) > > As the IPv6 addresses have enough space to map an area code, I don't > understand why it is never be implemented. In my opinion the 64 bits > interface ID is too long. If stateful autoconfiguration, static > addresses or the privacy extension are used, it is not possible to get > the MAC-address of the interface through the interface ID. A duplicate > address detection is still necessary. So it would be possible to reduce > the interface ID to clear space for the area code. > > Wouldn't it be the easiest way to map a reliable area code which is > validated by the provider? > Also Nomadic users could be located through their care of address. > > Thanks for comments, > > Achim Marikar > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 06:13:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23066 for ; Fri, 3 Dec 2004 06:13:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaBT1-0000Su-F8 for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 06:19:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaA9K-0008Iy-Dn; Fri, 03 Dec 2004 04:54:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca8YB-0006uC-UA for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 03:12:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09189 for ; Fri, 3 Dec 2004 03:12:22 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca8dr-0005FC-Ao for ipv6@ietf.org; Fri, 03 Dec 2004 03:18:16 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB38BmSZ297692; Fri, 3 Dec 2004 08:11:48 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB38BjSU282568; Fri, 3 Dec 2004 08:11:48 GMT Received: from zurich.ibm.com (sig-9-146-220-105.de.ibm.com [9.146.220.105]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA28324; Fri, 3 Dec 2004 09:11:38 +0100 Message-ID: <41B01FC0.9000907@zurich.ibm.com> Date: Fri, 03 Dec 2004 09:11:44 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John Day References: <3CF661B1787ABF41A869BE20108F8D6D4322CD@esebe056.ntc.nokia.com> <41AF0FA6.20609@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Questions about geographical dependent addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Sure John but the Internet's toplogy is determined by ISP interconnection and distribution topology; there is some correlation with geography of course, but it isn't intrinsic. Brian John Day wrote: > Geographical is a possible topology according to all of my topology > books. As every map projection illustrates by constructing a topology > between the map and the physical world. Whether that topology and a > particular graph have a topological relation is a different matter. A > network in and of itself has no topology. > > > > At 13:50 +0100 12/2/04, Brian E Carpenter wrote: > >> Achim, >> >>>> A localisation seems to be necessary for the Internet, otherwise so >>>> many >>>> people would not work on a localisation for Internet users >>>> (geopriv,ecrit, etc.). >> >> >> No, this doesn't follow. The fact that there are commercial >> motivations for geolocation or possible invasions of privacy >> using geolocation doesn't mean it's *necessary*. In fact, in >> many cases it may be highly undesirable. Preventing any >> possibility of geolocation might be more desirable than >> allowing it, depending on circumstances. >> >> ... >> >>>> As the IPv6 addresses have enough space to map an area code, I don't >>>> understand why it is never be implemented. >> >> >> Because IP routing works by topology, not by geography. There is no >> particular reason why logically adjacent address blocks would be >> geographically adjacent. Therefore, the concept of "area code" >> is simply meaningless in the IP context. >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 06:25:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23898 for ; Fri, 3 Dec 2004 06:25:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaBf7-0000hc-0v for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 06:31:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaALD-0003aP-Bb; Fri, 03 Dec 2004 05:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca8dc-0007X6-Lv for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 03:18:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10027 for ; Fri, 3 Dec 2004 03:17:59 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca8jI-0005Ny-Rr for ipv6@ietf.org; Fri, 03 Dec 2004 03:23:54 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB38HRVQ260572; Fri, 3 Dec 2004 08:17:27 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB38HUSU282494; Fri, 3 Dec 2004 08:17:30 GMT Received: from zurich.ibm.com (sig-9-146-220-105.de.ibm.com [9.146.220.105]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA64722; Fri, 3 Dec 2004 09:17:21 +0100 Message-ID: <41B02112.8020209@zurich.ibm.com> Date: Fri, 03 Dec 2004 09:17:22 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de References: <200411182014.PAA01264@ietf.org> <41AF1BDD.9070102@zurich.ibm.com> <20041202215906.GA4031@james> In-Reply-To: <20041202215906.GA4031@james> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: fenner@research.att.com, duerst@w3.org, IPv6 Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Thu, Dec 02, 2004 at 02:42:53PM +0100, Brian E Carpenter wrote: > > >>I have to wonder whether we shouldn't go further, and RECOMMEND >>the _ format and deprecate the % format in the scoping architecture. >> >>Annoying for implementers, but then we could get cut-and-paste ability. > > > Are we sure this is worth the effort it takes? So far, I have not > seen a real-world report that zone ids are indeed needed in URIs. > This _might_ come up in the future - but do we really expect to > change all the already existing code for the reason that the % > does not fit easily into URIs? I wish we had spotted this problem (and the problem in URLs caused by : ) much earlier... but if we don't change it now, we *never* will, which is why I asked the question. The cost of the change is high now, but will be unthinkable once v6 is in general use. I'm not convinced we should change it, but now is the time to decide. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 06:39:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25391 for ; Fri, 3 Dec 2004 06:39:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaBsD-0000ze-LO for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 06:45:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaANN-0003it-DB; Fri, 03 Dec 2004 05:09:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca8ev-0007q9-FV for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 03:19:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10195 for ; Fri, 3 Dec 2004 03:19:20 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca8kb-0005QM-LJ for ipv6@ietf.org; Fri, 03 Dec 2004 03:25:15 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iB38Ilug172822 for ; Fri, 3 Dec 2004 08:18:47 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB38IgG8022034 for ; Fri, 3 Dec 2004 09:18:42 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB38Il5k011796 for ; Fri, 3 Dec 2004 09:18:47 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB38IkBp011786; Fri, 3 Dec 2004 09:18:46 +0100 Received: from zurich.ibm.com (sig-9-146-220-105.de.ibm.com [9.146.220.105]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA28264; Fri, 3 Dec 2004 09:18:45 +0100 Message-ID: <41B0216A.50102@zurich.ibm.com> Date: Fri, 03 Dec 2004 09:18:50 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Atsushi Onoe References: <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> <200412030018.iB30I6gM025024@nest.sm.sony.co.jp> In-Reply-To: <200412030018.iB30I6gM025024@nest.sm.sony.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: fenner@research.att.com, duerst@w3.org, bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Atsushi Onoe wrote: >>I agree that getting "cut and paste" is a big usability win. Does "_" >>create any other problems? > > > There were >100 e-mails on the ipng ML at December 1999 about the > representation. Actually we considered the all possible characters. > One reason to reject '_' was that it should be used for . Why does that matter? Incompatibility with URL syntax is a much bigger problem, IMHO. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 10:42:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17757 for ; Fri, 3 Dec 2004 10:42:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaFfr-0006Qa-TB for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 10:48:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaDOk-0000pN-Vy; Fri, 03 Dec 2004 08:22:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaBmw-0006TU-K9 for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 06:39:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25434 for ; Fri, 3 Dec 2004 06:39:47 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaBsf-000109-48 for ipv6@ietf.org; Fri, 03 Dec 2004 06:45:45 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB3Bdfi3012632 for ; Fri, 3 Dec 2004 11:39:41 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA15530 for ; Fri, 3 Dec 2004 11:39:37 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB3Bdb012103 for ipv6@ietf.org; Fri, 3 Dec 2004 11:39:37 GMT Date: Fri, 3 Dec 2004 11:39:37 +0000 From: Tim Chown To: IPv6 Message-ID: <20041203113937.GI9812@login.ecs.soton.ac.uk> Mail-Followup-To: IPv6 References: <200411182014.PAA01264@ietf.org> <41AF1BDD.9070102@zurich.ibm.com> <20041202215906.GA4031@james> <41B02112.8020209@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B02112.8020209@zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Fri, Dec 03, 2004 at 09:17:22AM +0100, Brian E Carpenter wrote: > > I wish we had spotted this problem (and the problem in URLs > caused by : ) much earlier... but if we don't change it now, we > *never* will, which is why I asked the question. The cost of > the change is high now, but will be unthinkable once v6 is > in general use. > > I'm not convinced we should change it, but now is the time to decide. So what would the cost be of allowing the new syntax, while not removing the old? Then at least the capability is there to avoid the % when needed. As and when people hit the problem, they start using the newer syntax. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 12:42:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04801 for ; Fri, 3 Dec 2004 12:42:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaHXj-0003Gp-W9 for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 12:48:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaDQk-0001Xx-TT; Fri, 03 Dec 2004 08:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaCKf-0003Ip-E3; Fri, 03 Dec 2004 07:14:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27833; Fri, 3 Dec 2004 07:14:38 -0500 (EST) Message-Id: <200412031214.HAA27833@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Dec 2004 07:14:38 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-07.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, et al. Filename : draft-ietf-ipv6-link-scoped-mcast-07.txt Pages : 7 Date : 2004-12-2 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate their unique multicast addresses automatically without conflicts. Basically, this document proposes an alternative method for creating link-local multicast addresses over a known method like unicast-prefix-based IPv6 multicast addresses. It is preferred to use this method for link-local scope rather than unicast- prefix-based IPv6 multicast addresses. This memo update RFC3306. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-07.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-ipv6-link-scoped-mcast-07.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-ipv6-link-scoped-mcast-07.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-12-2115401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-2115401.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Dec 3 13:24:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15010 for ; Fri, 3 Dec 2004 13:24:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaICE-0006eE-BN for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 13:30:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaEby-0005Cm-EE; Fri, 03 Dec 2004 09:40:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaDzg-0008FC-27 for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 09:01:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05581 for ; Fri, 3 Dec 2004 09:01:06 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaE5O-00042h-VJ for ipv6@ietf.org; Fri, 03 Dec 2004 09:07:04 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB3E12i3018218 for ; Fri, 3 Dec 2004 14:01:02 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA26948 for ; Fri, 3 Dec 2004 14:01:01 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB3E11716020 for ipv6@ietf.org; Fri, 3 Dec 2004 14:01:01 GMT Date: Fri, 3 Dec 2004 14:01:01 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20041203140100.GV9812@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <200412022330.iB2NUUBb027940@drugs.dv.isc.org> <200412030427.iB34RfTY056218@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412030427.iB34RfTY056218@drugs.dv.isc.org> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Hi, Can I also add we have some discussion on this issue in the (now obsolete) draft draft-ietf-dnsop-dontpublish-unreachable-03, which can be found at: http://www.watersprings.org/pub/id/draft-ietf-dnsop-dontpublish-unreachable-03.txt After Washington IETF, a couple of us (at least myself and Alain) discussed taking this one up. One important issue is who is harmed by such publishing beyond the site advertising and sites connecting to it. What is the 3rd party impact? The above text mentions ambiguity as the key concern foor private addresses, but also talks about otehr types on unreachables. Regarding lack of uniqueness, if we cannot assume that CA ULAs are unique, then should we bother with them at all? :) Mark's mail suggests lack of such a guarantee is an issue, but that is only for non-CA prefixes, where people will be tempted to use the minimal prefix, i.e. all 0s most likely instead of a random 40 or 41 bit number (whichever it is :), because they will have to type these addresses in on an operational basis. Tim On Fri, Dec 03, 2004 at 03:27:41PM +1100, Mark Andrews wrote: > > > The section deals with how ULA's interact with the DNS. > > This sort of detail needs to be there otherwise it will not > > be read. One can argue whether auto configuring nameservers > > needs to be there but the gist of the rest does. > > Some text. > > Changing the NS records to point to BLACKHOLE-1.IANA.ORG > and BLACKHOLE-2.IANA.ORG is one possible change for the > example zones. > > --- draft-ietf-ipv6-unique-local-addr-08.txt Mon Nov 29 23:58:52 2004 > +++ draft-ietf-ipv6-unique-local-addr-08.txt.new Fri Dec 3 15:22:43 2004 > @@ -469,19 +469,51 @@ > > 4.4 DNS Issues > > - At the present time AAAA and PTR records for locally assigned local > - IPv6 addresses are not recommended to be installed in the global DNS. > - The operational issues relating to this are beyond the scope of this > - document. > - > - For background on this recommendation, the concern about adding AAAA > - and PTR records to the global DNS for locally assigned local IPv6 > - addresses stems from the lack of complete assurance that the prefixes > - are unique. There is a small possibility that the same PTR record > - might be registered by two different organizations. Due to this > - concern, adding AAAA records is thought to be unwise because matching > - PTR records can not be registered > + Sites using ULAs need to ensure that reverse DNS queries for ULAs do not > + leak out of the site(s) using the ULAa. This is best ensured by > + configuring the sites DNS servers to serve both C.F.IP6.ARPA and > + D.F.IP6.ARPA in addition to anymore specific zones under these used for > + local reverse lookups. > > + Leaking reverse queries will put extreme loads on the infrastructure > + servers and has in the past required sacrificial servers to be > + deployed to absorb the load cause by leaking queries. > + > + e.g. > + The following "empty" zones will prevent queries leaking from the > + zone. > + > + C.F.IP6.ARPA: > + C.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. . ( > + 1 7200 3600 604800 3600 ) > + C.F.IP6.ARPA. 3600 IN NS C.F.IP6.ARPA. > + C.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX > + C.F.IP6.ARPA. 3600 IN NS ::1 > + > + D.F.IP6.ARPA: > + D.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. . ( > + 1 7200 3600 604800 3600 ) > + D.F.IP6.ARPA. 3600 IN NS D.F.IP6.ARPA. > + D.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX > + C.F.IP6.ARPA. 3600 IN NS ::1 > + > + Multiple sites connecting using ULAs may want maintain common > + C.F.IP6.ARPA and D.F.IP6.ARPA zones and use them delegate more specific > + zones. It is not expected that centrally addresses will have delegations > + in the global DNS tree. > + > + Advertising locally assigned ULA AAAA records in the global DNS is > + MUST NOT occur as they are not globally unique and will lead > + to unexpected connections. > + > + Advertising centrally assigned ULA AAAA records in the global DNS is > + not encouraged at this point in time as not all applications recover > + well from attempting to reach a non-reachable addresses. > + > + Populating the reverse zones with appropriate PTR records is at the > + site's disgression. One should note that many applications will not > + accept a PTR record without the associated AAAA record also being > + available. Supplying this may require a split DNS configuration. > > 4.5 Application and Higher Level Protocol Issues > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 14:41:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27160 for ; Fri, 3 Dec 2004 14:41:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaJP7-0001ua-Br for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 14:47:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaInd-0005OE-9V; Fri, 03 Dec 2004 14:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaHIn-0007IX-JT for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 12:33:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02045 for ; Fri, 3 Dec 2004 12:33:03 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaHOY-0002Op-Ub for ipv6@ietf.org; Fri, 03 Dec 2004 12:39:04 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id EDA5C19735B; Fri, 3 Dec 2004 12:21:09 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB3HWWT17511; Fri, 3 Dec 2004 09:32:32 -0800 (PST) Message-Id: <200412031732.iB3HWWT17511@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: onoe@sm.sony.co.jp References: <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> <200412030018.iB30I6gM025024@nest.sm.sony.co.jp> Date: Fri, 3 Dec 2004 09:32:31 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: duerst@w3.org, ipv6@ietf.org, brc@zurich.ibm.com, bob.hinden@nokia.com Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >There were >100 e-mails on the ipng ML at December 1999 about the >representation. Actually we considered the all possible characters. >One reason to reject '_' was that it should be used for . There are very few messages (around 10) in the archive that actually discuss the specifics of delimiter selection (mostly with subject "Re: Scope ID secret Cabal (minutes)"). The only message that I saw suggesting that "-", "." and "_" might be reserved because they could be used in the also said that he preferred "-" or "_" as the delimiter. I'd say that message could be used to argue for either side of the issue. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 15:34:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03840 for ; Fri, 3 Dec 2004 15:34:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKE8-0003yc-7E for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 15:40:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJwI-0007yu-1q; Fri, 03 Dec 2004 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJpH-0004Zj-12 for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 15:14:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01755 for ; Fri, 3 Dec 2004 15:14:45 -0500 (EST) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaJv3-0003HM-I4 for ipv6@ietf.org; Fri, 03 Dec 2004 15:20:47 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA09501; Fri, 3 Dec 2004 15:14:31 -0500 (EST) Date: Fri, 3 Dec 2004 15:14:31 -0500 (EST) From: Dan Lanciani Message-Id: <200412032014.PAA09501@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Mark Andrews wrote: |+ Advertising locally assigned ULA AAAA records in the global DNS is |+ MUST NOT occur as they are not globally unique and will lead |+ to unexpected connections. I strongly object to making this a "MUST NOT," especially with the growing uncertainty that there will ever be a _permanent_ centrally assigned flavor of ULA available without recurring fees. An important feature of even locally assigned ULAs is that they are globally unique "enough" for many/most purposes that have been discussed. After months of analysis to that end, their lack of absolute uniqueness is insufficient to justify adding new prohibition on a particular range of uses at this late date. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 15:59:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06074 for ; Fri, 3 Dec 2004 15:59:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKcZ-0004pC-5s for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 16:05:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaKUj-0001h4-Va; Fri, 03 Dec 2004 15:57:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaKMB-0007WP-2v for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 15:48:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05278 for ; Fri, 3 Dec 2004 15:48:45 -0500 (EST) Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKRx-0004QK-KT for ipv6@ietf.org; Fri, 03 Dec 2004 15:54:47 -0500 Received: from 168-103-170-166.tukw.qwest.net[168.103.170.166] (helo=dochome) by mrelay.perfora.net with ESMTP (Nemesis), id 0MKz1m-1CaKM243lR-0001zH; Fri, 03 Dec 2004 15:48:38 -0500 X-Provags-ID: perfora.net abuse@perfora.net login:e889f076272915782d1e6806691de79b Message-ID: <0MKz1m-1CaKM243lR-0001zH@mrelay.perfora.net> From: "Brian McGehee" To: Date: Fri, 3 Dec 2004 12:48:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200412032014.PAA09501@ss10.danlan.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTZd4k8wJJZdPZLTeKF6ZcX6GfJ0QAAO/PA X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: RE: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit I have to agree with this MUST NOT. |+ Advertising locally assigned ULA AAAA records in the global DNS |+ MUST NOT occur as they are not globally unique and will lead |+ to unexpected connections. Although there is a good chance that someone else in the world has my same name, they don't receive their mail at my home address. OK, Bad example (reversed). But if there is a chance of overlap; allowing this insures there is a chance of misdirection. $.02 -Brian http://consult.tavian.com -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Dan Lanciani Sent: Friday, December 03, 2004 12:15 PM To: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt Mark Andrews wrote: |+ Advertising locally assigned ULA AAAA records in the global DNS is |+ MUST NOT occur as they are not globally unique and will lead |+ to unexpected connections. I strongly object to making this a "MUST NOT," especially with the growing uncertainty that there will ever be a _permanent_ centrally assigned flavor of ULA available without recurring fees. An important feature of even locally assigned ULAs is that they are globally unique "enough" for many/most purposes that have been discussed. After months of analysis to that end, their lack of absolute uniqueness is insufficient to justify adding new prohibition on a particular range of uses at this late date. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 17:14:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10704 for ; Fri, 3 Dec 2004 17:14:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaLmt-0006PS-P5 for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 17:20:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaKxN-0002yX-1U; Fri, 03 Dec 2004 16:27:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaKie-0001Lg-On for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 16:12:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06807 for ; Fri, 3 Dec 2004 16:11:58 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKoR-00055L-GF for ipv6@ietf.org; Fri, 03 Dec 2004 16:18:01 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 26C1E368A for ; Fri, 3 Dec 2004 22:11:25 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07696-10; Fri, 3 Dec 2004 22:11:24 +0100 (CET) Received: from james (Ibd66.i.pppool.de [85.73.189.102]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 2A3433669; Fri, 3 Dec 2004 22:11:24 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CaKi2-0000cm-Nz; Fri, 03 Dec 2004 22:11:22 +0100 Date: Fri, 3 Dec 2004 22:11:22 +0100 From: Juergen Schoenwaelder To: IPv6 Message-ID: <20041203211122.GB2298@james> Mail-Followup-To: IPv6 References: <200411182014.PAA01264@ietf.org> <41AF1BDD.9070102@zurich.ibm.com> <20041202215906.GA4031@james> <41B02112.8020209@zurich.ibm.com> <20041203113937.GI9812@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041203113937.GI9812@login.ecs.soton.ac.uk> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Fri, Dec 03, 2004 at 11:39:37AM +0000, Tim Chown wrote: > So what would the cost be of allowing the new syntax, while not removing > the old? Then at least the capability is there to avoid the % when needed. > As and when people hit the problem, they start using the newer syntax. Allowing both syntaxes is IMHO worse than sticking with what we have. Lets face it: Even if we decide today to move from % to _, it will take several years to get rid of the % notation in installed systems. If we allow both, this process might take even longer. While IPv6 might not be used as much as we like, it is widely implemented and the code is out there in customer hands. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 18:51:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21176 for ; Fri, 3 Dec 2004 18:51:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaNIf-000137-5j for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 18:57:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaN3f-0005D5-B9; Fri, 03 Dec 2004 18:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaMzT-0003bx-KF for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 18:37:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20373 for ; Fri, 3 Dec 2004 18:37:28 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaN5I-0000kY-Tk for ipv6@ietf.org; Fri, 03 Dec 2004 18:43:33 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 8B274677EF for ; Fri, 3 Dec 2004 23:36:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB3Nal62080800; Sat, 4 Dec 2004 10:36:47 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412032336.iB3Nal62080800@drugs.dv.isc.org> To: Dan Lanciani From: Mark Andrews In-reply-to: Your message of "Fri, 03 Dec 2004 15:14:31 CDT." <200412032014.PAA09501@ss10.danlan.com> Date: Sat, 04 Dec 2004 10:36:47 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 > Mark Andrews wrote: > > |+ Advertising locally assigned ULA AAAA records in the global DNS is > |+ MUST NOT occur as they are not globally unique and will lead > |+ to unexpected connections. > > I strongly object to making this a "MUST NOT," especially with the growing > uncertainty that there will ever be a _permanent_ centrally assigned flavor > of ULA available without recurring fees. Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG. If you need to publish them in the DNS you need to use a split DNS configuration. This is no different to how we handle RFS 1918 address. They don't get published in the GLOBAL DNS because they are AMBIGIOUS. > An important feature of even locally assigned ULAs is that they are globally > unique "enough" for many/most purposes that have been discussed. After month > s > of analysis to that end, their lack of absolute uniqueness is insufficient to > justify adding new prohibition on a particular range of uses at this late dat > e. They are unique enough to link serveral hundred / thousand sites *with minimal renumbering required*. They are not unique enough to link millions of sites where the is no way of knowing that renumbering is required. You just cant filter them out of global respones especially once DNSSEC is in use. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 19:32:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23688 for ; Fri, 3 Dec 2004 19:32:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaNwF-0001oc-NY for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 19:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaNh4-0002Lm-Mu; Fri, 03 Dec 2004 19:22:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaNVN-0007BV-55 for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 19:10:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22411 for ; Fri, 3 Dec 2004 19:10:26 -0500 (EST) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaNbC-0001Pm-CG for ipv6@ietf.org; Fri, 03 Dec 2004 19:16:31 -0500 Received: from stephen (ip151.post-vineyard.dfw.ygnition.net [66.135.181.151]) by ns2.sea (8.13.1/8.12.5) with SMTP id iB409qwR031892; Fri, 3 Dec 2004 16:09:54 -0800 Message-ID: <073b01c4d995$94ce0260$6801a8c0@stephen> From: "Stephen Sprunk" To: "Brian McGehee" , References: <0MKz1m-1CaKM243lR-0001zH@mrelay.perfora.net> Date: Fri, 3 Dec 2004 17:39:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Thus spake "Brian McGehee" >I have to agree with this MUST NOT. > > |+ Advertising locally assigned ULA AAAA records in the global DNS > |+ MUST NOT occur as they are not globally unique and will lead > |+ to unexpected connections. > > Although there is a good chance that someone else in the world has my same > name, they don't receive their mail at my home address. OK, Bad example > (reversed). But if there is a chance of overlap; allowing this insures > there is a chance of misdirection. My original thought in allowing ULA AAAA records in the global DNS was that it is not operationally feasible to expose those records to all of the hosts that have connectivity to those addresses and no others, particularly when you're using them to communicate privately to another organization. There is certainly a failure mode where two parties may inadvertently select the same prefix and one may get traffic intended for the other due to entries in the global DNS, but that is no different from someone publishing a ULA IP address on a web page instead of a DNS name that points to that address. The failure is the collision, not the DNS entry. I did think about this and considered the odds of the above happening to be significantly lower than the risk of a host not being able to resolve names for machines it can reach via a ULA because it (or its nameserver) is inadvertently using the global DNS instead of a local zone file. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 20:15:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27003 for ; Fri, 3 Dec 2004 20:15:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaObh-0002jw-41 for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 20:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaOOW-00008l-Sb; Fri, 03 Dec 2004 20:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaNzJ-0000qP-1o for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 19:41:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24551 for ; Fri, 3 Dec 2004 19:41:22 -0500 (EST) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaO58-00020f-JH for ipv6@ietf.org; Fri, 03 Dec 2004 19:47:27 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id TAA14212; Fri, 3 Dec 2004 19:41:20 -0500 (EST) Date: Fri, 3 Dec 2004 19:41:20 -0500 (EST) From: Dan Lanciani Message-Id: <200412040041.TAA14212@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Mark Andrews wrote: |> Mark Andrews wrote: |> |> |+ Advertising locally assigned ULA AAAA records in the global DNS is |> |+ MUST NOT occur as they are not globally unique and will lead |> |+ to unexpected connections. |> |> I strongly object to making this a "MUST NOT," especially with the growing |> uncertainty that there will ever be a _permanent_ centrally assigned flavor |> of ULA available without recurring fees. | | Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG. Wrong in what way? Morally? If you don't want to be troubled by the presence of locally assinged ULAs in my forward DNS, just don't request names from my forward DNS. | If you need to publish them in the DNS you need to use a | split DNS configuration. No, that will not work if I want to use locally assigned ULA addresses for dynamic tunnels that anyone can access. And in any case, do you really want us to be in a position of mandating split DNS? I have no objection to folks running split DNS if they so desire, but I do not so desire and I certainly do not wish to force split DNS on anyone. |This is no different to how we handle | RFS 1918 address. Umm, if locally assigned ULA addresses are going to have to be treated the same as RFC1918 addresses, why couldn't we have just kept site local addresses? |They don't get published in the GLOBAL DNS | because they are AMBIGIOUS. Merely repeating this assertion (even IN ALL CAPS) really isn't a useful argument. We have spent many months discussing ULAs as a solution to the ambiguity of site local addresses. This seems like a last minute attempt to cripple them. |> An important feature of even locally assigned ULAs is that they are globally |> unique "enough" for many/most purposes that have been discussed. After month |> s |> of analysis to that end, their lack of absolute uniqueness is insufficient to |> justify adding new prohibition on a particular range of uses at this late dat |> e. | | They are unique enough to link serveral hundred / thousand sites | *with minimal renumbering required*. | | They are not unique enough to link millions of sites where the | is no way of knowing that renumbering is required. Even if you are correct that they are not unique enough to link millions of sites (and I do not accept that you are correct--duplicates could be handled by cooperating sites by a de facto uniqueness mechanism outside the scope of this proposal) how does this justify restricting the utility of locally assigned ULAs in the several hundred/thousand sites case? How about a compromise? Let's first insure that centrally assigned ULAs are available for permanent assignment with no recurring fees (and at most a nominal initial fee). Once that is accomplished we would be in a better position to weigh the costs/benefits of recommending locally assigned ULAs in various contexts. Such recommendations could be in a document separate from the core ULA document. Restricting the use of locally assigned ULAs before we even know whether there will be an alternative seems a bit rash. After all, this topic has been under discussion for a very long time; what's the rush now? Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 21:23:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02363 for ; Fri, 3 Dec 2004 21:23:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaPfZ-0004C2-KT for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 21:29:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaPRR-0006e3-Tz; Fri, 03 Dec 2004 21:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaPNH-0004Qo-0n for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 21:10:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01578 for ; Fri, 3 Dec 2004 21:10:13 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaPT7-0003yE-IM for ipv6@ietf.org; Fri, 03 Dec 2004 21:16:18 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 696F2677F2 for ; Sat, 4 Dec 2004 02:09:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB429afs029184; Sat, 4 Dec 2004 13:09:36 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412040209.iB429afs029184@drugs.dv.isc.org> To: Dan Lanciani From: Mark Andrews In-reply-to: Your message of "Fri, 03 Dec 2004 19:41:20 CDT." <200412040041.TAA14212@ss10.danlan.com> Date: Sat, 04 Dec 2004 13:09:36 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 > Mark Andrews wrote: > > |> Mark Andrews wrote: > |> > |> |+ Advertising locally assigned ULA AAAA records in the global DNS is > |> |+ MUST NOT occur as they are not globally unique and will lead > |> |+ to unexpected connections. > |> > |> I strongly object to making this a "MUST NOT," especially with the growing > |> uncertainty that there will ever be a _permanent_ centrally assigned flavo > r > |> of ULA available without recurring fees. > | > | Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG. > > Wrong in what way? Morally? If you don't want to be troubled by the > presence of locally assinged ULAs in my forward DNS, just don't request > names from my forward DNS. A host may have *both* a LOCALLY ASSIGNED ULA and a global addresses. In fact this is highly likely. If I have a machine withe the same ULA when I attempt to connect the remote machine I will get my machine according to the address selection rules. > | If you need to publish them in the DNS you need to use a > | split DNS configuration. > > No, that will not work if I want to use locally assigned ULA addresses for > dynamic tunnels that anyone can access. And in any case, do you really want > us to be in a position of mandating split DNS? I have no objection to folks > running split DNS if they so desire, but I do not so desire and I certainly > do not wish to force split DNS on anyone. Then choose a centrally assigned ULA. The two types of ULA have different usage patterns. Pick the correct one for the job. > |This is no different to how we handle > | RFS 1918 address. > > Umm, if locally assigned ULA addresses are going to have to be treated the > same as RFC1918 addresses, why couldn't we have just kept site local addresse > s? Centrally assigned ULAs are globally unique. The restiction if you read what was written above was on LOCALLY ASSIGNED ULAs. There is a choice. You choose which set of tradeoffs to apply when select your ULA. You could even have one of each type. > |They don't get published in the GLOBAL DNS > | because they are AMBIGIOUS. > > Merely repeating this assertion (even IN ALL CAPS) really isn't a useful > argument. We have spent many months discussing ULAs as a solution to the > ambiguity of site local addresses. This seems like a last minute attempt > to cripple them. No. It is a attempt to prevent harm from incorrect use. > |> An important feature of even locally assigned ULAs is that they are global > ly > |> unique "enough" for many/most purposes that have been discussed. After mo > nth > |> s > |> of analysis to that end, their lack of absolute uniqueness is insufficient > to > |> justify adding new prohibition on a particular range of uses at this late > dat > |> e. > | > | They are unique enough to link serveral hundred / thousand sites > | *with minimal renumbering required*. > | > | They are not unique enough to link millions of sites where the > | is no way of knowing that renumbering is required. > > Even if you are correct that they are not unique enough to link millions > of sites (and I do not accept that you are correct--duplicates could be > handled by cooperating sites by a de facto uniqueness mechanism outside > the scope of this proposal) how does this justify restricting the utility > of locally assigned ULAs in the several hundred/thousand sites case? > > How about a compromise? Let's first insure that centrally assigned ULAs > are available for permanent assignment with no recurring fees (and at most > a nominal initial fee). Once that is accomplished we would be in a better > position to weigh the costs/benefits of recommending locally assigned ULAs > in various contexts. Such recommendations could be in a document separate > from the core ULA document. Restricting the use of locally assigned ULAs > before we even know whether there will be an alternative seems a bit rash. > After all, this topic has been under discussion for a very long time; what's > the rush now? It's not rash. They have limitations. The fact that you don't like the limitatitions does not mean that they should not be acknowledged and dealt with appropriately. > Dan Lanciani > ddl@danlan.*com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 3 23:21:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09369 for ; Fri, 3 Dec 2004 23:21:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaRWa-0006Qj-Eg for ipv6-web-archive@ietf.org; Fri, 03 Dec 2004 23:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaRMY-0005im-Pn; Fri, 03 Dec 2004 23:17:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaRKS-0004ut-5n for ipv6@megatron.ietf.org; Fri, 03 Dec 2004 23:15:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08881 for ; Fri, 3 Dec 2004 23:15:25 -0500 (EST) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaRQH-0006JU-E7 for ipv6@ietf.org; Fri, 03 Dec 2004 23:21:31 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id XAA16785; Fri, 3 Dec 2004 23:15:20 -0500 (EST) Date: Fri, 3 Dec 2004 23:15:20 -0500 (EST) From: Dan Lanciani Message-Id: <200412040415.XAA16785@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Mark Andrews wrote: |> Mark Andrews wrote: |> |> |> Mark Andrews wrote: |> |> |> |> |+ Advertising locally assigned ULA AAAA records in the global DNS is |> |> |+ MUST NOT occur as they are not globally unique and will lead |> |> |+ to unexpected connections. |> |> |> |> I strongly object to making this a "MUST NOT," especially with the growing |> |> uncertainty that there will ever be a _permanent_ centrally assigned flavo |> r |> |> of ULA available without recurring fees. |> | |> | Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG. |> |> Wrong in what way? Morally? If you don't want to be troubled by the |> presence of locally assinged ULAs in my forward DNS, just don't request |> names from my forward DNS. | | A host may have *both* a LOCALLY ASSIGNED ULA and a global | addresses. In fact this is highly likely. If I have a | machine withe the same ULA when I attempt to connect the | remote machine I will get my machine according to the address | selection rules. This may be true, but it is not responsive in spite of the tasteful use of ALL CAPS. You are starting with the premise that you are attempting to access my machines by looking up a name in my DNS. If you don't like the way I populate my DNS then you don't need to use my DNS. |> | If you need to publish them in the DNS you need to use a |> | split DNS configuration. |> |> No, that will not work if I want to use locally assigned ULA addresses for |> dynamic tunnels that anyone can access. And in any case, do you really want |> us to be in a position of mandating split DNS? I have no objection to folks |> running split DNS if they so desire, but I do not so desire and I certainly |> do not wish to force split DNS on anyone. | | Then choose a centrally assigned ULA. As I'm sure you are aware, centrally assigned ULAs are not currently available and their future availability on the terms originally suggested is becoming increasingly unlikely. |The two types of ULA have | different usage patterns. Pick the correct one for the job. When the proposal to create ULAs was "split" in order to accommodate a longer process for the centrally assigned flavor (because of the supposed need for comments from the existing address registries) the locally assigned flavor had the necessary attributes to support a wide variety of usage patterns. You propose to restrict the usage of the locally assigned flavor in such a way that many interesting applications will demand the centrally assigned flavor. I propose that if we really want to do that then we should first insure that the centrally assigned flavor comes into existence on reasonable terms. |> |This is no different to how we handle |> | RFS 1918 address. |> |> Umm, if locally assigned ULA addresses are going to have to be treated the |> same as RFC1918 addresses, why couldn't we have just kept site local addresse |> s? | | Centrally assigned ULAs are globally unique. The restiction if | you read what was written above was on LOCALLY ASSIGNED ULAs. And if you read what I wrote above you will see that I was indeed speaking of locally assigned ULAs, even though I didn't put it IN ALL CAPS. | There is a choice. You choose which set of tradeoffs to apply | when select your ULA. You could even have one of each type. This is a false choice. It is impossible to choose the set of tradeoffs because we have no idea what the attributes of centrally assigned ULAs (if they ever exist at all) will be. Basically, we copped out on mandating the critical attributes of centrally assigned ULAs (permanent assignment, low one-time fee) yet now you want to mandate restrictions on locally assigned ULAs that will force a requirement for the centrally assigned flavor. |> |They don't get published in the GLOBAL DNS |> | because they are AMBIGIOUS. |> |> Merely repeating this assertion (even IN ALL CAPS) really isn't a useful |> argument. We have spent many months discussing ULAs as a solution to the |> ambiguity of site local addresses. This seems like a last minute attempt |> to cripple them. | | No. It is a attempt to prevent harm from incorrect use. Harm to whom? |> |> An important feature of even locally assigned ULAs is that they are global |> ly |> |> unique "enough" for many/most purposes that have been discussed. After mo |> nth |> |> s |> |> of analysis to that end, their lack of absolute uniqueness is insufficient |> to |> |> justify adding new prohibition on a particular range of uses at this late |> dat |> |> e. |> | |> | They are unique enough to link serveral hundred / thousand sites |> | *with minimal renumbering required*. |> | |> | They are not unique enough to link millions of sites where the |> | is no way of knowing that renumbering is required. |> |> Even if you are correct that they are not unique enough to link millions |> of sites (and I do not accept that you are correct--duplicates could be |> handled by cooperating sites by a de facto uniqueness mechanism outside |> the scope of this proposal) how does this justify restricting the utility |> of locally assigned ULAs in the several hundred/thousand sites case? |> |> How about a compromise? Let's first insure that centrally assigned ULAs |> are available for permanent assignment with no recurring fees (and at most |> a nominal initial fee). Once that is accomplished we would be in a better |> position to weigh the costs/benefits of recommending locally assigned ULAs |> in various contexts. Such recommendations could be in a document separate |> from the core ULA document. Restricting the use of locally assigned ULAs |> before we even know whether there will be an alternative seems a bit rash. |> After all, this topic has been under discussion for a very long time; what's |> the rush now? I see that you declined to reply to my suggested compromise. How about we make centrally assigned ULAs work before we break locally assigned ULAs? | It's not rash. They have limitations. You are confusing architectural limitations with administrative restrictions. The architectural limitation of locally assigned ULAs is that there is some chance of duplication. This implies that exposure of such addresses outside of the realm in which their uniqueness can be guaranteed may lead to ambiguity. This is true regardless of the mechanism used to expose those addresses: global DNS, some other name lookup system, or even the passing of a literal address in some random protocol. Your proposal to prohibit locally assigned ULAs from the global DNS is an administrative restriction--one which considerably devalues the addresses in question. |The fact that you | don't like the limitatitions does not mean that they should | not be acknowledged and dealt with appropriately. The limitations of locally assigned ULAs have been acknowledged and discussed extensively. Your proposal to create an administrative restriction does nothing to deal with the limitations; it merely forces the use of an as yet undefined alternative where locally assigned ULAs would have been sufficient. This is very reminiscent of the original site local debates. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 4 00:22:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12815 for ; Sat, 4 Dec 2004 00:22:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaST2-0007bv-OO for ipv6-web-archive@ietf.org; Sat, 04 Dec 2004 00:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaSKP-0005Hy-P1; Sat, 04 Dec 2004 00:19:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaSJ2-00048G-2J for ipv6@megatron.ietf.org; Sat, 04 Dec 2004 00:18:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12359 for ; Sat, 4 Dec 2004 00:18:01 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaSOs-0007XN-Pn for ipv6@ietf.org; Sat, 04 Dec 2004 00:24:08 -0500 Received: from ocean.jinmei.org (PPP296.air128.dti.ne.jp [210.170.213.70]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E90C11521D; Sat, 4 Dec 2004 14:17:55 +0900 (JST) Date: Sat, 04 Dec 2004 14:17:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy T. Fielding" In-Reply-To: References: <200411191457.iAJEvaZ12916@windsor.research.att.com> <6.1.2.0.2.20041119101916.01f65b30@mailhost.iprg.nokia.com> <200411192057.iAJKvAr18036@windsor.research.att.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Bill Fenner , ipv6@ietf.org, uri@w3.org, bob.hinden@nokia.com Subject: Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 >>>>> On Fri, 19 Nov 2004 19:03:51 -0800, >>>>> "Roy T. Fielding" said: > I don't think that they are actively used for significant operations. > Yes, they are implemented (inconsistently) on multiple platforms > (some allow names to occur after the '%", while others assume that > the zone ID will be a small integer), (a minor note) draft-ietf-ipv6-scoping-arch-02.txt specifies integers as the minimum set of scope zone IDs that all implementations must support. All compliant specifications must accept decimal integers, and *BSDs should behave so, although it prints attached interface name by default. > There is nothing we can do in the specifications to change the > fact that using a % as a zone ID separator in URIs will result in > interoperability failures. Those applications are already deployed. > It would be easier to change all of the deployed operating systems > that contain IPv6 to allow an additional delimiter character if > cut-and-paste is really important. I don't buy this argument. We can also say that system libraries with '%' '%' as the delimiter and applications using the libraries are already deployed. As others already said, BSDs have been using for several years, which is also merged into MacOS X. In addition, as far as I know recent versions of Windows and Linux implementations adopt this specification. I would say that saying "these are not actively used for significant operations." is misleading. First of all, what "significant operations" mean is really not clear. Additionally, why can we be so sure that they are not actively used without knowing how real IPv6 operators do or do not use the syntax? As an IPv6 operator, I often use this notation for diagnosing IPv6 routers or in some cases DHCPv6/DNS servers. I'm not insisting that we can ignore the deployed parser that are not friendly with the '%' delimiter. I just want to note that we cannot simply say "XXX is not so deployed so it would be easier to fix it", whether the XXX is existing systems with the % delimiter or existing parsers which are unfriendly with the '%' delimiter. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 4 00:27:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13274 for ; Sat, 4 Dec 2004 00:27:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaSY4-0007ib-Cx for ipv6-web-archive@ietf.org; Sat, 04 Dec 2004 00:33:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaSKR-0005IG-45; Sat, 04 Dec 2004 00:19:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaSJF-0004Hd-Ex for ipv6@megatron.ietf.org; Sat, 04 Dec 2004 00:18:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12365 for ; Sat, 4 Dec 2004 00:18:14 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaSP7-0007Y1-SD for ipv6@ietf.org; Sat, 04 Dec 2004 00:24:22 -0500 Received: from ocean.jinmei.org (PPP296.air128.dti.ne.jp [210.170.213.70]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 31C0A15220; Sat, 4 Dec 2004 14:18:11 +0900 (JST) Date: Sat, 04 Dec 2004 14:18:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200411192057.iAJKvAr18036@windsor.research.att.com> References: <200411191457.iAJEvaZ12916@windsor.research.att.com> <6.1.2.0.2.20041119101916.01f65b30@mailhost.iprg.nokia.com> <200411192057.iAJKvAr18036@windsor.research.att.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ipv6@ietf.org, uri@w3.org, bob.hinden@nokia.com Subject: Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a >>>>> On Fri, 19 Nov 2004 15:57:06 -0500, >>>>> Bill Fenner said: >> My dump question (that exposes my lack of knowledge about URIs/etc.) is >> since the literal IPv6 address are enclosed in "[" "]" to allow for the ":" >> in the literal IPv6 address, why can't the "%" be used in the same >> way? For example: >> >> http://[fe80::20d:60ff:fe2f:8df5%4] >> >> Please excuse my ignorance on this, but it would be good to explain this >> (and include this information in the draft). (snip) > The basic issue is how special % is in URLs, because of > percent-encoding. Section 2.4 of draft-fielding-uri-rfc2396bis > (the full Standard URI spec, currently in the RFC-Editor's queue) > says: > Because the percent ("%") character serves as the indicator for > percent-encoded octets, it must be percent-encoded as "%25" in order > for that octet to be used as data within a URI. > The newer IRI spec (in IESG Evaluation; draft-duerst-iri-10.txt) > specifies an encoding of URIs to IRIs that assumes that any percent > anywhere in the URI begins a percent-encoded octet. Allowing a > bare "%" would complicate these rules quite a bit. There would be > no way to know without parsing the URI further whether the % began > a %-encoded octet or not. I see the complication in the specification. But aside from the specification issue, if you allow me ask a naive question as an implementor I'm still wondering why we cannot parse the syntax like http://[fe80::20d:60ff:fe2f:8df5%4] implementation-wise. If I were a parser programmer, I'd first find the pair of [ and ], and then pass the content (fe80::20d:60ff:fe2f:8df5%4) to a name-to-address conversion function such as getaddrinfo(). I'd do this procedure before doing sanity checks on the % character as an escape character. Of course, it is technically a bad idea to rely on such a hidden assumption. If we were going to make the specification from the scratch, I'd oppose to that. However, (in my understanding) we are discussing a more subtle issue; how to deal with the inconsistency between the 100%-compliant URI (or IRI) syntax and existing and deployed implementations. So, we'll probably seek a reasonable compromise... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 4 00:33:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13678 for ; Sat, 4 Dec 2004 00:33:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaSdY-0007pQ-P6 for ipv6-web-archive@ietf.org; Sat, 04 Dec 2004 00:39:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaSKS-0005Il-6Y; Sat, 04 Dec 2004 00:19:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaSJU-0004Z3-Qs for ipv6@megatron.ietf.org; Sat, 04 Dec 2004 00:18:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12380 for ; Sat, 4 Dec 2004 00:18:29 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaSPL-0007YL-Hq for ipv6@ietf.org; Sat, 04 Dec 2004 00:24:37 -0500 Received: from ocean.jinmei.org (PPP296.air128.dti.ne.jp [210.170.213.70]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 03E4115218; Sat, 4 Dec 2004 14:18:25 +0900 (JST) Date: Sat, 04 Dec 2004 14:18:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200412031732.iB3HWWT17511@windsor.research.att.com> References: <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> <200412030018.iB30I6gM025024@nest.sm.sony.co.jp> <200412031732.iB3HWWT17511@windsor.research.att.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: duerst@w3.org, bob.hinden@nokia.com, onoe@sm.sony.co.jp, brc@zurich.ibm.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 >>>>> On Fri, 3 Dec 2004 09:32:31 -0800, >>>>> Bill Fenner said: >> There were >100 e-mails on the ipng ML at December 1999 about the >> representation. Actually we considered the all possible characters. >> One reason to reject '_' was that it should be used for . > There are very few messages (around 10) in the archive that actually > discuss the specifics of delimiter selection (mostly with subject "Re: > Scope ID secret Cabal (minutes)"). The only message that I saw suggesting > that "-", "." and "_" might be reserved because they could be used in > the also said that he preferred "-" or "_" as the delimiter. > I'd say that message could be used to argue for either side of the issue. I've also been recalling the previous discussions, including non-public, internal ones. And I admit we did not find any clear conflict with "_" at that time. If we just started the scope-arch work, it would definitely be better to adopt "_", not "%". The problem is that % as the delimiter has been in the scope-arch spec for several years, and implementations using the spec have been quite widely deployed, making the transition costly. So, IMO, we need to make a decision considering following points: 1. how costly it is to change the existing implementation 2. how seriously we want (to allow) the use of scoped address syntax in IRIs or URIs I'm quite sure opinions vary on these points. Speaking for myself, I'm very reluctant to change the existing implementations. Regarding the migration cost, I basically agree with Juergen. I'd also really like to ask others not to underestimate the deployment base. Regarding point 2, I personally suspect the reality, at the risk of exposing my ignorance. I remember two possible use cases were shown: - configuring a home router/dhcp/dns server via HTTP via a link-local address - SNMP URIs that get passed between different agents/managers on the same system. In the former case, I guess we can simply use the "default zone ID" in many cases (although some implementations may not yet support that, in which case we'll need to fix them). I'd say the latter use case is very minor, while I must admit just saying "it should be minor" is not convincing. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I've noticed the draft-ietf-ipv6-scoping-arch-02.txt has been in the RFC editor queue for over 3 months. Is anyone know whether this is a usual delay or the issues with the URI syntax is working as a showstopper? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 4 01:32:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17266 for ; Sat, 4 Dec 2004 01:32:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaTYh-0000WU-GA for ipv6-web-archive@ietf.org; Sat, 04 Dec 2004 01:38:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaTRC-00039E-1N; Sat, 04 Dec 2004 01:30:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaTQZ-0002oP-TW for ipv6@megatron.ietf.org; Sat, 04 Dec 2004 01:29:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17178 for ; Sat, 4 Dec 2004 01:29:54 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaTWS-0000UK-LF for ipv6@ietf.org; Sat, 04 Dec 2004 01:36:01 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id CF81F677F9 for ; Sat, 4 Dec 2004 06:29:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB46TA2l077349; Sat, 4 Dec 2004 17:29:10 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412040629.iB46TA2l077349@drugs.dv.isc.org> To: Dan Lanciani From: Mark Andrews In-reply-to: Your message of "Fri, 03 Dec 2004 23:15:20 CDT." <200412040415.XAA16785@ss10.danlan.com> Date: Sat, 04 Dec 2004 17:29:10 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 > Mark Andrews wrote: > > |> Mark Andrews wrote: > |> > |> |> Mark Andrews wrote: > |> |> > |> |> |+ Advertising locally assigned ULA AAAA records in the global DNS i > s > |> |> |+ MUST NOT occur as they are not globally unique and will lead > |> |> |+ to unexpected connections. > |> |> > |> |> I strongly object to making this a "MUST NOT," especially with the grow > ing > |> |> uncertainty that there will ever be a _permanent_ centrally assigned fl > avo > |> r > |> |> of ULA available without recurring fees. > |> | > |> | Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG. > |> > |> Wrong in what way? Morally? If you don't want to be troubled by the > |> presence of locally assinged ULAs in my forward DNS, just don't request > |> names from my forward DNS. > | > | A host may have *both* a LOCALLY ASSIGNED ULA and a global > | addresses. In fact this is highly likely. If I have a > | machine withe the same ULA when I attempt to connect the > | remote machine I will get my machine according to the address > | selection rules. > > This may be true, but it is not responsive in spite of the tasteful use of > ALL CAPS. You are starting with the premise that you are attempting to > access my machines by looking up a name in my DNS. If you don't like the > way I populate my DNS then you don't need to use my DNS. If it in the global DNS is in NOT "your DNS". It is everybodies. If you want to put it in your DNS then use split DNS. Stop polluting the commons. > |> | If you need to publish them in the DNS you need to use a > |> | split DNS configuration. > |> > |> No, that will not work if I want to use locally assigned ULA addresses for > |> dynamic tunnels that anyone can access. And in any case, do you really wa > nt > |> us to be in a position of mandating split DNS? I have no objection to fol > ks > |> running split DNS if they so desire, but I do not so desire and I certainl > y > |> do not wish to force split DNS on anyone. > | > | Then choose a centrally assigned ULA. > > As I'm sure you are aware, centrally assigned ULAs are not currently availabl > e > and their future availability on the terms originally suggested is becoming > increasingly unlikely. Centrally assigned ULAs will appear. > |The two types of ULA have > | different usage patterns. Pick the correct one for the job. > > When the proposal to create ULAs was "split" in order to accommodate a longer > process for the centrally assigned flavor (because of the supposed need for > comments from the existing address registries) the locally assigned flavor > had the necessary attributes to support a wide variety of usage patterns. > You propose to restrict the usage of the locally assigned flavor in such a > way that many interesting applications will demand the centrally assigned > flavor. I propose that if we really want to do that then we should first > insure that the centrally assigned flavor comes into existence on reasonable > terms. > |> |This is no different to how we handle > |> | RFS 1918 address. > |> > |> Umm, if locally assigned ULA addresses are going to have to be treated the > |> same as RFC1918 addresses, why couldn't we have just kept site local addre > sse > |> s? > | > | Centrally assigned ULAs are globally unique. The restiction if > | you read what was written above was on LOCALLY ASSIGNED ULAs. > > And if you read what I wrote above you will see that I was indeed speaking > of locally assigned ULAs, even though I didn't put it IN ALL CAPS. > > | There is a choice. You choose which set of tradeoffs to apply > | when select your ULA. You could even have one of each type. > > This is a false choice. It is impossible to choose the set of tradeoffs > because we have no idea what the attributes of centrally assigned ULAs (if > they ever exist at all) will be. Basically, we copped out on mandating the > critical attributes of centrally assigned ULAs (permanent assignment, low > one-time fee) yet now you want to mandate restrictions on locally assigned > ULAs that will force a requirement for the centrally assigned flavor. You believe permanent assignment, low one-time fee was manditory. I never did. The *only* thing critical about centrally assigned addresses is that that are uniquely assigned within the specified address range. The rest is just nice to have. If the registries charge too much then people will move to locally assigned ULA and live with the limitations imposed by those addresses. > |> |They don't get published in the GLOBAL DNS > |> | because they are AMBIGIOUS. > |> > |> Merely repeating this assertion (even IN ALL CAPS) really isn't a useful > |> argument. We have spent many months discussing ULAs as a solution to the > |> ambiguity of site local addresses. This seems like a last minute attempt > |> to cripple them. > | > | No. It is a attempt to prevent harm from incorrect use. > > Harm to whom? Harm to users of the DNS. RFC 1535 was written in response to resolvers return address which connected to the wrong machines when putting in fully qualified addresses. You are asking the WG to endore a similar policy because you believe centrally assigned addresses will never occur. > |> |> An important feature of even locally assigned ULAs is that they are glo > bal > |> ly > |> |> unique "enough" for many/most purposes that have been discussed. After > mo > |> nth > |> |> s > |> |> of analysis to that end, their lack of absolute uniqueness is insuffici > ent > |> to > |> |> justify adding new prohibition on a particular range of uses at this la > te > |> dat > |> |> e. > |> | > |> | They are unique enough to link serveral hundred / thousand sites > |> | *with minimal renumbering required*. > |> | > |> | They are not unique enough to link millions of sites where the > |> | is no way of knowing that renumbering is required. > |> > |> Even if you are correct that they are not unique enough to link millions > |> of sites (and I do not accept that you are correct--duplicates could be > |> handled by cooperating sites by a de facto uniqueness mechanism outside > |> the scope of this proposal) how does this justify restricting the utility > |> of locally assigned ULAs in the several hundred/thousand sites case? > |> > |> How about a compromise? Let's first insure that centrally assigned ULAs > |> are available for permanent assignment with no recurring fees (and at most > |> a nominal initial fee). Once that is accomplished we would be in a better > |> position to weigh the costs/benefits of recommending locally assigned ULAs > |> in various contexts. Such recommendations could be in a document separate > |> from the core ULA document. Restricting the use of locally assigned ULAs > |> before we even know whether there will be an alternative seems a bit rash. > |> After all, this topic has been under discussion for a very long time; what > 's > |> the rush now? > > I see that you declined to reply to my suggested compromise. How about we > make centrally assigned ULAs work before we break locally assigned ULAs? > > | It's not rash. They have limitations. > > You are confusing architectural limitations with administrative restrictions. > The architectural limitation of locally assigned ULAs is that there is some > chance of duplication. This implies that exposure of such addresses outside > of the realm in which their uniqueness can be guaranteed may lead to ambiguit > y. > This is true regardless of the mechanism used to expose those addresses: glob > al > DNS, some other name lookup system, or even the passing of a literal address > in some random protocol. > > Your proposal to prohibit locally assigned ULAs from the global DNS is an > administrative restriction--one which considerably devalues the addresses > in question. They were already devalued. It was inherent consequence of the assignment technique. You must be the only one who thought that publishing of locally assigned ULA in the global DNS was going to occur. I know from the start as should have anyone who has ever dealt with site locals / link local / RFC 1918 addresses that there were never going to be published in the global DNS. They were by ther very nature abmigious. The fact that I said MUST NOT should not have come as suprise to anyone here. Sure the addresses will leak from time to time. You don't however deliberately *publish* them however. > |The fact that you > | don't like the limitatitions does not mean that they should > | not be acknowledged and dealt with appropriately. > > The limitations of locally assigned ULAs have been acknowledged and discussed > extensively. Your proposal to create an administrative restriction does > nothing to deal with the limitations; it merely forces the use of an as yet > undefined alternative where locally assigned ULAs would have been sufficient. > This is very reminiscent of the original site local debates. Site local was much worse. Here you choose which type of address to use. One with may require a fee vs one that is free. One which you can publish in the global dns vs one which you can't. One that you should never have to renumber vs one which you may have to renumber. > Dan Lanciani > ddl@danlan.*com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 4 03:25:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09987 for ; Sat, 4 Dec 2004 03:25:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaVKh-0002rE-R9 for ipv6-web-archive@ietf.org; Sat, 04 Dec 2004 03:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaV3R-0001Lg-69; Sat, 04 Dec 2004 03:14:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaUzc-00009J-Ic for ipv6@megatron.ietf.org; Sat, 04 Dec 2004 03:10:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08789 for ; Sat, 4 Dec 2004 03:10:10 -0500 (EST) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaV5U-0002VQ-Q9 for ipv6@ietf.org; Sat, 04 Dec 2004 03:16:18 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id DAA20285; Sat, 4 Dec 2004 03:10:05 -0500 (EST) Date: Sat, 4 Dec 2004 03:10:05 -0500 (EST) From: Dan Lanciani Message-Id: <200412040810.DAA20285@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Mark Andrews wrote: |> Mark Andrews wrote: |> |> |> Mark Andrews wrote: |> |> |> |> |> Mark Andrews wrote: |> |> |> |> |> |> |+ Advertising locally assigned ULA AAAA records in the global DNS i |> s |> |> |> |+ MUST NOT occur as they are not globally unique and will lead |> |> |> |+ to unexpected connections. |> |> |> |> |> |> I strongly object to making this a "MUST NOT," especially with the grow |> ing |> |> |> uncertainty that there will ever be a _permanent_ centrally assigned fl |> avo |> |> r |> |> |> of ULA available without recurring fees. |> |> | |> |> | Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG. |> |> |> |> Wrong in what way? Morally? If you don't want to be troubled by the |> |> presence of locally assinged ULAs in my forward DNS, just don't request |> |> names from my forward DNS. |> | |> | A host may have *both* a LOCALLY ASSIGNED ULA and a global |> | addresses. In fact this is highly likely. If I have a |> | machine withe the same ULA when I attempt to connect the |> | remote machine I will get my machine according to the address |> | selection rules. |> |> This may be true, but it is not responsive in spite of the tasteful use of |> ALL CAPS. You are starting with the premise that you are attempting to |> access my machines by looking up a name in my DNS. If you don't like the |> way I populate my DNS then you don't need to use my DNS. | | If it in the global DNS is in NOT "your DNS". It is everybodies. What are you talking about? The data in my DNS resides in my servers or in servers that I contract to hold it. You don't see it unless you query those servers. | If you want to put it in your DNS then use split DNS. Stop | polluting the commons. This is not a commons issue. Stop trying to assert jurisdiction over my property. |> |> | If you need to publish them in the DNS you need to use a |> |> | split DNS configuration. |> |> |> |> No, that will not work if I want to use locally assigned ULA addresses for |> |> dynamic tunnels that anyone can access. And in any case, do you really wa |> nt |> |> us to be in a position of mandating split DNS? I have no objection to fol |> ks |> |> running split DNS if they so desire, but I do not so desire and I certainl |> y |> |> do not wish to force split DNS on anyone. |> | |> | Then choose a centrally assigned ULA. |> |> As I'm sure you are aware, centrally assigned ULAs are not currently availabl |> e |> and their future availability on the terms originally suggested is becoming |> increasingly unlikely. | | Centrally assigned ULAs will appear. I never said that they will not, only that it is unlikely that they will exist on the terms originally suggested in discussion by this working group. |> |The two types of ULA have |> | different usage patterns. Pick the correct one for the job. |> |> When the proposal to create ULAs was "split" in order to accommodate a longer |> process for the centrally assigned flavor (because of the supposed need for |> comments from the existing address registries) the locally assigned flavor |> had the necessary attributes to support a wide variety of usage patterns. |> You propose to restrict the usage of the locally assigned flavor in such a |> way that many interesting applications will demand the centrally assigned |> flavor. I propose that if we really want to do that then we should first |> insure that the centrally assigned flavor comes into existence on reasonable |> terms. I see that you again declined to respond to my proposal that we first insure that the centrally assigned ULAs come into existence on reasonable terms. |> |> |This is no different to how we handle |> |> | RFS 1918 address. |> |> |> |> Umm, if locally assigned ULA addresses are going to have to be treated the |> |> same as RFC1918 addresses, why couldn't we have just kept site local addre |> sse |> |> s? |> | |> | Centrally assigned ULAs are globally unique. The restiction if |> | you read what was written above was on LOCALLY ASSIGNED ULAs. |> |> And if you read what I wrote above you will see that I was indeed speaking |> of locally assigned ULAs, even though I didn't put it IN ALL CAPS. |> |> | There is a choice. You choose which set of tradeoffs to apply |> | when select your ULA. You could even have one of each type. |> |> This is a false choice. It is impossible to choose the set of tradeoffs |> because we have no idea what the attributes of centrally assigned ULAs (if |> they ever exist at all) will be. Basically, we copped out on mandating the |> critical attributes of centrally assigned ULAs (permanent assignment, low |> one-time fee) yet now you want to mandate restrictions on locally assigned |> ULAs that will force a requirement for the centrally assigned flavor. | | You believe permanent assignment, low one-time fee was manditory. In as much as those attributes were core to the original proposal, yes. But that is irrelevant to the impossibility of examining tradeoffs when we have no idea what the attributes of centrally assigned ULAs will be. It is rash to use the assumption that there will be useful choices in the future to restrict choices today. | I never did. The *only* thing critical about centrally assigned | addresses is that that are uniquely assigned within the specified | address range. But uniquely assigned addresses are already available. They are expensive and they are not permanent. Do you really expect anyone to believe that you thought that the sole purpose of the centrally assigned ULA proposal was to create a new numerical range with no specific allocation attributes? Either you totally missed the point or else you are arguing so disingenuously that progress is impossible. |The rest is just nice to have. If the registries | charge too much then people will move to locally assigned ULA and | live with the limitations imposed by those addresses. That answer was acceptable before you proposed to impose such a severe restriction on locally assigned ULAs. |> |> |They don't get published in the GLOBAL DNS |> |> | because they are AMBIGIOUS. |> |> |> |> Merely repeating this assertion (even IN ALL CAPS) really isn't a useful |> |> argument. We have spent many months discussing ULAs as a solution to the |> |> ambiguity of site local addresses. This seems like a last minute attempt |> |> to cripple them. |> | |> | No. It is a attempt to prevent harm from incorrect use. |> |> Harm to whom? | | Harm to users of the DNS. Again, nobody forces you to use the DNS of a publisher of locally assigned ULAs. |RFC 1535 was written in response to | resolvers return address which connected to the wrong machines | when putting in fully qualified addresses. You are asking | the WG to endore a similar policy because you believe centrally | assigned addresses will never occur. No, I'm asking the WG to wait until centrally assigned addresses exist before effectively crippling locally assigned ULAs. But for the record I do not accept your premise that any small chance of ambiguity is euqally objectionable to an almost guaranteed ambiguity. |> |> |> An important feature of even locally assigned ULAs is that they are glo |> bal |> |> ly |> |> |> unique "enough" for many/most purposes that have been discussed. After |> mo |> |> nth |> |> |> s |> |> |> of analysis to that end, their lack of absolute uniqueness is insuffici |> ent |> |> to |> |> |> justify adding new prohibition on a particular range of uses at this la |> te |> |> dat |> |> |> e. |> |> | |> |> | They are unique enough to link serveral hundred / thousand sites |> |> | *with minimal renumbering required*. |> |> | |> |> | They are not unique enough to link millions of sites where the |> |> | is no way of knowing that renumbering is required. |> |> |> |> Even if you are correct that they are not unique enough to link millions |> |> of sites (and I do not accept that you are correct--duplicates could be |> |> handled by cooperating sites by a de facto uniqueness mechanism outside |> |> the scope of this proposal) how does this justify restricting the utility |> |> of locally assigned ULAs in the several hundred/thousand sites case? |> |> |> |> How about a compromise? Let's first insure that centrally assigned ULAs |> |> are available for permanent assignment with no recurring fees (and at most |> |> a nominal initial fee). Once that is accomplished we would be in a better |> |> position to weigh the costs/benefits of recommending locally assigned ULAs |> |> in various contexts. Such recommendations could be in a document separate |> |> from the core ULA document. Restricting the use of locally assigned ULAs |> |> before we even know whether there will be an alternative seems a bit rash. |> |> After all, this topic has been under discussion for a very long time; what |> 's |> |> the rush now? |> |> I see that you declined to reply to my suggested compromise. How about we |> make centrally assigned ULAs work before we break locally assigned ULAs? |> |> | It's not rash. They have limitations. |> |> You are confusing architectural limitations with administrative restrictions. |> The architectural limitation of locally assigned ULAs is that there is some |> chance of duplication. This implies that exposure of such addresses outside |> of the realm in which their uniqueness can be guaranteed may lead to ambiguit |> y. |> This is true regardless of the mechanism used to expose those addresses: glob |> al |> DNS, some other name lookup system, or even the passing of a literal address |> in some random protocol. |> |> Your proposal to prohibit locally assigned ULAs from the global DNS is an |> administrative restriction--one which considerably devalues the addresses |> in question. | | They were already devalued. It was inherent consequence of the | assignment technique. You must be the only one who thought that | publishing of locally assigned ULA in the global DNS was going to | occur. Actually, I never expected any kind of useful ULAs to exist at all. I expected pretty much the kind of two-pronged attack we are seeing. First turn the centrally assigned ULAs into rentals like the rest of the global space and then restrict the locally assigned ULAs to the point where they are unusable. |I know from the start as should have anyone who has | ever dealt with site locals / link local / RFC 1918 addresses that | there were never going to be published in the global DNS. They | were by ther very nature abmigious. | | The fact that I said MUST NOT should not have come as suprise to | anyone here. Well, it comes as no surprise to me because of my cynical assessment of the entire site local "replacement" plan. I would think it might come as a surprise to folks who believed that they might really get some useful stable address space out of this proposal. | Sure the addresses will leak from time to time. You don't however | deliberately *publish* them however. | |> |The fact that you |> | don't like the limitatitions does not mean that they should |> | not be acknowledged and dealt with appropriately. |> |> The limitations of locally assigned ULAs have been acknowledged and discussed |> extensively. Your proposal to create an administrative restriction does |> nothing to deal with the limitations; it merely forces the use of an as yet |> undefined alternative where locally assigned ULAs would have been sufficient. |> This is very reminiscent of the original site local debates. | | Site local was much worse. Here you choose which type of address to | use. No, you misunderstand. I was comparing the form of the debates, not the addresses. We were perpetually promised that once we got rid of site locals we could have something better, though as yet unspecified. Now we almost have locally assigned ULAs which--if not burdened with various administrative restrictions--might just be better. You propose to kill those for anyone not willing to use split DNS, and instead require centrally assigned ULAs which are conveniently stuck in limbo waiting for the existing registries to figure out how much they will cost. It's interesting that you waited until well after the central/local division (not to mention well after the original extended discussions) to start insisting on the addition of your DNS restriction. In any case, I will have to leave it to others to further this thread--if indeed anyone cares to do so. Please feel free to have the last word. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 4 07:51:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25670 for ; Sat, 4 Dec 2004 07:51:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaZU9-000873-M6 for ipv6-web-archive@ietf.org; Sat, 04 Dec 2004 07:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaZMd-0005bx-JL; Sat, 04 Dec 2004 07:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaZLL-0005Ff-3H for ipv6@megatron.ietf.org; Sat, 04 Dec 2004 07:48:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25534 for ; Sat, 4 Dec 2004 07:48:53 -0500 (EST) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaZRH-00083i-0T for ipv6@ietf.org; Sat, 04 Dec 2004 07:55:03 -0500 Received: from stephen (ip151.post-vineyard.dfw.ygnition.net [66.135.181.151]) by ns2.sea (8.13.1/8.12.5) with SMTP id iB4Cm6PR001796; Sat, 4 Dec 2004 04:48:11 -0800 Message-ID: <0b0e01c4d9ff$83325be0$6801a8c0@stephen> From: "Stephen Sprunk" To: "Dan Lanciani" , References: <200412040810.DAA20285@ss10.danlan.com> Date: Sat, 4 Dec 2004 06:29:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Thus spake "Dan Lanciani" > | If it in the global DNS is in NOT "your DNS". It is everybodies. > > What are you talking about? The data in my DNS resides in my servers or > in servers that I contract to hold it. You don't see it unless you query > those servers. > > | If you want to put it in your DNS then use split DNS. Stop > | polluting the commons. > > This is not a commons issue. Stop trying to assert jurisdiction over my > property. This has practical ramifications too; it's not possible to prevent people from putting ULAs in the global DNS since each controls their own zones. Anything we put in the i-d will be advisory in practice, so a SHOULD NOT is more appropriate than a MUST NOT even if we hypothetically agreed that it's a bad idea. I'll note that RFC 1918 says ambiguous addresses "should not" be seen outside their realm of validity. There is no reason to put a stronger restriction on ULAs, which have a significantly lower chance of actually being ambiguous in practice. > |> |The two types of ULA have > |> | different usage patterns. Pick the correct one for the job. > |> > |> When the proposal to create ULAs was "split" in order to accommodate a > longer > |> process for the centrally assigned flavor (because of the supposed need > for > |> comments from the existing address registries) the locally assigned > flavor > |> had the necessary attributes to support a wide variety of usage > patterns. > |> You propose to restrict the usage of the locally assigned flavor in > such a > |> way that many interesting applications will demand the centrally > assigned > |> flavor. I propose that if we really want to do that then we should > first > |> insure that the centrally assigned flavor comes into existence on > reasonable > |> terms. > > I see that you again declined to respond to my proposal that we first > insure > that the centrally assigned ULAs come into existence on reasonable terms. Locally-assigned ULAs should be significantly easier to get in place than centrally-assigned ULAs, and IMHO it is prudent for us to make sure the former will have no deficiencies compared to the latter other than the possibility of collisions. > |> This is a false choice. It is impossible to choose the set of > tradeoffs > |> because we have no idea what the attributes of centrally assigned ULAs > (if > |> they ever exist at all) will be. Basically, we copped out on mandating > the > |> critical attributes of centrally assigned ULAs (permanent assignment, > low > |> one-time fee) yet now you want to mandate restrictions on locally > assigned > |> ULAs that will force a requirement for the centrally assigned flavor. > | > | You believe permanent assignment, low one-time fee was manditory. > > In as much as those attributes were core to the original proposal, yes. > But > that is irrelevant to the impossibility of examining tradeoffs when we > have > no idea what the attributes of centrally assigned ULAs will be. It is > rash > to use the assumption that there will be useful choices in the future to > restrict choices today. Agreed. For now, we must treat locally-assigned ULAs as if they're all we're going to get. > |> | No. It is a attempt to prevent harm from incorrect use. > |> > |> Harm to whom? > | > | Harm to users of the DNS. > > Again, nobody forces you to use the DNS of a publisher of locally > assigned ULAs. Publishing an unreachable or possibly-ambiguous address in DNS hardly constitutes harm. > No, I'm asking the WG to wait until centrally assigned addresses exist > before > effectively crippling locally assigned ULAs. But for the record I do not > accept your premise that any small chance of ambiguity is euqally > objectionable > to an almost guaranteed ambiguity. Ditto. If the odds of collision are considered significant enough that we need to start treating ULAs as ambiguous, we need to revisit how many random bits there are or how they're generated. If we end up treating ULAs as if they're ambiguous, then we've made little or no progress versus site-locals. > |> Your proposal to prohibit locally assigned ULAs from the global DNS is > an > |> administrative restriction--one which considerably devalues the > addresses > |> in question. > | > | They were already devalued. It was inherent consequence of the > | assignment technique. You must be the only one who thought that > | publishing of locally assigned ULA in the global DNS was going to > | occur. > > Actually, I never expected any kind of useful ULAs to exist at all. I > expected pretty much the kind of two-pronged attack we are seeing. First > turn the centrally assigned ULAs into rentals like the rest of the global > space and then restrict the locally assigned ULAs to the point where they > are unusable. IIRC, I'm the one who originally suggested ULAs be allowed in the global DNS, and after a brief discussion it appeared to have consensus. I don't recall any of the current debate coming up back at that time. > |I know from the start as should have anyone who has > | ever dealt with site locals / link local / RFC 1918 addresses that > | there were never going to be published in the global DNS. They > | were by ther very nature abmigious. > | > | The fact that I said MUST NOT should not have come as suprise to > | anyone here. > > Well, it comes as no surprise to me because of my cynical assessment of > the > entire site local "replacement" plan. I would think it might come as a > surprise to folks who believed that they might really get some useful > stable > address space out of this proposal. MUST NOT certainly comes as a surprise to me. There was a very specific reason I proposed that ULAs be allowed in the global DNS even if I didn't want them to be _common_, and the current "not recommended" is sufficient. Maybe we should upgrade that to SHOULD NOT, but not to MUST NOT. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 4 19:00:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03482 for ; Sat, 4 Dec 2004 19:00:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CajvX-0003On-8X for ipv6-web-archive@ietf.org; Sat, 04 Dec 2004 19:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caj7l-0006wF-9q; Sat, 04 Dec 2004 18:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaifW-0001Xs-W2 for ipv6@megatron.ietf.org; Sat, 04 Dec 2004 17:46:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27373 for ; Sat, 4 Dec 2004 17:46:20 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CailY-0001wQ-TR for ipv6@ietf.org; Sat, 04 Dec 2004 17:52:37 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 41A92677F3 for ; Sat, 4 Dec 2004 22:45:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB4Mjd2V012359; Sun, 5 Dec 2004 09:45:40 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412042245.iB4Mjd2V012359@drugs.dv.isc.org> To: "Stephen Sprunk" From: Mark Andrews In-reply-to: Your message of "Sat, 04 Dec 2004 06:29:31 MDT." <0b0e01c4d9ff$83325be0$6801a8c0@stephen> Date: Sun, 05 Dec 2004 09:45:39 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d If ISC was to publish in the DNS www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists today www.isc.org. 10M IN AAAA FC01:4f8:0:2::d and you happened to have a machine with local addresses FC01:4f8:0:2::d. You would be unable to reach www.isc.org from any machine receiving your ULA prefix as a consequence of the address selection rules. This is the harm that can be caused when you publish a LA ULA. If you don't have MUST NOT you don't have a way to point blame when things go wrong. With MUST NOT you can say please remove the address you are in violation of RFC XXXX. 2001:4f8:0:2::d is assigned by forcing the LL address then using auto assignment to get the other prefixes. It is done this way so it won't change with hardware changes. I expect other sites will do similar things to provide stable addressing to their external machines. Collisions in addresses get much more probable when you start assigning the local parts by hand. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 5 00:53:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20081 for ; Sun, 5 Dec 2004 00:53:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CapQj-0001CR-4X for ipv6-web-archive@ietf.org; Sun, 05 Dec 2004 00:59:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caow4-0000LL-IC; Sun, 05 Dec 2004 00:27:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaoWF-00087J-Qg for ipv6@megatron.ietf.org; Sun, 05 Dec 2004 00:01:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17761 for ; Sun, 5 Dec 2004 00:01:08 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaocK-0000LW-Td for ipv6@ietf.org; Sun, 05 Dec 2004 00:07:29 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A077C6C3 for ; Sun, 5 Dec 2004 00:00:37 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 05 Dec 2004 00:00:37 -0500 Message-Id: <20041205050037.A077C6C3@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.31% | 13 | 21.28% | 73959 | mark_andrews@isc.org 11.48% | 7 | 9.37% | 32572 | brc@zurich.ibm.com 6.56% | 4 | 9.74% | 33848 | ipng-incoming@danlan.com 8.20% | 5 | 5.56% | 19339 | bob.hinden@nokia.com 3.28% | 2 | 10.45% | 36305 | brian@innovationslab.net 6.56% | 4 | 5.17% | 17969 | j.schoenwaelder@iu-bremen.de 4.92% | 3 | 5.06% | 17593 | internet-drafts@ietf.org 4.92% | 3 | 4.82% | 16766 | jinmei@isl.rdc.toshiba.co.jp 3.28% | 2 | 3.89% | 13511 | stephen@sprunk.org 3.28% | 2 | 3.59% | 12467 | tjc@ecs.soton.ac.uk 3.28% | 2 | 2.82% | 9815 | yukiyo.akisada@jp.yokogawa.com 3.28% | 2 | 2.02% | 7005 | fenner@research.att.com 1.64% | 1 | 2.58% | 8958 | rkrishnan.s@samsung.com 1.64% | 1 | 1.72% | 5987 | john.loughney@nokia.com 1.64% | 1 | 1.59% | 5522 | liqunhui@pub.xaonline.com 1.64% | 1 | 1.50% | 5204 | ericlklein@softhome.net 1.64% | 1 | 1.33% | 4607 | doc@tavian.com 1.64% | 1 | 1.24% | 4323 | jeanjour@comcast.net 1.64% | 1 | 1.13% | 3925 | erik.nordmark@sun.com 1.64% | 1 | 1.10% | 3834 | info@marikar.com 1.64% | 1 | 1.07% | 3703 | sra+ipng@hactrn.net 1.64% | 1 | 1.03% | 3584 | mailman-owner@ietf.org 1.64% | 1 | 0.98% | 3419 | msa@burp.tkv.asdf.org 1.64% | 1 | 0.96% | 3328 | onoe@sm.sony.co.jp --------+------+--------+----------+------------------------ 100.00% | 61 |100.00% | 347543 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 5 01:30:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22147 for ; Sun, 5 Dec 2004 01:30:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Caq0x-0001t1-Ne for ipv6-web-archive@ietf.org; Sun, 05 Dec 2004 01:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CapSe-0000oO-Fg; Sun, 05 Dec 2004 01:01:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cap3F-0002Fz-Qw for ipv6@megatron.ietf.org; Sun, 05 Dec 2004 00:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19195 for ; Sun, 5 Dec 2004 00:35:14 -0500 (EST) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cap9K-0000tb-K7 for ipv6@ietf.org; Sun, 05 Dec 2004 00:41:35 -0500 Received: from stephen (ip151.post-vineyard.dfw.ygnition.net [66.135.181.151]) by ns2.sea (8.13.1/8.12.5) with SMTP id iB55YWgr004840; Sat, 4 Dec 2004 21:34:33 -0800 Message-ID: <0fb201c4da8c$19da73c0$6801a8c0@stephen> From: "Stephen Sprunk" To: "Mark Andrews" References: <200412042245.iB4Mjd2V012359@drugs.dv.isc.org> Date: Sat, 4 Dec 2004 23:34:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Thus spake "Mark Andrews" > > If ISC was to publish in the DNS > > www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists today > www.isc.org. 10M IN AAAA FC01:4f8:0:2::d > > and you happened to have a machine with local addresses > FC01:4f8:0:2::d. > > You would be unable to reach www.isc.org from any machine > receiving your ULA prefix as a consequence of the address > selection rules. I can't ping that same host with "ping fc01:4f8:0:2::d" either; whether the hostname is in DNS or not doesn't materially reduce the impact of a LA ULA collision. > This is the harm that can be caused when you publish a > LA ULA. That is certainly a possible outcome if you happen to collide with someone, that someone happens to be mixing PI/PA and LA ULA addresses for a given hostname, and you happen to try to contact a host via that hostname. Care to calculate the odds that your scenario will happen? However, there do exist cases where the behavior is well-defined and correct even in the face of ambiguity. Suppose you have: www-dev.isc.org. 10M IN AAAA fc01:4f8:0:2::d ;no PI/PA addys which is (hypothetically) a development server only intended to be used by ISC's business partners, and ISC's LA ULA prefix is reachable over private links within the closed set of parties that need to use the dev server. ISC's business partners can reach the dev server at the above name with no changes to their local nameservers (if they even have control of such), removing an opportunity for human error to intrude. OTOH, anyone else trying to contact the dev server will either reach a different host (due to a collision) or nothing at all -- either is acceptable to ISC. The hostname and IP are intended to be useless to any party not privately connected, whether colliding or not, and a LA ULA is no worse as a public response than, say, an address assigned to a competitor: neither is valid data yet neither is a protocol or logic violation. > If you don't have MUST NOT you don't have a way to point > blame when things go wrong. With MUST NOT you can say > please remove the address you are in violation of RFC XXXX. from RFC 2119: "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." That sums up exactly how putting LA ULAs into the global DNS should be viewed: there exist circumstances when doing so is useful, but they require careful thought to prevemt unintended interactions. The LA ULA draft could certainly be enhanced with a list of what to consider and example scenarios where they do and don't work, but a MUST NOT isn't appropriate as long as there is _any_ legitimate use. Removing the LA ULA from DNS will not solve the ambiguity problem anyway, nor does it mask the interaction with address selection rules. The problem still exists at the IP layer, and any application that supports IPv6 address literals (i.e. nearly all of them) would see the exact same behavior if users were to type in an ambiguous ULA literal instead of a hostname that resolved to that ULA. Should we also ban users from distributing LA ULAs via smoke signals or avian carriers to keep from trying to use addresses where they're not valid? Finally, the verbage may give you something to point at when another admin does something you don't like, but that's the _only_ effect it will have. If he's going to ignore a MUST NOT in an RFC, what are the odds he'll make non-trivial changes to his configuration merely because _you_ had the misfortune to collide with his prefix? Of course, the only serious risk of collisions will be from intentional failure by both parties to follow the MUSTs in the draft... > 2001:4f8:0:2::d is assigned by forcing the LL address then > using auto assignment to get the other prefixes. It is > done this way so it won't change with hardware changes. > > I expect other sites will do similar things to provide stable > addressing to their external machines. Collisions in addresses > get much more probable when you start assigning the local parts > by hand. It reduces the collision space from 2^128 to 2^64, which is significant, but LA ULA prefixes are sufficiently unique that the rest of the address doesn't need to be. With 40 bits, we'll need over a million sites fully interconnected using LA ULAs before there's a 50/50 chance of prefix collision... Of course, since ULAs' scope is expected to be from one to a few thousand sites, making the odds of collision on the order of 2^-15 to 2^-40 for each ULA prefix. It is safe for us to act as if LA ULAs were unambiguous and let layer 8 detect and correct collisions if they ever occur. Now consider the odds of a human error at a registry that results in a duplicate assignment; since it's nonzero (provable, since it's happened to me) should we also start treating PI/PA space as ambiguous just in case? No, we act as if PI/PA space were unambiguous and let layer 8 detect and correct duplicates when they occur. Notice the symmetry there? In the end, the entire DNS paragraph is totally unenforceable thus the choice of SHOULD NOT or MUST NOT is not going to change a darn thing in real deployments. Consensus was achieved on this point long ago, and there is no indication that has changed or that it would make a meaningful difference even if it had. This effort would be better spent on other parts of this draft or on building support for CA ULAs and/or end-user PI space. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 5 02:16:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12975 for ; Sun, 5 Dec 2004 02:16:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Caqjg-0003GM-8i for ipv6-web-archive@ietf.org; Sun, 05 Dec 2004 02:23:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caq9b-0005pQ-QI; Sun, 05 Dec 2004 01:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caplm-0005Vd-H1 for ipv6@megatron.ietf.org; Sun, 05 Dec 2004 01:21:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21431 for ; Sun, 5 Dec 2004 01:21:17 -0500 (EST) Received: from widefw.sm.sony.co.jp ([133.138.0.3] helo=nebula.sm.sony.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Caprs-0001h3-0R for ipv6@ietf.org; Sun, 05 Dec 2004 01:27:36 -0500 Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.12.11/8.12.11) with ESMTP id iB56KE7h017511; Sun, 5 Dec 2004 15:20:14 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.12.11/8.12.8) id iB56KXqu003087; Sun, 5 Dec 2004 15:20:33 +0900 (JST) Date: Sun, 5 Dec 2004 15:20:33 +0900 (JST) From: Atsushi Onoe Message-Id: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> To: jinmei@isl.rdc.toshiba.co.jp In-Reply-To: Your message of "Sat, 04 Dec 2004 14:18:33 +0900" References: X-Mailer: Cue version 0.8 (041124-1839/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: fenner@research.att.com, duerst@w3.org, brc@zurich.ibm.com, bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > 2. how seriously we want (to allow) the use of scoped address syntax > in IRIs or URIs It should be noted that the scoped address format MUST NOT be sent on the wire. The address part of the URI must be parsed before sending to the proxy even when proxy server is configured. This means additional processing should be required for the implementation, regardless which delimiter is used. I think it was in justification of non-conforming URI specification, which is usually intended to be sent over the wire. Regards, Atsushi Onoe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 5 02:48:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15398 for ; Sun, 5 Dec 2004 02:48:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CarEe-0003tO-9B for ipv6-web-archive@ietf.org; Sun, 05 Dec 2004 02:55:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caqet-0003zI-Sl; Sun, 05 Dec 2004 02:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaqI1-0008Ha-N0 for ipv6@megatron.ietf.org; Sun, 05 Dec 2004 01:54:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27670 for ; Sun, 5 Dec 2004 01:54:36 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaqO7-0002ra-DO for ipv6@ietf.org; Sun, 05 Dec 2004 02:00:56 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C4705677F3 for ; Sun, 5 Dec 2004 06:54:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB56rpVs009177; Sun, 5 Dec 2004 17:53:51 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412050653.iB56rpVs009177@drugs.dv.isc.org> To: "Stephen Sprunk" From: Mark Andrews In-reply-to: Your message of "Sat, 04 Dec 2004 23:34:20 MDT." <0fb201c4da8c$19da73c0$6801a8c0@stephen> Date: Sun, 05 Dec 2004 17:53:51 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 > Thus spake "Mark Andrews" > > > > If ISC was to publish in the DNS > > > > www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists today > > www.isc.org. 10M IN AAAA FC01:4f8:0:2::d > > > > and you happened to have a machine with local addresses > > FC01:4f8:0:2::d. > > > > You would be unable to reach www.isc.org from any machine > > receiving your ULA prefix as a consequence of the address > > selection rules. > > I can't ping that same host with "ping fc01:4f8:0:2::d" either; whether the > hostname is in DNS or not doesn't materially reduce the impact of a LA ULA > collision. > > > This is the harm that can be caused when you publish a > > LA ULA. > > That is certainly a possible outcome if you happen to collide with someone, > that someone happens to be mixing PI/PA and LA ULA addresses for a given > hostname, and you happen to try to contact a host via that hostname. Care > to calculate the odds that your scenario will happen? > > However, there do exist cases where the behavior is well-defined and correct > even in the face of ambiguity. Suppose you have: > > www-dev.isc.org. 10M IN AAAA fc01:4f8:0:2::d ;no PI/PA addys > > which is (hypothetically) a development server only intended to be used by > ISC's business partners, and ISC's LA ULA prefix is reachable over private > links within the closed set of parties that need to use the dev server. > > ISC's business partners can reach the dev server at the above name with no > changes to their local nameservers (if they even have control of such), > removing an opportunity for human error to intrude. OTOH, anyone else > trying to contact the dev server will either reach a different host (due to > a collision) or nothing at all -- either is acceptable to ISC. The hostname > and IP are intended to be useless to any party not privately connected, > whether colliding or not, and a LA ULA is no worse as a public response > than, say, an address assigned to a competitor: neither is valid data yet > neither is a protocol or logic violation. If you want to be able to do this then get a CAULA. CAULA are designed for those who want to play on the global scale. Use the right tool for the right job. Stop trying to treat CLULAs as if they are identical to CAULAs. They aren't. > > If you don't have MUST NOT you don't have a way to point > > blame when things go wrong. With MUST NOT you can say > > please remove the address you are in violation of RFC XXXX. > > from RFC 2119: > "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label." This WG has much too little experience with DNS administators. You give them a inch with a SHOULD / SHOULD NOT and they take a mile. DNS/TCP is a SHOULD in RFC 103[45]. Care to hazard what one of the major probems is with the DNS? TCP being blocked at the firewall, one vendor doesn't support TCP by default. I don't know how many times I've heard "Oh DNS/TCP is a SHOULD we don't need to support it." even when the DNS lookups against their servers are failing because they have DNS/TCP blocked. This section really is targeting DNS administators. If they can make a wrong decision with a SHOULD / MAY they will. 10+ years of correcting mistakes like this has shown me that you don't leave doors like this open. This will become "It's only a SHOULD NOT it won't cause any harm". DNS administators regularly fail to keep the parent/child NS records in sync. They regularly only put glue in the parent zone. These are the basics. You want to hand them a SHOULD NOT. > That sums up exactly how putting LA ULAs into the global DNS should be > viewed: there exist circumstances when doing so is useful, but they require > careful thought to prevemt unintended interactions. The LA ULA draft could > certainly be enhanced with a list of what to consider and example scenarios > where they do and don't work, but a MUST NOT isn't appropriate as long as > there is _any_ legitimate use. CAULA in the global DNS will result in unreachable machines. LAULA in the global DNS will result in connections to wrong machines with subsequent exposure of everything transmitted over those connections. > Removing the LA ULA from DNS will not solve the ambiguity problem anyway, > nor does it mask the interaction with address selection rules. The problem > still exists at the IP layer, and any application that supports IPv6 address > literals (i.e. nearly all of them) would see the exact same behavior if > users were to type in an ambiguous ULA literal instead of a hostname that > resolved to that ULA. Should we also ban users from distributing LA ULAs > via smoke signals or avian carriers to keep from trying to use addresses > where they're not valid? I never said it would remove the problem. It will however prevent part of the set of problems caused by having ambigious addresses. Remember when a user types in a LAULA they know (can know) they have hace a LACULA. When a user types a domainname into a application they have no way of knowing that they have got back a LACLA. I know when a type 10.x.x.x that it is ambigious address. Users will learn that FC... is a ambigious address. I didn't say don't put them in the DNS. I said don't put them in the global DNS. > Finally, the verbage may give you something to point at when another admin > does something you don't like, but that's the _only_ effect it will have. > If he's going to ignore a MUST NOT in an RFC, what are the odds he'll make > non-trivial changes to his configuration merely because _you_ had the > misfortune to collide with his prefix? Of course, the only serious risk of > collisions will be from intentional failure by both parties to follow the > MUSTs in the draft... It's much easier to get change when it is clearly proscribed. > > 2001:4f8:0:2::d is assigned by forcing the LL address then > > using auto assignment to get the other prefixes. It is > > done this way so it won't change with hardware changes. > > > > I expect other sites will do similar things to provide stable > > addressing to their external machines. Collisions in addresses > > get much more probable when you start assigning the local parts > > by hand. > > It reduces the collision space from 2^128 to 2^64, which is significant, but > LA ULA prefixes are sufficiently unique that the rest of the address doesn't > need to be. With 40 bits, we'll need over a million sites fully > interconnected using LA ULAs before there's a 50/50 chance of prefix > collision... Of course, since ULAs' scope is expected to be from one to a > few thousand sites, making the odds of collision on the order of 2^-15 to > 2^-40 for each ULA prefix. It is safe for us to act as if LA ULAs were > unambiguous and let layer 8 detect and correct collisions if they ever > occur. We are talking aboult LAULA's assigned world wide. Not just the number of LAULA within a private routing domain. > Now consider the odds of a human error at a registry that results in a > duplicate assignment; since it's nonzero (provable, since it's happened to > me) should we also start treating PI/PA space as ambiguous just in case? > No, we act as if PI/PA space were unambiguous and let layer 8 detect and > correct duplicates when they occur. Notice the symmetry there? Putting LACLA into the DNS results in "broken by design". This is very different to "broken by error". > In the end, the entire DNS paragraph is totally unenforceable thus the > choice of SHOULD NOT or MUST NOT is not going to change a darn thing in real > deployments. Consensus was achieved on this point long ago, and there is no > indication that has changed or that it would make a meaningful difference > even if it had. This effort would be better spent on other parts of this > draft or on building support for CA ULAs and/or end-user PI space. Pointing out the limitations of LAULAs actually enhances the need for CAULAs. By attempting to treat them the same you actually are saying "we don't need CAULAs. LAULAs are `good enough' for everything we want to do." They clear are not good enough for every senario. Pointing out the differences make the case for both types stronger, not weaker. Letting people know up front the inherent limitations of each type is a good thing. I want CAULAs. I'd even be willing to pay a reasonable annual fee. If I can't get get a CAULA at a reasonable fee I will use a LAULA and live with the limitations that it brings. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 5 10:44:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16421 for ; Sun, 5 Dec 2004 10:44:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cayec-0001Kn-5r for ipv6-web-archive@ietf.org; Sun, 05 Dec 2004 10:50:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CayVK-0007Ms-9f; Sun, 05 Dec 2004 10:40:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CayTJ-0006zD-Ln; Sun, 05 Dec 2004 10:38:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15745; Sun, 5 Dec 2004 10:38:46 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CayZR-0001DZ-6c; Sun, 05 Dec 2004 10:45:12 -0500 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 215427; Sun, 05 Dec 2004 10:31:50 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 5 Dec 2004 10:35:25 -0500 To: Pekka Savola , iesg@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ipv6@ietf.org Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Hi Pekka, There is a new version of this document available at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-07.txt Could you check if it addresses your substantial concerns? Margaret At 12:15 AM +0200 11/13/04, Pekka Savola wrote: >On Sat, 30 Oct 2004, The IESG wrote: >> The IESG has received a request from the IP Version 6 Working Group WG to >> consider the following document: >> >> - 'Link Scoped IPv6 Multicast Addresses ' >> as a Proposed Standard >> >> 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-11-13. > >The document is in an awful shape. It clearly hasn't seen >sufficient review. I think thew applicability is very questionable >as well, but it seems some think this is sufficiently useful... > >semi-substantial >---------------- > >==> this doc should probably say "This memo updates RFC 3306." at the end, >because you're modifying the format specified there (an old MUST no longer >applies). > > flgs MUST be "0011". (The first two bits have been yet undefined, > sent as zero and ignored on receipt) flgs MUST use the same flag > defined in section 4 of [RFC 3306]. > >==> the sentence no longer holds true, due to embedded-RP. I'd suggest just >removing the sentence, because it doesn't seeem to be relevant to >the main thrust of the document. > > scop MUST be <= 2. It is preferred to use this method for the > link-local scope rather than unicast-prefix-based IPv6 multicast > addresses [RFC 3306]. > > >==> The sentence here is redundant. The users can use whichever they wish >and deem appropriate. > > LSM (Link Scoped Multicast) field MUST be "1111 1111" which maps to > the plen field in [RFC 3306], whereas the plen field in [RFC 3306] > MUST NOT be greater than 64. > > > That is, flgs, scop, and LSM fields are used to identify whether an > address is a multicast address as specified in this document. > > >==> this seems an inappropriately complex and confusing way to specify this, >renaming plen field to "LSM" and giving it static value of 255. Just >specify that plen = 255, you don't even have to have the extra >diagram and you're done! > > The lifetime of link scoped multicast addresses has no dependency > on the Valid Lifetime field in the Prefix Information option, > corresponding to the unicast address being used, contained in the > Router Advertisement message [RFC 2461]. > >==> does this need to be said? This is rather obvious. If you want to say >something, I'd rather say that there is no lifetime because link-local >addresses have no lifetime! > > >5. Considerations > > > Since multicast addresses are created from the unique IID, their > useful lifetime is linked to the period during which the IID is > known to be unique. Thus, it is possible to conflict between IIDs, > due to a new node joining the network that uses the same IID. The > document does not consider this case at this phase. It is another > challenging issue and out of scope of this document. > >==> this is a bit inaccurate, "due to a new node joining the network >that uses the same IID" -- this node would fail DAD and be unable to >use the link-local address to generate the link-scoped address! On >the other hand, the cases where DAD fails, this also fails -- like >the node with same MAC address as with someone on the link powered >on and only after that plugged on the link. > > The link scoped multicast address format supports source-specific > multicast addresses by the same method, as defined by [RFC 3306]. > >==> this is tehnically conflicting with the spec because plen is 255, and >not 0 as required by SSM. Just remove this. > >==> The title should be renamed in any case to something better than >"Considerations". > >6. Security Considerations > > > [RFC 3041] describes the privacy extension to IPv6 stateless > address autoconfiguration for an IID. The secure IID, generated by > [RFC 3041], can be used for consisting of a link scoped multicast > address since the uniqueness is verified by the DAD procedure as > part of the secure auto-configuration process. > >==> Here Be Dragons! This is technically wrong: RFC3041 addresses are >generated based on the received prefix information options, so there will >never be link-local scope RFC3041 addresses to generate the multicast >addresses from -- and even if there were, you'd have to consider their >lifetime here. > >==> Now that this bogus text is removed, Security Considerations section is >empty. I guess something needs to be written there. I guess you could say >that the uniqueness of the multicast addresses is guaranteed by the DAD >process. > > > >editorial >--------- > > of a node, an IID is uniquely determined. After then, each node > >==> "After then" should be replaced with something like "After that" or just >simply "Then". Fix in multiple places. > > conflicts. Basically, it is preferred to use this method for the > link-local scope rather than unicast-prefix-based IPv6 multicast > addresses [RFC 3306]. > >==> no references in the abstract, just remove '[RFC 3306]'. > >Also, nodes which are > supplied multicast services, easily consist of multicast addresses > of multicast servers using NDP (address resolution) and well-known > group IDs. > >==> "supplied" -> "supplying" ? Further, I'm having trouble understanding >what this sentence tries to mean.. > > Group ID is generated to indicate multicast application and is used > to guarantee its uniqueness only in the host. It may also be set > on the basis of the guidelines outlined in [RFC 3307]. > >==> remove "also". > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 5 15:05:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03909 for ; Sun, 5 Dec 2004 15:05:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb2jn-0006nF-PV for ipv6-web-archive@ietf.org; Sun, 05 Dec 2004 15:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb2Z2-0008Ks-Ct; Sun, 05 Dec 2004 15:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb2Sy-0005WW-FD for ipv6@megatron.ietf.org; Sun, 05 Dec 2004 14:54:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02988 for ; Sun, 5 Dec 2004 14:54:42 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb2ZA-0006a2-Jf for ipv6@ietf.org; Sun, 05 Dec 2004 15:01:09 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 2B55119736B for ; Sun, 5 Dec 2004 14:42:37 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB5Js9Z23118; Sun, 5 Dec 2004 11:54:09 -0800 (PST) Message-Id: <200412051954.iB5Js9Z23118@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ipv6@ietf.org References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> Date: Sun, 5 Dec 2004 11:54:07 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 I've added the following pieces to the draft to try to capture the conversation so far. [at the end of section 2.1:] o Use '%' in the URI Pro: + "%" is the same character. + Can copy and paste between forms. Con: + '%' is fundamentally special in URIs; parsers can be expected to be hard-wired to know that they start a percent-encoded octet. + IPvFuture ABNF doesn't permit bare percent. Issues: + Impossible to ensure that this exception to a fundamental URI rule would be handled properly by parsers. [new section:] 3. Limitations The usefulness of a URI or IRI using a literal scoped address is obviously limited to systems within the same scope. The addition of the zone identifier further limits the usefulness to the system on which the URI or IRI was generated, since zone IDs are completely local to a given host. Therefore, care must be taken to not pass these URIs between systems. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 5 20:00:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24831 for ; Sun, 5 Dec 2004 20:00:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb7LP-0003zK-An for ipv6-web-archive@ietf.org; Sun, 05 Dec 2004 20:07:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb74W-0007Xn-8e; Sun, 05 Dec 2004 19:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb6yn-0006nT-CC for ipv6@megatron.ietf.org; Sun, 05 Dec 2004 19:43:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23338 for ; Sun, 5 Dec 2004 19:43:50 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb753-0003aN-95 for ipv6@ietf.org; Sun, 05 Dec 2004 19:50:21 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 51579A7B03; Sun, 5 Dec 2004 19:43:20 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB60hJ926432; Sun, 5 Dec 2004 16:43:19 -0800 (PST) Message-Id: <200412060043.iB60hJ926432@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> <200412030018.iB30I6gM025024@nest.sm.sony.co.jp> <200412031732.iB3HWWT17511@windsor.research.att.com> Date: Sun, 5 Dec 2004 16:43:18 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >p.s. I've noticed the draft-ietf-ipv6-scoping-arch-02.txt has been in >the RFC editor queue for over 3 months. Is anyone know whether this >is a usual delay or the issues with the URI syntax is working as a >showstopper? The RFCs that have been published over the last couple of months have had average delays of just over 4 months. As far as I know, nobody has suggested delaying this document's publication as RFC. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 03:14:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10318 for ; Mon, 6 Dec 2004 03:14:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbE79-0003vV-JS for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 03:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbDqh-0005qW-Ie; Mon, 06 Dec 2004 03:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbDh1-0004ft-9S for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 02:53:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08963 for ; Mon, 6 Dec 2004 02:53:57 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbDnJ-0003Yj-H2 for ipv6@ietf.org; Mon, 06 Dec 2004 03:00:31 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 86F073608; Mon, 6 Dec 2004 08:53:25 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16149-08; Mon, 6 Dec 2004 08:53:24 +0100 (CET) Received: from james (Ia185.i.pppool.de [85.73.161.133]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5CF80360A; Mon, 6 Dec 2004 08:53:24 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CbDgQ-0000eN-EU; Mon, 06 Dec 2004 08:53:22 +0100 Date: Mon, 6 Dec 2004 08:53:22 +0100 From: Juergen Schoenwaelder To: Bill Fenner Message-ID: <20041206075322.GA2473@james> Mail-Followup-To: Bill Fenner , ipv6@ietf.org References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> <200412051954.iB5Js9Z23118@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412051954.iB5Js9Z23118@windsor.research.att.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Sun, Dec 05, 2004 at 11:54:07AM -0800, Bill Fenner wrote: > 3. Limitations > > The usefulness of a URI or IRI using a literal scoped address is > obviously limited to systems within the same scope. The addition of > the zone identifier further limits the usefulness to the system on > which the URI or IRI was generated, since zone IDs are completely > local to a given host. Therefore, care must be taken to not pass > these URIs between systems. This phrase "passing URIs between systems" never made me really happy. I believe there are valid reasons to pass even URIs with zone IDs. The point is I think that the interpretation of such URIs is only meaningful on a given system or set of systems which understand the semantics of the zone ID. Looking at the SNMP URI as an example: It might be totally OK to have a manager which understands the zones within a network and which sends a properly constructed URI including a zone ID to a box for consumption on that box. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 03:40:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13012 for ; Mon, 6 Dec 2004 03:40:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbEWg-0004ap-HC for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 03:47:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbEOM-0002pd-1x; Mon, 06 Dec 2004 03:38:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbEMg-0002Pb-Of for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 03:37:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12521 for ; Mon, 6 Dec 2004 03:37:01 -0500 (EST) Received: from parsley.amaranth.net ([216.44.4.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbESq-0004RR-QC for ipv6@ietf.org; Mon, 06 Dec 2004 03:43:35 -0500 Received: from ancho.senie.com (h0006b1049b35.ne.client2.attbi.com [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id iB68dDv6013917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Dec 2004 03:39:14 -0500 Message-Id: <6.2.0.14.2.20041206032446.07fcc3f0@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 06 Dec 2004 03:34:33 -0500 To: Mark Andrews , "Stephen Sprunk" From: Daniel Senie In-Reply-To: <200412042245.iB4Mjd2V012359@drugs.dv.isc.org> References: <200412042245.iB4Mjd2V012359@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiVirus: checked by Vexira Milter (version: 1.1; VAE: 6.28.0.18; VDF: 6.28.0.104; host: parsley.amaranth.net) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 At 05:45 PM 12/4/2004, Mark Andrews wrote: > If ISC was to publish in the DNS > > www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists > today > www.isc.org. 10M IN AAAA FC01:4f8:0:2::d > > and you happened to have a machine with local addresses > FC01:4f8:0:2::d. > > You would be unable to reach www.isc.org from any machine > receiving your ULA prefix as a consequence of the address > selection rules. Come on. This is NOT a real-world example. Today, I publish domains of the style example.com for production (public) use. I also publish NS records for zones of the style local.example.com for addresses on local (i.e. PRIVATE) networks that are not reachable from outside. Why do I do this? It simplifies getting around on private networks that allow servers to communicate for private matters (backups, for example). The servers are multihomed, with a public facing interface that is used for public things and a private-facing interface that's used for private things. There's no interference with public operations. If you try to ping a host on .local.amaranth.net, you may get unexpected results since there are many RFC1918 addresses there. Did this harm anything? No. Could I use views in BIND to block your being able to query there? Sure. People can and will publish zones for private use. Using a third level, such as local.example.com, is a GOOD way to do this. If you're concerned about people screwing up in the form you show above, then make a statement to that effect, rather than insisting on a MUST NOT that covers reasonable, and non-interfering usage such as folks have been using for years in IPv4. There's no Commons involved here. > This is the harm that can be caused when you publish a > LA ULA. > > If you don't have MUST NOT you don't have a way to point > blame when things go wrong. With MUST NOT you can say > please remove the address you are in violation of RFC XXXX. That's worked exceptionally well for folks leaking bogus-sourced packets (RFC 2827/BCP38). The IETF doesn't have a very good police force. If your goal is to enforce this by making DNS server products refuse to load zone data containing ULAs, I suspect that will fail as well, as the marketplace will insist such be allowed, and some vendor(s) will ignore claims to the contrary in the RFC. > 2001:4f8:0:2::d is assigned by forcing the LL address then > using auto assignment to get the other prefixes. It is > done this way so it won't change with hardware changes. > > I expect other sites will do similar things to provide stable > addressing to their external machines. Collisions in addresses > get much more probable when you start assigning the local parts > by hand. > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 04:30:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16826 for ; Mon, 6 Dec 2004 04:30:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbFIj-0005kZ-LU for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 04:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbFAX-0001iQ-11; Mon, 06 Dec 2004 04:28:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbF8Z-0001Im-6e for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 04:26:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16576 for ; Mon, 6 Dec 2004 04:26:29 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbFEt-0005ez-Dl for ipv6@ietf.org; Mon, 06 Dec 2004 04:33:03 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 46EE2677F3 for ; Mon, 6 Dec 2004 09:25:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB69PlKt055635; Mon, 6 Dec 2004 20:25:47 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412060925.iB69PlKt055635@drugs.dv.isc.org> To: Daniel Senie From: Mark Andrews In-reply-to: Your message of "Mon, 06 Dec 2004 03:34:33 CDT." <6.2.0.14.2.20041206032446.07fcc3f0@mail.amaranth.net> Date: Mon, 06 Dec 2004 20:25:46 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Stephen Sprunk , ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 > At 05:45 PM 12/4/2004, Mark Andrews wrote: > > > If ISC was to publish in the DNS > > > > www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists > > today > > www.isc.org. 10M IN AAAA FC01:4f8:0:2::d > > > > and you happened to have a machine with local addresses > > FC01:4f8:0:2::d. > > > > You would be unable to reach www.isc.org from any machine > > receiving your ULA prefix as a consequence of the address > > selection rules. > > Come on. This is NOT a real-world example. > > Today, I publish domains of the style example.com for production (public) > use. I also publish NS records for zones of the style local.example.com for > addresses on local (i.e. PRIVATE) networks that are not reachable from > outside. Why do I do this? It simplifies getting around on private networks > that allow servers to communicate for private matters (backups, for > example). The servers are multihomed, with a public facing interface that > is used for public things and a private-facing interface that's used for > private things. > > There's no interference with public operations. If you try to ping a host > on .local.amaranth.net, you may get unexpected results since there are many > RFC1918 addresses there. Did this harm anything? No. Could I use views in > BIND to block your being able to query there? Sure. It does no harm unless someone happens to attempt to use those names outside of your world. You have no knowledge of what is running on those addresses. Internal email address do leak. The safe response to a leaked internal address is to have it not connect to anything when used externally. Your decision causes harm when the address is actually running a SMTP server. Similar senarios happen with every other protocol. Because the addresses are ambigious you have no knowledge of what harm a name leak will cause. You think that is harmless. You can't know for sure what the impact of a name leak will cause. > People can and will publish zones for private use. Using a third level, > such as local.example.com, is a GOOD way to do this. > > If you're concerned about people screwing up in the form you show above, > then make a statement to that effect, rather than insisting on a MUST NOT > that covers reasonable, and non-interfering usage such as folks have been > using for years in IPv4. There's no Commons involved here. I say MUST NOT because you cannot, as the publisher, know the impact of publishing a ambigious address has on others. > > This is the harm that can be caused when you publish a > > LA ULA. > > > > If you don't have MUST NOT you don't have a way to point > > blame when things go wrong. With MUST NOT you can say > > please remove the address you are in violation of RFC XXXX. > > That's worked exceptionally well for folks leaking bogus-sourced packets > (RFC 2827/BCP38). The IETF doesn't have a very good police force. If your > goal is to enforce this by making DNS server products refuse to load zone > data containing ULAs, I suspect that will fail as well, as the marketplace > will insist such be allowed, and some vendor(s) will ignore claims to the > contrary in the RFC. Just because people don't do the right thing is not a reason to not tell them what the correct thing to do is. Mark > > 2001:4f8:0:2::d is assigned by forcing the LL address then > > using auto assignment to get the other prefixes. It is > > done this way so it won't change with hardware changes. > > > > I expect other sites will do similar things to provide stable > > addressing to their external machines. Collisions in addresses > > get much more probable when you start assigning the local parts > > by hand. > > > >-- > >Mark Andrews, ISC > >1 Seymour St., Dundas Valley, NSW 2117, Australia > >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 04:43:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17819 for ; Mon, 6 Dec 2004 04:43:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbFVb-00061K-D0 for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 04:50:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbFFO-0002OE-FQ; Mon, 06 Dec 2004 04:33:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbFEO-0002Ft-42 for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 04:32:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16962 for ; Mon, 6 Dec 2004 04:32:30 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbFKi-0005lm-D4 for ipv6@ietf.org; Mon, 06 Dec 2004 04:39:05 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iB69Vqug197814 for ; Mon, 6 Dec 2004 09:31:52 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB69Vkbq117234 for ; Mon, 6 Dec 2004 10:31:46 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB69Vp0K028133 for ; Mon, 6 Dec 2004 10:31:51 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB69VpaC028124; Mon, 6 Dec 2004 10:31:51 +0100 Received: from zurich.ibm.com (sig-9-145-249-221.de.ibm.com [9.145.249.221]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA76522; Mon, 6 Dec 2004 10:31:42 +0100 Message-ID: <41B426FF.6070709@zurich.ibm.com> Date: Mon, 06 Dec 2004 10:31:43 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Dan Lanciani References: <200412032014.PAA09501@ss10.danlan.com> In-Reply-To: <200412032014.PAA09501@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Dan Lanciani wrote: > Mark Andrews wrote: > > |+ Advertising locally assigned ULA AAAA records in the global DNS is > |+ MUST NOT occur as they are not globally unique and will lead > |+ to unexpected connections. > > I strongly object to making this a "MUST NOT," ... OK. Lot of shouting since this was sent but not much new text. How about Locally assigned ULA AAAA records MUST NOT appear in the global DNS, since there is an extremely small probability that the corresponding addresses are not unique. Even though these addresses will be unrouteable in the global Internet, their leakage via DNS is highly undesirable. Such AAAA records MAY appear in local regions of the DNS corresponding to their region of routeability. (And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 13:10:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06364 for ; Mon, 6 Dec 2004 13:10:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbNQW-0002qy-Ld for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 13:17:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbNBy-0004h4-IV; Mon, 06 Dec 2004 13:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbN6l-0003Dg-3n for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 12:57:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04695 for ; Mon, 6 Dec 2004 12:57:08 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbND9-0002Ul-54 for ipv6@ietf.org; Mon, 06 Dec 2004 13:03:48 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id C57421974A1; Mon, 6 Dec 2004 12:45:01 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB6HucV09082; Mon, 6 Dec 2004 09:56:38 -0800 (PST) Message-Id: <200412061756.iB6HucV09082@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: j.schoenwaelder@iu-bremen.de References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> <200412051954.iB5Js9Z23118@windsor.research.att.com> <20041206075322.GA2473@james> Date: Mon, 6 Dec 2004 09:56:37 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Good point. I replaced the last sentence with: Therefore, care must be taken to not pass these URIs blindly between systems. When both systems are aware of the relevant Zone IDs, e.g., an SNMP manager that is aware of the zone ID configuration of an agent, it is acceptable to pass these URIs between systems. Wordsmithing is welcome. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 13:38:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09653 for ; Mon, 6 Dec 2004 13:38:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbNr0-0003V0-Fj for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 13:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbNh9-0004Az-Cw; Mon, 06 Dec 2004 13:34:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbNaD-0002Kg-MS for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 13:27:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08018 for ; Mon, 6 Dec 2004 13:27:34 -0500 (EST) Received: from parsley.amaranth.net ([216.44.4.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbNgS-0003GN-Vj for ipv6@ietf.org; Mon, 06 Dec 2004 13:34:15 -0500 Received: from ancho.senie.com (h0006b1049b35.ne.client2.attbi.com [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id iB6IU02R031240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Dec 2004 13:30:01 -0500 Message-Id: <6.2.0.14.2.20041206131919.0868ef98@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 06 Dec 2004 13:27:13 -0500 To: Brian E Carpenter From: Daniel Senie In-Reply-To: <41B426FF.6070709@zurich.ibm.com> References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiVirus: checked by Vexira Milter (version: 1.1; VAE: 6.28.0.18; VDF: 6.28.0.106; host: parsley.amaranth.net) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f At 04:31 AM 12/6/2004, Brian E Carpenter wrote: >Dan Lanciani wrote: >>Mark Andrews wrote: >>|+ Advertising locally assigned ULA AAAA records in the global DNS is >>|+ MUST NOT occur as they are not globally unique and will lead >>|+ to unexpected connections. >>I strongly object to making this a "MUST NOT," ... > > >OK. Lot of shouting since this was sent but not much new text. > >How about > > Locally assigned ULA AAAA records MUST NOT appear in the global DNS, > since there is an extremely small probability that the corresponding > addresses are not unique. Even though these addresses will be > unrouteable in the global Internet, their leakage via DNS is highly > undesirable. Such AAAA records MAY appear in local regions of the DNS > corresponding to their region of routeability. > >(And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) I disagree. SHOULD NOT is sufficient, as it was (is) for RFC 1918. I also would remove the "highly" in "highly undesirable". The leak of such an address is not serious. Though such leakage has occurred occasionally with IPv4, the world has not ended. While I understand a strong desire to "get it right this time with IPv6," I don't see this particular issue as one where the result will be anything more than annoying prospective adopters of IPv6 with no good reason. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 14:30:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15501 for ; Mon, 6 Dec 2004 14:30:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbOfC-0005AK-PJ for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 14:36:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbOX3-0001LB-J1; Mon, 06 Dec 2004 14:28:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbOVI-0000t9-41; Mon, 06 Dec 2004 14:26:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15141; Mon, 6 Dec 2004 14:26:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbObi-00053H-0B; Mon, 06 Dec 2004 14:33:14 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CbOO8-0006qT-PG; Mon, 06 Dec 2004 14:19:12 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 06 Dec 2004 14:19:12 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'IP Tunnel MIB' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 The IESG has approved the following document: - 'IP Tunnel MIB ' as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks.  Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects.  This MIB does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIBs. Working Group Summary The IPv6 working group has reviewed this document and this document reflects the consensus of the group. Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list, the IPv6 working group chairs, and members of the ipv6mib mailing list. A MIB Doctor review was performed by Bert Wijnen. This document was reviewed for the IESG by Margaret Wasserman. RFC Editor Note Please make the following change: OLD: Note: instead of the name tunnelIfTOS, a better name would have been tunnelIfDSCPMethod, but the existing name appeared in RFC 2776 and existing objects cannot be renamed." NEW: Note: instead of the name tunnelIfTOS, a better name would have been tunnelIfDSCPMethod, but the existing name appeared in RFC 2667 and existing objects cannot be renamed." -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 14:43:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17037 for ; Mon, 6 Dec 2004 14:43:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbOs5-0005bd-7c for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 14:50:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbOX9-0001T3-EZ; Mon, 06 Dec 2004 14:28:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbOVg-0000wI-E5; Mon, 06 Dec 2004 14:27:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15246; Mon, 6 Dec 2004 14:26:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbOc6-00054Q-G7; Mon, 06 Dec 2004 14:33:38 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CbOPr-0007Oj-MJ; Mon, 06 Dec 2004 14:20:59 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 06 Dec 2004 14:20:59 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'Management Information Base for the User Datagram Protocol (UDP)' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 The IESG has approved the following document: - 'Management Information Base for the User Datagram Protocol (UDP) ' as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The publication of this document will move RFC 2454 'IP Version 6 Management Information Base for the User Datagram Protocol' to Historic status. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary   This memo defines a portion of the Management Information Base (MIB)   for use with network management protocols in the Internet community.   In particular, it describes managed objects used for implementations   of the User Datagram Protocol (UDP) in an IP version independent   manner.  This memo obsoletes RFCs 2013 and 2454. Working Group Summary The IPv6 working group has reviewed this document and this document reflects the consensus of the group. Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list, the IPv6 working group chairs, and members of the ipv6mib mailing list. A MIB doctor review was performed by Bert Wijnen, and a review was performed during IETF LC by Mike Heard. This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 15:19:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21437 for ; Mon, 6 Dec 2004 15:19:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbPQq-0006dd-Cb for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 15:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbPIb-00020e-Q3; Mon, 06 Dec 2004 15:17:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbPHx-0001VG-2Y for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 15:16:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21170 for ; Mon, 6 Dec 2004 15:16:51 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbPOL-0006ay-VW for ipv6@ietf.org; Mon, 06 Dec 2004 15:23:31 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2BC76371B; Mon, 6 Dec 2004 21:16:17 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27770-10; Mon, 6 Dec 2004 21:16:16 +0100 (CET) Received: from james (I81c1.i.pppool.de [85.73.129.193]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 547F63718; Mon, 6 Dec 2004 21:16:16 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CbPHK-0000fT-72; Mon, 06 Dec 2004 21:16:14 +0100 Date: Mon, 6 Dec 2004 21:16:14 +0100 From: Juergen Schoenwaelder To: Bill Fenner Message-ID: <20041206201614.GA2451@james> Mail-Followup-To: Bill Fenner , ipv6@ietf.org References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> <200412051954.iB5Js9Z23118@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412051954.iB5Js9Z23118@windsor.research.att.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 3.4 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On Sun, Dec 05, 2004 at 11:54:07AM -0800, Bill Fenner wrote: > > I've added the following pieces to the draft to try to capture the > conversation so far. > > [at the end of section 2.1:] > o Use '%' in the URI > Pro: > + "%" is the same character. > + Can copy and paste between forms. > Con: > + '%' is fundamentally special in URIs; parsers can be > expected to be hard-wired to know that they start a > percent-encoded octet. > + IPvFuture ABNF doesn't permit bare percent. > Issues: > + Impossible to ensure that this exception to a fundamental > URI rule would be handled properly by parsers. I think it is useful to explore how generic these real-world URI parsers really are. I just tried to use http://%3134.169.34.18/ and http://134.169.34.%31%38/ to access a web page, expecting that parsers would turn that into http://134.169.34.18/ but I got lots of "host not found" messages. So it indeed looks like the real-world parsers I have access to pass hostnames/IP addresses to name lookup functions without preparsing them. I also tried things such as without much luck. Please make your own tests. The conclusion from my little series of tests is clear. The implementations I have tried do not interpret % escape sequences in the host portion of URIs and so the direction should be to simply allow % for IPv6 addresses with a zone identifier and to tell URI folks that they better do not mandate that % escape encoding is applied to the host portion of URIs since this is a) not really useful and b) not widely implemented. Of course, if you find implementations that do interpret % escape sequences in the host portion of URIs, your conclusions might be different. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 15:26:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22228 for ; Mon, 6 Dec 2004 15:26:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbPY1-0006mZ-Jw for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 15:33:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbPNa-0005tg-Qz; Mon, 06 Dec 2004 15:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbPJJ-0002RK-E7 for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 15:18:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21329 for ; Mon, 6 Dec 2004 15:18:15 -0500 (EST) From: kck@netcom.com Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbPPj-0006co-Do for ipv6@ietf.org; Mon, 06 Dec 2004 15:24:55 -0500 Received: from [192.168.167.46] (helo=wamui08.slb.atl.earthlink.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CbPJH-0007mg-00 for ipv6@ietf.org; Mon, 06 Dec 2004 15:18:15 -0500 Message-ID: <10089952.1102364295245.JavaMail.root@wamui08.slb.atl.earthlink.net> Date: Mon, 6 Dec 2004 12:18:15 -0800 (GMT-08:00) To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kck@netcom.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit -----Original Message----- >> This is the harm that can be caused when you publish a >> LA ULA. > >That is certainly a possible outcome if you happen to collide with someone, >that someone happens to be mixing PI/PA and LA ULA addresses for a given >hostname, and you happen to try to contact a host via that hostname. Care >to calculate the odds that your scenario will happen? As someone who will end up supporting installations or have to debug problems related to connectivity, the actual odds are not important. If the odds are greater than 0, it will happen. Whatever solution that is proposed here should keep that in mind. Also, any solution should keep in mind how to work around any such problems when it does happen. If addresses are in global DNS, does that make my life horrible when trying to create scenarios where I need to avoid parts of the DNS? Not sure thats an issue here, but I think it needs to be considered. >However, there do exist cases where the behavior is well-defined and correct >even in the face of ambiguity. Suppose you have: The scenario you proposed can be done without using global DNS. I would almost argue that you would want to do it outside of the global DNS, since I do not need to advertise this part of my infrastructure to the world. >Removing the LA ULA from DNS will not solve the ambiguity problem anyway, >nor does it mask the interaction with address selection rules. The problem >still exists at the IP layer, and any application that supports IPv6 address >literals (i.e. nearly all of them) would see the exact same behavior if >users were to type in an ambiguous ULA literal instead of a hostname that >resolved to that ULA. Should we also ban users from distributing LA ULAs >via smoke signals or avian carriers to keep from trying to use addresses >where they're not valid? You are probably right here. But I think the standards should try and do what it can to protect unknowing entities from unwanted behaviour. As you stated later, you can't stop people from doing things, even with a MUST NOT in the document, but I do not think this is a good argument for NOT tightening up a document where the IETF feels certain behaviour should be restricted or isolated to local use only. After following this thread for a bit, my outside opinion is that we should keep the global DNS as clean as possible, and allow internal organizations do what they need to without unknowingly mess up an innocent bystander who will not have any idea of whats going on or how to fix/work around problems. --rich -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 6 21:41:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20836 for ; Mon, 6 Dec 2004 21:41:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbVOJ-0006Pt-AN for ipv6-web-archive@ietf.org; Mon, 06 Dec 2004 21:47:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbVCN-0006Tv-Ny; Mon, 06 Dec 2004 21:35:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbVBT-0006Li-6E for ipv6@megatron.ietf.org; Mon, 06 Dec 2004 21:34:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20603 for ; Mon, 6 Dec 2004 21:34:32 -0500 (EST) Received: from r-dd.iij4u.or.jp ([210.130.0.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbVHw-0006JJ-51 for ipv6@ietf.org; Mon, 06 Dec 2004 21:41:16 -0500 Received: from localhost (h248.p048.iij4u.or.jp [210.130.48.248]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id iB72YSV25895; Tue, 7 Dec 2004 11:34:29 +0900 (JST) Date: Tue, 07 Dec 2004 11:34:19 +0900 (JST) Message-Id: <20041207.113419.41627796.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: ipv6@ietf.org In-Reply-To: <20041206201614.GA2451@james> References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> <200412051954.iB5Js9Z23118@windsor.research.att.com> <20041206201614.GA2451@james> X-Mailer: Mew version 4.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit > I think it is useful to explore how generic these real-world URI > parsers really are. I just tried to use > > http://%3134.169.34.18/ and http://134.169.34.%31%38/ > > to access a web page, expecting that parsers would turn that into > > http://134.169.34.18/ > > but I got lots of "host not found" messages. My web browser behaves as the same for these examples. But it is terminated by inputing the following illegal notations. http://134.169.34.1%8/ http://134.169.34%.18/ http://134.169.3%4.18/ http://134.169.34.18%en0/ OTOH, it is not terminated by the following notations. http://[::1%4]/ http://[::1%en0]/ Hence, illegal '%' notation may not be safe for some implementation. But illegal '%' notation in [::] might be treated specially. Regards, Noritoshi Demizu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 04:28:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05569 for ; Tue, 7 Dec 2004 04:28:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbbl4-0006Cd-7j for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 04:35:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbbag-0003VS-Bi; Tue, 07 Dec 2004 04:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbbUC-0001xP-1Q for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 04:18:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04663 for ; Tue, 7 Dec 2004 04:18:18 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbbai-0005wV-T7 for ipv6@ietf.org; Tue, 07 Dec 2004 04:25:05 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB79GiVQ210688; Tue, 7 Dec 2004 09:16:51 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB79Grwq278164; Tue, 7 Dec 2004 09:16:53 GMT Received: from zurich.ibm.com (sig-9-145-250-55.de.ibm.com [9.145.250.55]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA28592; Tue, 7 Dec 2004 10:16:40 +0100 Message-ID: <41B574F9.6070605@zurich.ibm.com> Date: Tue, 07 Dec 2004 10:16:41 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Daniel Senie References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <6.2.0.14.2.20041206131919.0868ef98@mail.amaranth.net> In-Reply-To: <6.2.0.14.2.20041206131919.0868ef98@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Daniel Senie wrote: > At 04:31 AM 12/6/2004, Brian E Carpenter wrote: > >> Dan Lanciani wrote: >> >>> Mark Andrews wrote: >>> |+ Advertising locally assigned ULA AAAA records in the global DNS is >>> |+ MUST NOT occur as they are not globally unique and will lead >>> |+ to unexpected connections. >>> I strongly object to making this a "MUST NOT," ... >> >> >> >> OK. Lot of shouting since this was sent but not much new text. >> >> How about >> >> Locally assigned ULA AAAA records MUST NOT appear in the global DNS, >> since there is an extremely small probability that the corresponding >> addresses are not unique. Even though these addresses will be >> unrouteable in the global Internet, their leakage via DNS is highly >> undesirable. Such AAAA records MAY appear in local regions of the DNS >> corresponding to their region of routeability. >> >> (And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) > > > I disagree. SHOULD NOT is sufficient, as it was (is) for RFC 1918. I > also would remove the "highly" in "highly undesirable". The leak of such > an address is not serious. Though such leakage has occurred occasionally > with IPv4, the world has not ended. While I understand a strong desire > to "get it right this time with IPv6," I don't see this particular issue > as one where the result will be anything more than annoying prospective > adopters of IPv6 with no good reason. Personally, I could accept either MUST NOT or SHOULD NOT, and don't feel strongly about "highly." I hope the chairs can declare a consensus... Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 04:34:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06045 for ; Tue, 7 Dec 2004 04:34:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbbqe-0006Kg-UI for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 04:41:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbbe9-0004Me-7W; Tue, 07 Dec 2004 04:28:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbbaA-0003Pg-Vd for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 04:24:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05245 for ; Tue, 7 Dec 2004 04:24:29 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbbgh-00065S-SU for ipv6@ietf.org; Tue, 07 Dec 2004 04:31:16 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iB79NwvU225722 for ; Tue, 7 Dec 2004 09:23:58 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB79Nq6K119862 for ; Tue, 7 Dec 2004 10:23:52 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB79NwQa013131 for ; Tue, 7 Dec 2004 10:23:58 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB79Nw6W013116; Tue, 7 Dec 2004 10:23:58 +0100 Received: from zurich.ibm.com (sig-9-145-250-55.de.ibm.com [9.145.250.55]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA28504; Tue, 7 Dec 2004 10:23:56 +0100 Message-ID: <41B576AD.3020206@zurich.ibm.com> Date: Tue, 07 Dec 2004 10:23:57 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> <200412051954.iB5Js9Z23118@windsor.research.att.com> <20041206201614.GA2451@james> In-Reply-To: <20041206201614.GA2451@james> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit How interesting! www.%33com.com also fails, so it isn't even being kicked into numeric addresses that does it - the parsers simply don't interpret the escape at that point. So they're all broken? Brian Juergen Schoenwaelder wrote: > On Sun, Dec 05, 2004 at 11:54:07AM -0800, Bill Fenner wrote: > >>I've added the following pieces to the draft to try to capture the >>conversation so far. >> >>[at the end of section 2.1:] >> o Use '%' in the URI >> Pro: >> + "%" is the same character. >> + Can copy and paste between forms. >> Con: >> + '%' is fundamentally special in URIs; parsers can be >> expected to be hard-wired to know that they start a >> percent-encoded octet. >> + IPvFuture ABNF doesn't permit bare percent. >> Issues: >> + Impossible to ensure that this exception to a fundamental >> URI rule would be handled properly by parsers. > > > I think it is useful to explore how generic these real-world URI > parsers really are. I just tried to use > > http://%3134.169.34.18/ and http://134.169.34.%31%38/ > > to access a web page, expecting that parsers would turn that into > > http://134.169.34.18/ > > but I got lots of "host not found" messages. So it indeed looks like > the real-world parsers I have access to pass hostnames/IP addresses > to name lookup functions without preparsing them. I also tried things > such as without much luck. Please make > your own tests. > > The conclusion from my little series of tests is clear. The > implementations I have tried do not interpret % escape sequences > in the host portion of URIs and so the direction should be to > simply allow % for IPv6 addresses with a zone identifier and to > tell URI folks that they better do not mandate that % escape > encoding is applied to the host portion of URIs since this is > a) not really useful and b) not widely implemented. Of course, > if you find implementations that do interpret % escape sequences > in the host portion of URIs, your conclusions might be different. > > /js > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 04:48:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06659 for ; Tue, 7 Dec 2004 04:48:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbc3a-0006Y9-Ir for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 04:54:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbbq3-0001Sr-SL; Tue, 07 Dec 2004 04:40:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbbhn-0005bB-06 for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 04:32:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05840 for ; Tue, 7 Dec 2004 04:32:21 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbboJ-0006Fz-7b for ipv6@ietf.org; Tue, 07 Dec 2004 04:39:08 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 46B9F3720; Tue, 7 Dec 2004 10:31:49 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27762-01; Tue, 7 Dec 2004 10:31:48 +0100 (CET) Received: from james (I81f8.i.pppool.de [85.73.129.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8935D3729; Tue, 7 Dec 2004 10:31:48 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CbbhC-0001ND-Am; Tue, 07 Dec 2004 10:31:46 +0100 Date: Tue, 7 Dec 2004 10:31:46 +0100 From: Juergen Schoenwaelder To: Brian E Carpenter Message-ID: <20041207093146.GB5255@james> Mail-Followup-To: Brian E Carpenter , Bill Fenner , ipv6@ietf.org References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp> <200412051954.iB5Js9Z23118@windsor.research.att.com> <20041206201614.GA2451@james> <41B576AD.3020206@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B576AD.3020206@zurich.ibm.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 3.2 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Bill Fenner , ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Tue, Dec 07, 2004 at 10:23:57AM +0100, Brian E Carpenter wrote: > How interesting! www.%33com.com also fails, so it isn't even > being kicked into numeric addresses that does it - the parsers > simply don't interpret the escape at that point. > > So they're all broken? Either all these implementations are broken or the specification which requires % escape processing on the host portion of a URI (because it makes the URI grammer look nicer). It actually does not buy us anything to do % escape processing on the host name and with internationalized domain names, implementations might have even more reasons to treat the host portion of URIs in special ways. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 05:13:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08752 for ; Tue, 7 Dec 2004 05:13:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbcRj-00073O-Bh for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 05:19:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbcFy-0005OX-KB; Tue, 07 Dec 2004 05:07:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbc9l-0004WR-EJ for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 05:01:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07811 for ; Tue, 7 Dec 2004 05:01:14 -0500 (EST) Received: from widefw.sm.sony.co.jp ([133.138.0.3] helo=nebula.sm.sony.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbcGH-0006py-Gz for ipv6@ietf.org; Tue, 07 Dec 2004 05:08:03 -0500 Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.12.11/8.12.11) with ESMTP id iB7A0idv014571; Tue, 7 Dec 2004 19:00:44 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.12.11/8.12.8) id iB7A0hvB016826; Tue, 7 Dec 2004 19:00:43 +0900 (JST) Date: Tue, 7 Dec 2004 19:00:43 +0900 (JST) From: Atsushi Onoe Message-Id: <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> To: brc@zurich.ibm.com In-Reply-To: Your message of "Tue, 07 Dec 2004 10:23:57 +0100" <41B576AD.3020206@zurich.ibm.com> References: <41B576AD.3020206@zurich.ibm.com> X-Mailer: Cue version 0.8 (041124-1839/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: fenner@research.att.com, j.schoenwaelder@iu-bremen.de, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 > How interesting! www.%33com.com also fails, so it isn't even > being kicked into numeric addresses that does it - the parsers > simply don't interpret the escape at that point. > > So they're all broken? No. As BNF states in RFC 2396, escape by '%' is not allowed for hostport. So the implementation should not interpret '%33' as '3' when it appears in hostname or IP address, in any cases. Regards, Atsushi Onoe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 05:44:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11273 for ; Tue, 7 Dec 2004 05:44:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbcw1-0007mV-2h for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 05:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbciK-0003dJ-2e; Tue, 07 Dec 2004 05:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbcd1-0006En-W1 for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 05:31:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10043 for ; Tue, 7 Dec 2004 05:31:29 -0500 (EST) Received: from r-dd.iij4u.or.jp ([210.130.0.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbcjZ-0007S4-9E for ipv6@ietf.org; Tue, 07 Dec 2004 05:38:18 -0500 Received: from localhost (h248.p048.iij4u.or.jp [210.130.48.248]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id iB7AVQc01847; Tue, 7 Dec 2004 19:31:27 +0900 (JST) Date: Tue, 07 Dec 2004 19:31:16 +0900 (JST) Message-Id: <20041207.193116.85416733.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: ipv6@ietf.org In-Reply-To: <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> References: <41B576AD.3020206@zurich.ibm.com> <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> X-Mailer: Mew version 4.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit > No. As BNF states in RFC 2396, escape by '%' is not allowed for hostport. > So the implementation should not interpret '%33' as '3' when it appears > in hostname or IP address, in any cases. You might already know but allows %xx notation in host part. Regards, Noritoshi Demizu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 06:14:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13529 for ; Tue, 7 Dec 2004 06:14:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbdOm-0008Ng-JQ for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 06:20:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbdAA-0000iC-LC; Tue, 07 Dec 2004 06:05:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbcXh-0000lM-IQ for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 05:26:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09519 for ; Tue, 7 Dec 2004 05:25:59 -0500 (EST) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbceC-0007IA-7u for ipv6@ietf.org; Tue, 07 Dec 2004 05:32:47 -0500 Received: from [80.226.146.38] (helo=[172.30.11.226]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1CbcXK-000BWI-RM; Tue, 07 Dec 2004 10:25:39 +0000 In-Reply-To: <200412032336.iB3Nal62080800@drugs.dv.isc.org> References: <200412032336.iB3Nal62080800@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5543DA36-483A-11D9-89BF-000D9329F0D6@karoshi.com> Content-Transfer-Encoding: 7bit From: Bill Manning Date: Tue, 7 Dec 2004 11:25:35 +0100 To: Mark Andrews X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 07 Dec 2004 06:05:45 -0500 Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit > Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG. > If you need to publish them in the DNS you need to use a > split DNS configuration. This is no different to how we handle > RFS 1918 address. They don't get published in the GLOBAL DNS > because they are AMBIGIOUS. they do get published in the "global" DNS (whatever happened to the IABs single coherent namespace?) since I have seen things like: foo.bar. a 192.168.31.2 that said, regardless of IETF blustering, ULA or equivalents are routable address blocks - please provide an unambigious, statement of how any prefix is globally restricted to a limited scope for routing) - AND- keep your mits out of my zone files thank you very much. > You just cant filter them out of global respones especially once > DNSSEC is in use. > true... > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 06:15:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13683 for ; Tue, 7 Dec 2004 06:15:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbdQM-0008Q0-Fq for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 06:22:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbdAB-0000iJ-ID; Tue, 07 Dec 2004 06:05:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbcbM-0005vx-7o for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 05:29:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09928 for ; Tue, 7 Dec 2004 05:29:46 -0500 (EST) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbchu-0007QM-83 for ipv6@ietf.org; Tue, 07 Dec 2004 05:36:34 -0500 Received: from [80.226.146.38] (helo=[172.30.11.226]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1CbcbB-000C0S-Qt; Tue, 07 Dec 2004 10:29:38 +0000 In-Reply-To: <41B426FF.6070709@zurich.ibm.com> References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bill Manning Date: Tue, 7 Dec 2004 11:30:09 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 07 Dec 2004 06:05:45 -0500 Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit On Dec 6, 2004, at 10:31, Brian E Carpenter wrote: > Dan Lanciani wrote: >> Mark Andrews wrote: >> |+ Advertising locally assigned ULA AAAA records in the global DNS >> is >> |+ MUST NOT occur as they are not globally unique and will lead >> |+ to unexpected connections. >> I strongly object to making this a "MUST NOT," ... > > > OK. Lot of shouting since this was sent but not much new text. > > How about > > Locally assigned ULA AAAA records MUST NOT appear in the global > DNS, > since there is an extremely small probability that the > corresponding > addresses are not unique. Even though these addresses will be > unrouteable in the global Internet, their leakage via DNS is highly > undesirable. Such AAAA records MAY appear in local regions of the > DNS > corresponding to their region of routeability. keep your mitts off my zone files. and if the prefixes are routable -AT ALL- then i may chose to define my "local region" to be the Internet. > > (And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 07:56:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24265 for ; Tue, 7 Dec 2004 07:56:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbf0H-0002Kq-Oj for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 08:03:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbemx-00040E-P0; Tue, 07 Dec 2004 07:49:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbeeo-0003Gl-SR for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 07:41:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22906 for ; Tue, 7 Dec 2004 07:41:29 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbelM-0001r2-Rp for ipv6@ietf.org; Tue, 07 Dec 2004 07:48:18 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB7CefVQ204532; Tue, 7 Dec 2004 12:40:42 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB7Ceowq239520; Tue, 7 Dec 2004 12:40:50 GMT Received: from zurich.ibm.com (sig-9-145-250-55.de.ibm.com [9.145.250.55]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA99840; Tue, 7 Dec 2004 13:40:39 +0100 Message-ID: <41B5A4C7.7000409@zurich.ibm.com> Date: Tue, 07 Dec 2004 13:40:39 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Noritoshi Demizu References: <41B576AD.3020206@zurich.ibm.com> <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> <20041207.193116.85416733.Noritoshi@Demizu.ORG> In-Reply-To: <20041207.193116.85416733.Noritoshi@Demizu.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Noritoshi Demizu wrote: >>No. As BNF states in RFC 2396, escape by '%' is not allowed for hostport. >>So the implementation should not interpret '%33' as '3' when it appears >>in hostname or IP address, in any cases. > > > You might already know but > allows %xx notation in host part. > Really? Did the IESG know it was *changing* the syntax when it approved 2396bis? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 08:00:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24533 for ; Tue, 7 Dec 2004 08:00:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbf3Q-0002Q0-1F for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 08:06:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbeqz-0004dR-4H; Tue, 07 Dec 2004 07:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbeil-0003js-DR for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 07:45:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23274 for ; Tue, 7 Dec 2004 07:45:34 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbepF-0001wd-N8 for ipv6@ietf.org; Tue, 07 Dec 2004 07:52:22 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB7CibpN197116; Tue, 7 Dec 2004 12:44:37 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB7CiheE058488; Tue, 7 Dec 2004 12:44:44 GMT Received: from zurich.ibm.com (sig-9-145-250-55.de.ibm.com [9.145.250.55]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA98256; Tue, 7 Dec 2004 13:44:35 +0100 Message-ID: <41B5A5B3.9040501@zurich.ibm.com> Date: Tue, 07 Dec 2004 13:44:35 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bill Manning References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Bill Manning wrote: > > On Dec 6, 2004, at 10:31, Brian E Carpenter wrote: > >> Dan Lanciani wrote: >> >>> Mark Andrews wrote: >>> |+ Advertising locally assigned ULA AAAA records in the global DNS is >>> |+ MUST NOT occur as they are not globally unique and will lead >>> |+ to unexpected connections. >>> I strongly object to making this a "MUST NOT," ... >> >> >> >> OK. Lot of shouting since this was sent but not much new text. >> >> How about >> >> Locally assigned ULA AAAA records MUST NOT appear in the global DNS, >> since there is an extremely small probability that the corresponding >> addresses are not unique. Even though these addresses will be >> unrouteable in the global Internet, their leakage via DNS is highly >> undesirable. Such AAAA records MAY appear in local regions of the DNS >> corresponding to their region of routeability. > > > keep your mitts off my zone files. > and if the prefixes are routable -AT ALL- then i may chose to > define my "local region" to be the Internet. Bill, you could do that if the prefixes are *routed* but that is not going to be the case if the ULA spec is followed, except for private routing arrangements. Since the spec says they MUST NOT be globally routed, it seems entirely rational to apply the same rule to your zone files. But as I said before, I can live with SHOULD NOT. Brian > >> >> (And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 08:26:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27644 for ; Tue, 7 Dec 2004 08:26:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbfSq-0003IL-2c for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 08:33:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbfFi-0001wl-DW; Tue, 07 Dec 2004 08:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbfA7-0000Q2-86 for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 08:13:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26135 for ; Tue, 7 Dec 2004 08:13:50 -0500 (EST) Received: from r-dd.iij4u.or.jp ([210.130.0.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbfGf-0002qu-Bv for ipv6@ietf.org; Tue, 07 Dec 2004 08:20:38 -0500 Received: from localhost (124.117.138.210.xn.2iij.net [210.138.117.124]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id iB7DDRc23116; Tue, 7 Dec 2004 22:13:28 +0900 (JST) Date: Tue, 07 Dec 2004 22:13:21 +0900 (JST) Message-Id: <20041207.221321.104027179.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: Brian E Carpenter In-Reply-To: <41B5A4C7.7000409@zurich.ibm.com> References: <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> <20041207.193116.85416733.Noritoshi@Demizu.ORG> <41B5A4C7.7000409@zurich.ibm.com> X-Mailer: Mew version 4.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit > >>No. As BNF states in RFC 2396, escape by '%' is not allowed for hostport. > >>So the implementation should not interpret '%33' as '3' when it appears > >>in hostname or IP address, in any cases. > > > > You might already know but > > allows %xx notation in host part. > > Really? I believe so. The following ABNF is extracted from Appendix A of (Sep 2004). URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty authority = [ userinfo "@" ] host [ ":" port ] host = IP-literal / IPv4address / reg-name reg-name = *( unreserved / pct-encoded / sub-delims ) pct-encoded = "%" HEXDIG HEXDIG (Nov 2004) also allows %xx notation in host part. The following ABNF is extracted from section 2.2 of it. IRI = scheme ":" ihier-part [ "?" iquery ] ihier-part = "//" iauthority ipath-abempty / ipath-absolute / ipath-rootless / ipath-empty iauthority = [ iuserinfo "@" ] ihost [ ":" port ] ihost = IP-literal / IPv4address / ireg-name ireg-name = *( iunreserved / pct-encoded / sub-delims ) pct-encoded = "%" HEXDIG HEXDIG Regards, Noritoshi Demizu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 08:46:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29469 for ; Tue, 7 Dec 2004 08:46:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbfmb-0003nb-Qt for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 08:53:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbfe8-0006hI-F4; Tue, 07 Dec 2004 08:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbfZE-0005j3-L3 for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 08:39:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28731 for ; Tue, 7 Dec 2004 08:39:46 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbffn-0003cU-AN for ipv6@ietf.org; Tue, 07 Dec 2004 08:46:36 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 337D5371A; Tue, 7 Dec 2004 14:39:14 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10548-04; Tue, 7 Dec 2004 14:39:13 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 571D93718; Tue, 7 Dec 2004 14:39:13 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CbfYf-0000nh-Lg; Tue, 07 Dec 2004 14:39:13 +0100 Date: Tue, 7 Dec 2004 14:39:13 +0100 From: Juergen Schoenwaelder To: Noritoshi Demizu Message-ID: <20041207133913.GA3069@james> Mail-Followup-To: Noritoshi Demizu , ipv6@ietf.org References: <41B576AD.3020206@zurich.ibm.com> <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> <20041207.193116.85416733.Noritoshi@Demizu.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207.193116.85416733.Noritoshi@Demizu.ORG> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, Dec 07, 2004 at 07:31:16PM +0900, Noritoshi Demizu wrote: > > No. As BNF states in RFC 2396, escape by '%' is not allowed for hostport. > > So the implementation should not interpret '%33' as '3' when it appears > > in hostname or IP address, in any cases. > > You might already know but > allows %xx notation in host part. Does someone know the actual motivation for this change? Which problem were they trying to solve by allowing %xx notation in the host part? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 09:28:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04534 for ; Tue, 7 Dec 2004 09:28:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbgRG-0004vf-DO for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 09:35:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbgHW-0006JN-KK; Tue, 07 Dec 2004 09:25:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbfPw-00042e-VZ for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 08:30:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27961 for ; Tue, 7 Dec 2004 08:30:11 -0500 (EST) Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbfWV-0003NU-Ml for ipv6@ietf.org; Tue, 07 Dec 2004 08:37:00 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 849BE174EE2; Tue, 7 Dec 2004 08:29:40 -0500 (EST) To: ipv6@ietf.org Message-Id: <20041207132940.849BE174EE2@newdev.harvard.edu> Date: Tue, 7 Dec 2004 08:29:40 -0500 (EST) From: sob@harvard.edu (Scott Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Tue, 07 Dec 2004 09:25:32 -0500 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Brian sez: > Bill, you could do that if the prefixes are *routed* but that is > not going to be the case if the ULA spec is followed, except for > private routing arrangements. Since the spec says they MUST NOT > be globally routed, imo - much wishful thinking also imo - this whole idea is a clear and present danger to the Internet (assuming that IPv6 gets general deployment) Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 10:00:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10271 for ; Tue, 7 Dec 2004 10:00:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbgvz-0005q9-D4 for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 10:07:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbgl6-0004OV-6y; Tue, 07 Dec 2004 09:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbgg7-0003Fz-Im for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 09:50:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08933 for ; Tue, 7 Dec 2004 09:50:57 -0500 (EST) Received: from r-dd.iij4u.or.jp ([210.130.0.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbgmc-0005YE-Lg for ipv6@ietf.org; Tue, 07 Dec 2004 09:57:47 -0500 Received: from localhost (124.117.138.210.xn.2iij.net [210.138.117.124]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id iB7EonC07089; Tue, 7 Dec 2004 23:50:49 +0900 (JST) Date: Tue, 07 Dec 2004 23:50:43 +0900 (JST) Message-Id: <20041207.235043.112630247.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: ipv6@ietf.org In-Reply-To: <20041207.221321.104027179.Noritoshi@Demizu.ORG> References: <20041207.193116.85416733.Noritoshi@Demizu.ORG> <41B5A4C7.7000409@zurich.ibm.com> <20041207.221321.104027179.Noritoshi@Demizu.ORG> X-Mailer: Mew version 4.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit > > > You might already know but > > > allows %xx notation in host part. I should also mention that does not allow %xx notation in literal IPv6 address, as follows. IP-literal = "[" ( IPv6address / IPvFuture ) "]" IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) IPv6address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" ls32 = ( h16 ":" h16 ) / IPv4address h16 = 1*4HEXDIG Hence, a URI parser should not interpret %xx notation in IP-literal, if it follows . Regards, Noritoshi Demizu > From: Noritoshi Demizu > To: Brian E Carpenter > Cc: ipv6@ietf.org, Margaret Wasserman > Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt > Date: Tue, 07 Dec 2004 22:13:21 +0900 (JST) > > > >>No. As BNF states in RFC 2396, escape by '%' is not allowed for hostport. > > >>So the implementation should not interpret '%33' as '3' when it appears > > >>in hostname or IP address, in any cases. > > > > > > You might already know but > > > allows %xx notation in host part. > > > > Really? > > I believe so. The following ABNF is extracted from Appendix A of > (Sep 2004). > > URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] > hier-part = "//" authority path-abempty > / path-absolute > / path-rootless > / path-empty > authority = [ userinfo "@" ] host [ ":" port ] > host = IP-literal / IPv4address / reg-name > reg-name = *( unreserved / pct-encoded / sub-delims ) > pct-encoded = "%" HEXDIG HEXDIG > > (Nov 2004) also allows %xx notation in host > part. The following ABNF is extracted from section 2.2 of it. > > IRI = scheme ":" ihier-part [ "?" iquery ] > ihier-part = "//" iauthority ipath-abempty > / ipath-absolute > / ipath-rootless > / ipath-empty > iauthority = [ iuserinfo "@" ] ihost [ ":" port ] > ihost = IP-literal / IPv4address / ireg-name > ireg-name = *( iunreserved / pct-encoded / sub-delims ) > pct-encoded = "%" HEXDIG HEXDIG > > Regards, > Noritoshi Demizu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 10:40:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14723 for ; Tue, 7 Dec 2004 10:40:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbhYT-0006jK-OF for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 10:47:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbhMQ-0007lA-6U; Tue, 07 Dec 2004 10:34:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbh9t-0004ZU-PS for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 10:21:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12818 for ; Tue, 7 Dec 2004 10:21:43 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbhGT-0006L1-OF for ipv6@ietf.org; Tue, 07 Dec 2004 10:28:34 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB7FLD5M308518 for ; Tue, 7 Dec 2004 15:21:13 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB7FLMwq252836 for ; Tue, 7 Dec 2004 15:21:22 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iB7FLCA0028633 for ; Tue, 7 Dec 2004 15:21:12 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iB7FLCrZ028625; Tue, 7 Dec 2004 15:21:12 GMT Received: from zurich.ibm.com (sig-9-145-252-133.de.ibm.com [9.145.252.133]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA100084; Tue, 7 Dec 2004 16:21:11 +0100 Message-ID: <41B5CA67.5060306@zurich.ibm.com> Date: Tue, 07 Dec 2004 16:21:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Scott Bradner References: <20041207132940.849BE174EE2@newdev.harvard.edu> In-Reply-To: <20041207132940.849BE174EE2@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Scott Bradner wrote: > Brian sez: > >>Bill, you could do that if the prefixes are *routed* but that is >>not going to be the case if the ULA spec is followed, except for >>private routing arrangements. Since the spec says they MUST NOT >>be globally routed, > > > imo - much wishful thinking My point is simply that what we say about DNS should be compatible with what we say about routing. > > also imo - this whole idea is a clear and present danger to the Internet > (assuming that IPv6 gets general deployment) I disagree. The risk of these non-aggregatable prefixes appearing in the default-free BGP4 table in exchange for lots of money is the same as the risk of *any* longer prefix from PA space doing so. The danger exists as long as rich enterprises are willing to pay for routeability. There are other things we are doing (renumbering procedures, multi6, the NAP draft) to try and deflect this danger, but ULAs don't increase it. Brian > > Scott > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 10:59:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17012 for ; Tue, 7 Dec 2004 10:59:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbhr0-0007Hn-TJ for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 11:06:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbhTA-00011W-Kf; Tue, 07 Dec 2004 10:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbhE6-0005ks-6z for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 10:26:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13234 for ; Tue, 7 Dec 2004 10:26:04 -0500 (EST) Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbhKT-0006QG-HB for ipv6@ietf.org; Tue, 07 Dec 2004 10:32:42 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 28780175375; Tue, 7 Dec 2004 10:25:21 -0500 (EST) To: brc@zurich.ibm.com, sob@harvard.edu In-Reply-To: <41B5CA67.5060306@zurich.ibm.com> Message-Id: <20041207152521.28780175375@newdev.harvard.edu> Date: Tue, 7 Dec 2004 10:25:21 -0500 (EST) From: sob@harvard.edu (Scott Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Tue, 07 Dec 2004 10:41:38 -0500 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > My point is simply that what we say about DNS should be compatible with > what we say about routing. I agree with that > There are other things we are doing (renumbering procedures, multi6, the > NAP draft) to try and deflect this danger, but ULAs don't increase it. we disagree - I think they are an "attractive nuisance" (to use a pseudo-legal term) and we (the IETF) will rue the day that we approve this idea Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 11:43:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22138 for ; Tue, 7 Dec 2004 11:43:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbiXz-0008Ly-5w for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 11:50:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbiEz-0001Hg-Q0; Tue, 07 Dec 2004 11:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbi4o-0002PY-1E for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 11:20:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19526 for ; Tue, 7 Dec 2004 11:20:31 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbiBO-0007qU-2N for ipv6@ietf.org; Tue, 07 Dec 2004 11:27:23 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id D1A7AA7B00; Tue, 7 Dec 2004 11:20:01 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB7GK1A28539; Tue, 7 Dec 2004 08:20:01 -0800 (PST) Message-Id: <200412071620.iB7GK1A28539@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: onoe@sm.sony.co.jp References: <41B576AD.3020206@zurich.ibm.com> <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> Date: Tue, 7 Dec 2004 08:20:00 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: brc@zurich.ibm.com, ipv6@ietf.org, j.schoenwaelder@iu-bremen.de Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The Full Standard URI spec (draft-fielding-uri-rfc2396bis-07.txt) and the Proposed Standard IRI spec (draft-duerst-iri-11.txt) both specify percent-encoding in the host part, particularly for support of internationalization. It's a shame that the uri@w3.org list got dropped off of the cc list, since that's where all the experts on URI parsers etc. live. I'd like to request that those who would like to discuss using the raw '%' resend their message cc'ing both lists, so that discussion can include the relevant people. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 12:23:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26568 for ; Tue, 7 Dec 2004 12:23:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbjAK-0000ss-8p for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 12:30:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbir6-00057r-Gd; Tue, 07 Dec 2004 12:10:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbiXX-0007BS-OC for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 11:50:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22781 for ; Tue, 7 Dec 2004 11:50:13 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbie6-00005H-83 for ipv6@ietf.org; Tue, 07 Dec 2004 11:57:05 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 08EE6A7B06; Tue, 7 Dec 2004 11:49:42 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB7Gnfr29026; Tue, 7 Dec 2004 08:49:41 -0800 (PST) Message-Id: <200412071649.iB7Gnfr29026@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: brc@zurich.ibm.com References: <41B576AD.3020206@zurich.ibm.com> <200412071000.iB7A0hvB016826@nest.sm.sony.co.jp> <20041207.193116.85416733.Noritoshi@Demizu.ORG> <41B5A4C7.7000409@zurich.ibm.com> Date: Tue, 7 Dec 2004 08:49:41 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org, demizu@dd.iij4u.or.jp Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Percent encoding in the host part is an idn/i18n extension only; the grammar is more permissive than the text. The text restricts percent-escaping to UTF-8 encoding of non-ASCII names. This was part of a significant rewrite of the grammar from an ad-hoc BNF to ABNF; see appendix D of draft-fielding-uri-rfc2396bis. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 13:33:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03907 for ; Tue, 7 Dec 2004 13:33:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbkGC-0002dp-Gh for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 13:40:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbk0N-0005f3-JL; Tue, 07 Dec 2004 13:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbjnc-0003nB-5G for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 13:10:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01872 for ; Tue, 7 Dec 2004 13:10:53 -0500 (EST) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbju6-000288-CQ for ipv6@ietf.org; Tue, 07 Dec 2004 13:17:46 -0500 Received: from stephen (ip151.post-vineyard.dfw.ygnition.net [66.135.181.151]) by ns2.sea (8.13.1/8.12.5) with SMTP id iB7IADjP024415; Tue, 7 Dec 2004 10:10:13 -0800 Message-ID: <02a201c4dc87$ff922500$6801a8c0@stephen> From: "Stephen Sprunk" To: "Brian E Carpenter" , "Scott Bradner" References: <20041207132940.849BE174EE2@newdev.harvard.edu> <41B5CA67.5060306@zurich.ibm.com> Date: Tue, 7 Dec 2004 11:58:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Thus spake "Brian E Carpenter" > Scott Bradner wrote: >> Brian sez: >>>Bill, you could do that if the prefixes are *routed* but that is >>>not going to be the case if the ULA spec is followed, except for >>>private routing arrangements. Since the spec says they MUST NOT >>>be globally routed, >> >> imo - much wishful thinking > > My point is simply that what we say about DNS should be compatible with > what we say about routing. I think we must consider how little influence any RFC has on operational behavior, as opposed to the much greater influence they have on implementations. IMHO, the best we can say is ULAs SHOULD NOT be returned in DNS responses to hosts that cannot reach those addresses and then give some guidelines on how to do this correctly in practice. >> also imo - this whole idea is a clear and present danger to the Internet >> (assuming that IPv6 gets general deployment) > > I disagree. The risk of these non-aggregatable prefixes appearing > in the default-free BGP4 table in exchange for lots of money is the same > as the risk of *any* longer prefix from PA space doing so. The danger > exists as long as rich enterprises are willing to pay for routeability. > There are other things we are doing (renumbering procedures, multi6, the > NAP draft) to try and deflect this danger, but ULAs don't increase it. I'll note that ARIN is, at this very moment, debating whether to allow PI assignments directly to end sites; if that proposal is approved, they will pay only $100/yr for a prefix that any ISP can be reasonably expected to accept. The costs, in both time and effort, of getting every relevant ISP in the world to accept PA or ULA routes will be significantly higher. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 13:46:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05318 for ; Tue, 7 Dec 2004 13:46:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbkT7-0002wc-KC for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 13:53:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbkAx-0003H5-5a; Tue, 07 Dec 2004 13:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbk5w-0007Gc-HD for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 13:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03455 for ; Tue, 7 Dec 2004 13:29:49 -0500 (EST) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbkCY-0002Wb-FQ for ipv6@ietf.org; Tue, 07 Dec 2004 13:36:43 -0500 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel13.hp.com (Postfix) with ESMTP id 4AF8C1C177F2 for ; Tue, 7 Dec 2004 10:29:50 -0800 (PST) Received: from cacexc05.americas.cpqcorp.net ([16.92.1.29]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 10:29:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Dec 2004 10:29:29 -0800 Message-ID: <5A4CF82798D39A4AA3BC89B89720B519473613@cacexc05.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt Thread-Index: AcTcP2Pmljvd52UATUqA41UO96Qm2AAR5Jyw From: "Dalberg, Stevin J" To: X-OriginalArrivalTime: 07 Dec 2004 18:29:30.0446 (UTC) FILETIME=[B0E2AEE0:01C4DC8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable I believe SHOULD NOT is sufficient as well for CA ULA. I believe there may be ligitimate cases when having CA ULA's in global DNS exist. Company A has a VPN tunnel to Company B, and they route ULA addressing through this tunnel. By advertising this addressing in the global DNS for AAAA records, it enables this to get done without Company A and Company B doing zone transfers to each other, and having to push some zones and limit others, or use split DNS, etc... I admit, this is what they *SHOULD* be doing, but I have yet to see a large company that isn't lazy when it comes to DNS... For LA ULA's, I also agree that it SHOULD NOT is appropriate, since a central authority that doesn't have a recurring fee doesn't exist, and we should allow for that to be the case. Steve Dalberg Email: steve at sendithere dot com -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, December 07, 2004 1:17 AM To: Daniel Senie Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt Daniel Senie wrote: > At 04:31 AM 12/6/2004, Brian E Carpenter wrote: >=20 >> Dan Lanciani wrote: >> >>> Mark Andrews wrote: >>> |+ Advertising locally assigned ULA AAAA records in the global DNS is >>> |+ MUST NOT occur as they are not globally unique and will lead >>> |+ to unexpected connections. >>> I strongly object to making this a "MUST NOT," ... >> >> >> >> OK. Lot of shouting since this was sent but not much new text. >> >> How about >> >> Locally assigned ULA AAAA records MUST NOT appear in the global DNS, >> since there is an extremely small probability that the corresponding >> addresses are not unique. Even though these addresses will be >> unrouteable in the global Internet, their leakage via DNS is highly >> undesirable. Such AAAA records MAY appear in local regions of the DNS >> corresponding to their region of routeability. >> >> (And I would put an equivalent SHOULD NOT on centrally assigned=20 >> ULAs.) >=20 >=20 > I disagree. SHOULD NOT is sufficient, as it was (is) for RFC 1918. I=20 > also would remove the "highly" in "highly undesirable". The leak of=20 > such an address is not serious. Though such leakage has occurred=20 > occasionally with IPv4, the world has not ended. While I understand a=20 > strong desire to "get it right this time with IPv6," I don't see this=20 > particular issue as one where the result will be anything more than=20 > annoying prospective adopters of IPv6 with no good reason. Personally, I could accept either MUST NOT or SHOULD NOT, and don't feel strongly about "highly." I hope the chairs can declare a consensus... Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 16:38:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28485 for ; Tue, 7 Dec 2004 16:38:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbn8s-00005L-Ch for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 16:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbmUk-0007av-13; Tue, 07 Dec 2004 16:03:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbmQk-0005WJ-FW; Tue, 07 Dec 2004 15:59:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20161; Tue, 7 Dec 2004 15:59:28 -0500 (EST) Message-Id: <200412072059.PAA20161@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 07 Dec 2004 15:59:28 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, et al. Filename : draft-ietf-ipv6-link-scoped-mcast-08.txt Pages : 6 Date : 2004-12-7 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate their unique multicast addresses automatically without conflicts. Basically, this document proposes an alternative method for creating link-local multicast addresses over a known method like unicast-prefix-based IPv6 multicast addresses. It is preferred to use this method for link-local scope rather than unicast- prefix-based IPv6 multicast addresses. This memo update RFC3306. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-08.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-ipv6-link-scoped-mcast-08.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-ipv6-link-scoped-mcast-08.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-12-7154027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-7154027.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Dec 7 17:07:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04979 for ; Tue, 7 Dec 2004 17:07:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbnbO-000240-O9 for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 17:14:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnL5-0002u2-GG; Tue, 07 Dec 2004 16:57:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbmoO-0001hu-L8 for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 16:23:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23528 for ; Tue, 7 Dec 2004 16:23:54 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbmv2-0007ED-Ck for ipv6@ietf.org; Tue, 07 Dec 2004 16:30:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB7KsWl11562; Tue, 7 Dec 2004 12:54:32 -0800 X-mProtect: <200412072054> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdu6NXdQ; Tue, 07 Dec 2004 12:54:30 PST Message-Id: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 07 Dec 2004 13:23:08 -0800 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi, >OK. Lot of shouting since this was sent but not much new text. > >How about > > Locally assigned ULA AAAA records MUST NOT appear in the global DNS, > since there is an extremely small probability that the corresponding > addresses are not unique. Even though these addresses will be > unrouteable in the global Internet, their leakage via DNS is highly > undesirable. Such AAAA records MAY appear in local regions of the DNS > corresponding to their region of routeability. > >(And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) While I am sure everyone in this discussion has read the DNS text in the current draft, here it is just in case: 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document. For background on this recommendation, the concern about adding AAAA and PTR records to the global DNS for locally assigned local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same PTR record might be registered by two different organizations. Due to this concern, adding AAAA records is thought to be unwise because matching PTR records can not be registered. This text (in my view) is more or less equivalent to what is proposed above. The text in the draft doesn't use the upper case MUST/SHOULD language since this part of the document is operational guidelines and that language doesn't seem appropriate. I suppose something with lower case must/should would work. My personal view is that this is about all we can say now in this document. I continue to think that what is needed is a separate draft that discusses this topic in detail. This document might even relax the recommendation if warranted. It would be a good place to describe different approaches to the locally and centrally assigned ULAs as well. Chair hat on: The -08 draft is currently in the IESG. Almost all of the Discuss votes have been cleared. If we can go with the current text it may result in the document being approved soon. The more we try to fine tune it there is a risk of further delay. It would be good if we could move forward on this document. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 17:22:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06613 for ; Tue, 7 Dec 2004 17:22:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbnpQ-0002US-9s for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 17:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnQL-0006sx-H8; Tue, 07 Dec 2004 17:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnH2-0000sb-0W for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 16:53:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02797 for ; Tue, 7 Dec 2004 16:53:29 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbnNd-0001Li-TN for ipv6@ietf.org; Tue, 07 Dec 2004 17:00:24 -0500 Received: from pc6 (1Cust182.tnt1.lnd4.gbr.da.uu.net [62.188.130.182]) by ranger.systems.pipex.net (Postfix) with SMTP id F2A42E0000F9; Tue, 7 Dec 2004 21:52:54 +0000 (GMT) Message-ID: <003801c4dc9e$a8bfc4a0$0601a8c0@pc6> From: "Tom Petch" To: References: <200412050620.iB56KXqu003087@nest.sm.sony.co.jp><200412051954.iB5Js9Z23118@windsor.research.att.com> <20041206201614.GA2451@james> Date: Tue, 7 Dec 2004 21:49:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit I tried all the addresses Juergen gave and they all worked for me with Internet Explorer (6.0) - perhaps the world's commonest browser but perhaps not so common for those on the ipv6 list;-) Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Bill Fenner" Cc: Sent: Monday, December 06, 2004 9:16 PM Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt > > I think it is useful to explore how generic these real-world URI > parsers really are. I just tried to use > > http://%3134.169.34.18/ and http://134.169.34.%31%38/ both worked fine > > to access a web page, expecting that parsers would turn that into > > http://134.169.34.18/ worked fine > > but I got lots of "host not found" messages. So it indeed looks like > the real-world parsers I have access to pass hostnames/IP addresses > to name lookup functions without preparsing them. I also tried things > such as without much luck. Please make worked fine > your own tests. all works fine > > The conclusion from my little series of tests is clear. The > implementations I have tried do not interpret % escape sequences > in the host portion of URIs and so the direction should be to > simply allow % for IPv6 addresses with a zone identifier and to > tell URI folks that they better do not mandate that % escape > encoding is applied to the host portion of URIs since this is > a) not really useful and b) not widely implemented. Of course, > if you find implementations that do interpret % escape sequences > in the host portion of URIs, your conclusions might be different. > > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 17:40:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08346 for ; Tue, 7 Dec 2004 17:40:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbo79-0002zw-I1 for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 17:47:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnmW-0006T4-Hb; Tue, 07 Dec 2004 17:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbndE-0002va-1U for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 17:16:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05939 for ; Tue, 7 Dec 2004 17:16:25 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbnjq-0002L6-Uf for ipv6@ietf.org; Tue, 07 Dec 2004 17:23:20 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA06954; Tue, 7 Dec 2004 16:15:52 -0600 (CST) Received: from xch-nebh-01.ne.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iB7MFpQ12715; Tue, 7 Dec 2004 16:15:51 -0600 (CST) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Dec 2004 17:15:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Dec 2004 17:15:51 -0500 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt Thread-Index: AcTcqTgHiWYEptDGTWSGtSX+/ahD0wAAFXzw From: "Manfredi, Albert E" To: "Bob Hinden" , X-OriginalArrivalTime: 07 Dec 2004 22:15:51.0912 (UTC) FILETIME=[5011EE80:01C4DCAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable For what it's worth, having re-read the arguments pro and con, and the = wording used in RFC 1918 with respect to routing outside the private net = domain, I think that the -08 draft covers everything and word-smiths = everything quite nicely. Bert > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com] > Sent: Tuesday, December 07, 2004 4:23 PM > To: ipv6@ietf.org > Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt >=20 >=20 > Hi, >=20 > >OK. Lot of shouting since this was sent but not much new text. > > > >How about > > > > Locally assigned ULA AAAA records MUST NOT appear in=20 > the global DNS, > > since there is an extremely small probability that the=20 > corresponding > > addresses are not unique. Even though these addresses will be > > unrouteable in the global Internet, their leakage via=20 > DNS is highly > > undesirable. Such AAAA records MAY appear in local=20 > regions of the DNS > > corresponding to their region of routeability. > > > >(And I would put an equivalent SHOULD NOT on centrally=20 > assigned ULAs.) >=20 > While I am sure everyone in this discussion has read the DNS=20 > text in the=20 > current draft, here it is just in case: >=20 > 4.4 DNS Issues >=20 > At the present time AAAA and PTR records for locally=20 > assigned local > IPv6 addresses are not recommended to be installed in the=20 > global DNS. > The operational issues relating to this are beyond the=20 > scope of this > document. >=20 > For background on this recommendation, the concern about=20 > adding AAAA > and PTR records to the global DNS for locally assigned local IPv6 > addresses stems from the lack of complete assurance that=20 > the prefixes > are unique. There is a small possibility that the same PTR record > might be registered by two different organizations. Due to this > concern, adding AAAA records is thought to be unwise=20 > because matching > PTR records can not be registered. >=20 > This text (in my view) is more or less equivalent to what is proposed=20 > above. The text in the draft doesn't use the upper case MUST/SHOULD=20 > language since this part of the document is operational=20 > guidelines and that=20 > language doesn't seem appropriate. I suppose something with=20 > lower case=20 > must/should would work. >=20 > My personal view is that this is about all we can say now in this=20 > document. I continue to think that what is needed is a=20 > separate draft that=20 > discusses this topic in detail. This document might even relax the=20 > recommendation if warranted. It would be a good place to describe=20 > different approaches to the locally and centrally assigned=20 > ULAs as well. >=20 > Chair hat on: >=20 > The -08 draft is currently in the IESG. Almost all of the=20 > Discuss votes=20 > have been cleared. If we can go with the current text it may=20 > result in the=20 > document being approved soon. The more we try to fine tune=20 > it there is a=20 > risk of further delay. >=20 > It would be good if we could move forward on this document. >=20 > Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 17:45:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08900 for ; Tue, 7 Dec 2004 17:45:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CboBv-00039M-Ls for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 17:52:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnzV-0002YF-Qf; Tue, 07 Dec 2004 17:39:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnmL-0006CI-B5 for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 17:25:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07038 for ; Tue, 7 Dec 2004 17:25:50 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbnsy-0002ap-JA for ipv6@ietf.org; Tue, 07 Dec 2004 17:32:46 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 9127767503 for ; Tue, 7 Dec 2004 22:25:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB7MPFsO071015; Wed, 8 Dec 2004 09:25:16 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412072225.iB7MPFsO071015@drugs.dv.isc.org> To: Bob Hinden From: Mark Andrews In-reply-to: Your message of "Tue, 07 Dec 2004 13:23:08 -0800." <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> Date: Wed, 08 Dec 2004 09:25:15 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc > Hi, > > >OK. Lot of shouting since this was sent but not much new text. > > > >How about > > > > Locally assigned ULA AAAA records MUST NOT appear in the global DNS, > > since there is an extremely small probability that the corresponding > > addresses are not unique. Even though these addresses will be > > unrouteable in the global Internet, their leakage via DNS is highly > > undesirable. Such AAAA records MAY appear in local regions of the DNS > > corresponding to their region of routeability. > > > >(And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) > > While I am sure everyone in this discussion has read the DNS text in the > current draft, here it is just in case: > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local > IPv6 addresses are not recommended to be installed in the global DNS. > The operational issues relating to this are beyond the scope of this > document. > > For background on this recommendation, the concern about adding AAAA > and PTR records to the global DNS for locally assigned local IPv6 > addresses stems from the lack of complete assurance that the prefixes > are unique. There is a small possibility that the same PTR record > might be registered by two different organizations. Due to this > concern, adding AAAA records is thought to be unwise because matching > PTR records can not be registered. > > This text (in my view) is more or less equivalent to what is proposed > above. The text in the draft doesn't use the upper case MUST/SHOULD > language since this part of the document is operational guidelines and that > language doesn't seem appropriate. I suppose something with lower case > must/should would work. > > My personal view is that this is about all we can say now in this > document. I continue to think that what is needed is a separate draft that > discusses this topic in detail. This document might even relax the > recommendation if warranted. It would be a good place to describe > different approaches to the locally and centrally assigned ULAs as well. > > Chair hat on: > > The -08 draft is currently in the IESG. Almost all of the Discuss votes > have been cleared. If we can go with the current text it may result in the > document being approved soon. The more we try to fine tune it there is a > risk of further delay. > > It would be good if we could move forward on this document. > > Bob Which completely ignores the operational problems caused by leaking reverse lookups. We know these will exist and we need to take steps to prevent them. The only complaint I saw against my proposed text was the level of proscription against adding AAAA LAU LAs to the global DNS. Don't throw the baby out with the bath water. Mark > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 18:12:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12416 for ; Tue, 7 Dec 2004 18:12:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbobu-0003sG-2N for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 18:19:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CboHf-0007wZ-Ag; Tue, 07 Dec 2004 17:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbo8a-0004mO-Ln for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 17:48:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09272 for ; Tue, 7 Dec 2004 17:48:50 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CboFE-0003Du-5G for ipv6@ietf.org; Tue, 07 Dec 2004 17:55:45 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB7MJP311502; Tue, 7 Dec 2004 14:19:25 -0800 X-mProtect: <200412072219> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdkM6x7g; Tue, 07 Dec 2004 14:19:23 PST Message-Id: <6.1.2.0.2.20041207132358.06371200@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 07 Dec 2004 14:48:02 -0800 To: Scott Bradner From: Bob Hinden In-Reply-To: <20041207152521.28780175375@newdev.harvard.edu> References: <41B5CA67.5060306@zurich.ibm.com> <20041207152521.28780175375@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: brc@zurich.ibm.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Scott, > > There are other things we are doing (renumbering procedures, multi6, the > > NAP draft) to try and deflect this danger, but ULAs don't increase it. > >we disagree - I think they are an "attractive nuisance" (to use a >pseudo-legal term) and we (the IETF) will rue the day that we approve >this idea I don't agree. One reason I think this is not a significant concern is that the ULA prefixes are too long. /48's aren't big enough for large organizations. They will want a shorter prefix if they are going to go to the trouble of "convincing" their ISPs to route them for general usage (instead of using a PA prefix). Instead of getting their ISPs to route a /48 ULA prefix, I think it is much more likely that they will do what people do today. They will become a member of an RIR, and then become an LIR and get a PI prefix. This is fairly common as I understand it. If there is a need in the community for PI addresses that can be used by large organizations, then the RIRs should address that need directly and provide them. It's not that hard for organizations to become an LIR today, so the RIRs might as well make the rules clearer and allow organizations to get these assignments without having to become a member of the RIR. The underlying concern with this is, of course, the size of the default free routing tables and the stability of BGP. ULA's aren't going to make this worse (or better). Organizations that really need PI addresses will get them and then get ISPs to advertise them (as they do today). It doesn't matter if the entry in routing table is a RIR assigned prefix, a ULA prefix, or something else. It's still one entry in the routing table and routing updates. The problem is a real one and is not created by the IETF standardizing ULA addresses. Their intended usage if for local addresses (hence their name) and most people think they are an improvement over site-local addresses. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 18:12:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12541 for ; Tue, 7 Dec 2004 18:12:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbocU-0003tY-Ib for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 18:19:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CboHg-0007wp-Gn; Tue, 07 Dec 2004 17:58:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CboAJ-0005ja-4k for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 17:50:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09371 for ; Tue, 7 Dec 2004 17:50:36 -0500 (EST) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CboGx-0003Hf-Hw for ipv6@ietf.org; Tue, 07 Dec 2004 17:57:32 -0500 Received: from [208.48.59.10] (helo=[10.71.0.221]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1CboAD-0004sC-CU; Tue, 07 Dec 2004 22:50:33 +0000 In-Reply-To: <41B5A5B3.9040501@zurich.ibm.com> References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <41B5A5B3.9040501@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> Content-Transfer-Encoding: 7bit From: Bill Manning Date: Tue, 7 Dec 2004 17:51:08 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit On Dec 7, 2004, at 7:44, Brian E Carpenter wrote: > Bill Manning wrote: >> On Dec 6, 2004, at 10:31, Brian E Carpenter wrote: >>> Dan Lanciani wrote: >>> >>>> Mark Andrews wrote: >>>> |+ Advertising locally assigned ULA AAAA records in the global >>>> DNS is >>>> |+ MUST NOT occur as they are not globally unique and will lead >>>> |+ to unexpected connections. >>>> I strongly object to making this a "MUST NOT," ... >>> >>> >>> >>> OK. Lot of shouting since this was sent but not much new text. >>> >>> How about >>> >>> Locally assigned ULA AAAA records MUST NOT appear in the global >>> DNS, >>> since there is an extremely small probability that the >>> corresponding >>> addresses are not unique. Even though these addresses will be >>> unrouteable in the global Internet, their leakage via DNS is >>> highly >>> undesirable. Such AAAA records MAY appear in local regions of >>> the DNS >>> corresponding to their region of routeability. >> keep your mitts off my zone files. >> and if the prefixes are routable -AT ALL- then i may chose to >> define my "local region" to be the Internet. > > Bill, you could do that if the prefixes are *routed* but that is > not going to be the case if the ULA spec is followed, except for > private routing arrangements. Since the spec says they MUST NOT > be globally routed, it seems entirely rational to apply the same > rule to your zone files. But as I said before, I can live with > SHOULD NOT. > > Brian > please define "globally routable" in technical terms. and since routing is not the same as lookup, your assertion about the "rational" nature of registration in a lookup system does not hold much credence. >>> >>> (And I would put an equivalent SHOULD NOT on centrally assigned >>> ULAs.) >>> >>> Brian >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 18:14:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12919 for ; Tue, 7 Dec 2004 18:14:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CboeK-0003zW-8A for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 18:21:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CboIF-00087I-MM; Tue, 07 Dec 2004 17:58:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CboDv-0006Wx-2N for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 17:54:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09752 for ; Tue, 7 Dec 2004 17:54:20 -0500 (EST) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CboKZ-0003NH-Oo for ipv6@ietf.org; Tue, 07 Dec 2004 18:01:16 -0500 Received: from [208.48.59.10] (helo=[10.71.0.221]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1CboDs-0005Iz-DY; Tue, 07 Dec 2004 22:54:20 +0000 In-Reply-To: <02a201c4dc87$ff922500$6801a8c0@stephen> References: <20041207132940.849BE174EE2@newdev.harvard.edu> <41B5CA67.5060306@zurich.ibm.com> <02a201c4dc87$ff922500$6801a8c0@stephen> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0317DF40-48A3-11D9-89BF-000D9329F0D6@karoshi.com> Content-Transfer-Encoding: 7bit From: Bill Manning Date: Tue, 7 Dec 2004 17:54:55 -0500 To: "Stephen Sprunk" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Brian E Carpenter , ipv6@ietf.org, Scott Bradner Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Dec 7, 2004, at 12:58, Stephen Sprunk wrote: > Thus spake "Brian E Carpenter" >> Scott Bradner wrote: >>> Brian sez: >>>> Bill, you could do that if the prefixes are *routed* but that is >>>> not going to be the case if the ULA spec is followed, except for >>>> private routing arrangements. Since the spec says they MUST NOT >>>> be globally routed, >>> >>> imo - much wishful thinking >> >> My point is simply that what we say about DNS should be compatible >> with >> what we say about routing. > > I think we must consider how little influence any RFC has on > operational behavior, as opposed to the much greater influence they > have on implementations. > > IMHO, the best we can say is ULAs SHOULD NOT be returned in DNS > responses to hosts that cannot reach those addresses and then give > some guidelines on how to do this correctly in practice. and how are you going to determine the "reachability" between the two endpoints based on a name/address lookup? are you nuts? the DNS has zero idea of the topology between the node making the query and the node information the query is requesting. --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 18:50:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16178 for ; Tue, 7 Dec 2004 18:50:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbpCw-0004jO-AK for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 18:57:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbowm-0004zu-3F; Tue, 07 Dec 2004 18:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbocL-0005LP-2M for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 18:19:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13684 for ; Tue, 7 Dec 2004 18:19:34 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cboiz-000491-Kk for ipv6@ietf.org; Tue, 07 Dec 2004 18:26:30 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iB7NJZdt007191 for ; Tue, 7 Dec 2004 16:19:35 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8D00EQ5KSMFN@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 07 Dec 2004 16:19:35 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8D00JJOKSLI1@mail.sun.net> for ipv6@ietf.org; Tue, 07 Dec 2004 16:19:34 -0700 (MST) Date: Tue, 07 Dec 2004 15:19:31 -0800 From: Alain Durand To: John.Loughney@Nokia.com, "'IETF IPv6 Mailing List'" Message-id: <7339B2A8-48A6-11D9-B591-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT Subject: RFC2526 and node requirements document X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Hi, I couldn't find any mention of RFC2526 "Reserved IPv6 Subnet Anycast Addresses" in the node requirement document. Is it OK for an IPv6 node to ignore it? in practice, should/must an implementation have some code to: 1- prohibit such addresses to be configured on an interface 2- make sure that no ICMP messages are ever sent to such addresses? - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 18:59:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16803 for ; Tue, 7 Dec 2004 18:59:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbpLW-0004vw-3n for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 19:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cboxc-0005KG-C1; Tue, 07 Dec 2004 18:41:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbogB-00078K-0R for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 18:23:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14061 for ; Tue, 7 Dec 2004 18:23:32 -0500 (EST) Received: from parsley.amaranth.net ([216.44.4.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbomp-0004DW-SI for ipv6@ietf.org; Tue, 07 Dec 2004 18:30:28 -0500 Received: from ancho.senie.com (h0006b1049b35.ne.client2.attbi.com [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id iB7NPwHl019976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2004 18:26:01 -0500 Message-Id: <6.2.0.14.2.20041207181830.0933a4f8@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 07 Dec 2004 18:22:25 -0500 To: Bob Hinden , ipv6@ietf.org From: Daniel Senie In-Reply-To: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiVirus: checked by Vexira Milter (version: 1.1; VAE: 6.29.0.2; VDF: 6.29.0.4; host: parsley.amaranth.net) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 At 04:23 PM 12/7/2004, Bob Hinden wrote: >Hi, > >>OK. Lot of shouting since this was sent but not much new text. >> >>How about >> >> Locally assigned ULA AAAA records MUST NOT appear in the global DNS, >> since there is an extremely small probability that the corresponding >> addresses are not unique. Even though these addresses will be >> unrouteable in the global Internet, their leakage via DNS is highly >> undesirable. Such AAAA records MAY appear in local regions of the DNS >> corresponding to their region of routeability. >> >>(And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) > >While I am sure everyone in this discussion has read the DNS text in the >current draft, here it is just in case: > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local > IPv6 addresses are not recommended to be installed in the global DNS. > The operational issues relating to this are beyond the scope of this > document. > > For background on this recommendation, the concern about adding AAAA > and PTR records to the global DNS for locally assigned local IPv6 > addresses stems from the lack of complete assurance that the prefixes > are unique. There is a small possibility that the same PTR record > might be registered by two different organizations. Due to this > concern, adding AAAA records is thought to be unwise because matching > PTR records can not be registered. > >This text (in my view) is more or less equivalent to what is proposed >above. The text in the draft doesn't use the upper case MUST/SHOULD >language since this part of the document is operational guidelines and >that language doesn't seem appropriate. I suppose something with lower >case must/should would work. On re-reading the text in the present version of the draft, and reflecting on recent discussion, I support your assessment and agree that the language presently in the draft is sufficient. I see no reason to hold the document up. >My personal view is that this is about all we can say now in this >document. I continue to think that what is needed is a separate draft >that discusses this topic in detail. This document might even relax the >recommendation if warranted. It would be a good place to describe >different approaches to the locally and centrally assigned ULAs as well. > >Chair hat on: > >The -08 draft is currently in the IESG. Almost all of the Discuss votes >have been cleared. If we can go with the current text it may result in >the document being approved soon. The more we try to fine tune it there >is a risk of further delay. I strongly endorse this, especially in light of my comments above. Let's put this document to bed. >It would be good if we could move forward on this document. > >Bob > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 7 19:09:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18260 for ; Tue, 7 Dec 2004 19:09:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbpVZ-0005Bw-1Q for ipv6-web-archive@ietf.org; Tue, 07 Dec 2004 19:16:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbpLT-0004Db-2p; Tue, 07 Dec 2004 19:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbp2n-0006cQ-Tv for ipv6@megatron.ietf.org; Tue, 07 Dec 2004 18:46:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16032 for ; Tue, 7 Dec 2004 18:46:55 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbp9R-0004fh-Vh for ipv6@ietf.org; Tue, 07 Dec 2004 18:53:51 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iB7Nktdt026454 for ; Tue, 7 Dec 2004 16:46:55 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8D00EKCM27FN@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 07 Dec 2004 16:46:55 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8D00JOXM26I1@mail.sun.net> for ipv6@ietf.org; Tue, 07 Dec 2004 16:46:55 -0700 (MST) Date: Tue, 07 Dec 2004 15:46:52 -0800 From: Alain Durand In-reply-to: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> To: Bob Hinden Message-id: <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7BIT On Dec 7, 2004, at 1:23 PM, Bob Hinden wrote: > While I am sure everyone in this discussion has read the DNS text in > the current draft, here it is just in case: > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local > IPv6 addresses are not recommended to be installed in the global > DNS. > The operational issues relating to this are beyond the scope of this > document. > > For background on this recommendation, the concern about adding AAAA > and PTR records to the global DNS for locally assigned local IPv6 > addresses stems from the lack of complete assurance that the > prefixes > are unique. There is a small possibility that the same PTR record > might be registered by two different organizations. Due to this > concern, adding AAAA records is thought to be unwise because > matching > PTR records can not be registered. Bob, This is unfortunately not the only concern. Actually, i would even say this is a somehow minor issue, as the risk of collision is small. The real concern is similar to what is explain in the v6ops IPv6onbydefault draft. Say that a well know host publish 2 AAAA in the global DNS, a 'regular' one and a ULA one, apparently to make local things works better. What is going to happen is that remote hosts have statistically 50% chance to try the ULA first. Then, if TCP is in used, an application will have to wait up to 3 minutes (according to present TCP specs) before it can safely fall back to the 2nd address. Note that some implementations I know have lowered this timeout, but this is still a critical issue. In other words, the concern is not so much with publishing local addresses in a local branch of the DNS, but to publish both local and global data for the same name. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 04:29:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05724 for ; Wed, 8 Dec 2004 04:29:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbyF5-0000Mi-Ue for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 04:36:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbxzX-0005CY-Kj; Wed, 08 Dec 2004 04:20:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbxx2-0004oy-9B for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 04:17:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04927 for ; Wed, 8 Dec 2004 04:17:34 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cby3k-000094-6H for ipv6@ietf.org; Wed, 08 Dec 2004 04:24:34 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB89H25M178152; Wed, 8 Dec 2004 09:17:02 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB89HCPv281812; Wed, 8 Dec 2004 09:17:12 GMT Received: from zurich.ibm.com (sig-9-146-220-141.de.ibm.com [9.146.220.141]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA70024; Wed, 8 Dec 2004 10:17:01 +0100 Message-ID: <41B6C68E.4000008@zurich.ibm.com> Date: Wed, 08 Dec 2004 10:17:02 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bob Hinden References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> In-Reply-To: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit I agree with Bob about the current draft; I still believe it will be much better to discuss the DNS issues in depth in a separate (dnsops) document. My piece of text was intended in that context. Brian Bob Hinden wrote: > Hi, > >> OK. Lot of shouting since this was sent but not much new text. >> >> How about >> >> Locally assigned ULA AAAA records MUST NOT appear in the global DNS, >> since there is an extremely small probability that the corresponding >> addresses are not unique. Even though these addresses will be >> unrouteable in the global Internet, their leakage via DNS is highly >> undesirable. Such AAAA records MAY appear in local regions of the DNS >> corresponding to their region of routeability. >> >> (And I would put an equivalent SHOULD NOT on centrally assigned ULAs.) > > > While I am sure everyone in this discussion has read the DNS text in the > current draft, here it is just in case: > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local > IPv6 addresses are not recommended to be installed in the global DNS. > The operational issues relating to this are beyond the scope of this > document. > > For background on this recommendation, the concern about adding AAAA > and PTR records to the global DNS for locally assigned local IPv6 > addresses stems from the lack of complete assurance that the prefixes > are unique. There is a small possibility that the same PTR record > might be registered by two different organizations. Due to this > concern, adding AAAA records is thought to be unwise because matching > PTR records can not be registered. > > This text (in my view) is more or less equivalent to what is proposed > above. The text in the draft doesn't use the upper case MUST/SHOULD > language since this part of the document is operational guidelines and > that language doesn't seem appropriate. I suppose something with lower > case must/should would work. > > My personal view is that this is about all we can say now in this > document. I continue to think that what is needed is a separate draft > that discusses this topic in detail. This document might even relax the > recommendation if warranted. It would be a good place to describe > different approaches to the locally and centrally assigned ULAs as well. > > Chair hat on: > > The -08 draft is currently in the IESG. Almost all of the Discuss votes > have been cleared. If we can go with the current text it may result in > the document being approved soon. The more we try to fine tune it there > is a risk of further delay. > > It would be good if we could move forward on this document. > > Bob > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 04:38:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06380 for ; Wed, 8 Dec 2004 04:38:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbyOR-0000a1-DU for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 04:45:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbyBA-0007GD-Po; Wed, 08 Dec 2004 04:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cby5g-00060p-8h for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 04:26:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05380 for ; Wed, 8 Dec 2004 04:26:29 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbyCN-0000Hm-C7 for ipv6@ietf.org; Wed, 08 Dec 2004 04:33:29 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB89PtVQ263824; Wed, 8 Dec 2004 09:25:55 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB89Q1Pv229912; Wed, 8 Dec 2004 09:26:02 GMT Received: from zurich.ibm.com (sig-9-146-220-141.de.ibm.com [9.146.220.141]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA81678; Wed, 8 Dec 2004 10:25:49 +0100 Message-ID: <41B6C89F.8020802@zurich.ibm.com> Date: Wed, 08 Dec 2004 10:25:51 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Stephen Sprunk References: <20041207132940.849BE174EE2@newdev.harvard.edu> <41B5CA67.5060306@zurich.ibm.com> <02a201c4dc87$ff922500$6801a8c0@stephen> In-Reply-To: <02a201c4dc87$ff922500$6801a8c0@stephen> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Scott Bradner Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: ... >>> also imo - this whole idea is a clear and present danger to the Internet >>> (assuming that IPv6 gets general deployment) >> >> >> I disagree. The risk of these non-aggregatable prefixes appearing >> in the default-free BGP4 table in exchange for lots of money is the same >> as the risk of *any* longer prefix from PA space doing so. The danger >> exists as long as rich enterprises are willing to pay for routeability. >> There are other things we are doing (renumbering procedures, multi6, the >> NAP draft) to try and deflect this danger, but ULAs don't increase it. > > > I'll note that ARIN is, at this very moment, debating whether to allow > PI assignments directly to end sites; if that proposal is approved, they > will pay only $100/yr for a prefix that any ISP can be reasonably > expected to accept. The costs, in both time and effort, of getting > every relevant ISP in the world to accept PA or ULA routes will be > significantly higher. Not quite that simple. Firstly those "PI" prefxes would in fact be taken out of PA space, because that's all the registries have today. Secondly they would only be for people already allocated an AS number, and the registries estimate that about 10k prefixes would be the maximum in practice. However, you're correct that this would provide a much more attractive safety valve than inappropriate use of ULAs. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 04:45:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07083 for ; Wed, 8 Dec 2004 04:45:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbyUm-0000i4-9m for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 04:52:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbyBH-0007Ib-G2; Wed, 08 Dec 2004 04:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbyA2-0006wy-St for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 04:31:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05819 for ; Wed, 8 Dec 2004 04:31:00 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbyGl-0000Nw-U1 for ipv6@ietf.org; Wed, 08 Dec 2004 04:38:01 -0500 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iB89UTbP212226 for ; Wed, 8 Dec 2004 09:30:29 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB89Ugbb020006 for ; Wed, 8 Dec 2004 10:30:42 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB89UTV5025171 for ; Wed, 8 Dec 2004 10:30:29 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB89UTxw025152; Wed, 8 Dec 2004 10:30:29 +0100 Received: from zurich.ibm.com (sig-9-146-220-141.de.ibm.com [9.146.220.141]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA22586; Wed, 8 Dec 2004 10:30:28 +0100 Message-ID: <41B6C9B5.5070802@zurich.ibm.com> Date: Wed, 08 Dec 2004 10:30:29 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bill Manning References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <41B5A5B3.9040501@zurich.ibm.com> <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> In-Reply-To: <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Bill Manning wrote: > > On Dec 7, 2004, at 7:44, Brian E Carpenter wrote: > >> Bill Manning wrote: >> >>> On Dec 6, 2004, at 10:31, Brian E Carpenter wrote: >>> >>>> Dan Lanciani wrote: >>>> >>>>> Mark Andrews wrote: >>>>> |+ Advertising locally assigned ULA AAAA records in the global >>>>> DNS is >>>>> |+ MUST NOT occur as they are not globally unique and will lead >>>>> |+ to unexpected connections. >>>>> I strongly object to making this a "MUST NOT," ... >>>> >>>> >>>> >>>> >>>> OK. Lot of shouting since this was sent but not much new text. >>>> >>>> How about >>>> >>>> Locally assigned ULA AAAA records MUST NOT appear in the global >>>> DNS, >>>> since there is an extremely small probability that the >>>> corresponding >>>> addresses are not unique. Even though these addresses will be >>>> unrouteable in the global Internet, their leakage via DNS is highly >>>> undesirable. Such AAAA records MAY appear in local regions of >>>> the DNS >>>> corresponding to their region of routeability. >>> >>> keep your mitts off my zone files. >>> and if the prefixes are routable -AT ALL- then i may chose to >>> define my "local region" to be the Internet. >> >> >> Bill, you could do that if the prefixes are *routed* but that is >> not going to be the case if the ULA spec is followed, except for >> private routing arrangements. Since the spec says they MUST NOT >> be globally routed, it seems entirely rational to apply the same >> rule to your zone files. But as I said before, I can live with >> SHOULD NOT. >> >> Brian >> > please define "globally routable" in technical terms. Why? I didn't use that phrase. The draft doesn't say that, it says that ULA prefixes must not be globally routed. Different. > and since routing is not the same as lookup, your assertion > about the "rational" nature of registration in a lookup system > does not hold much credence. Not at all. As others have pointed out, if DNS returns AAA records for prefixes that are not in fact routed, TCP timeouts will result. That's sufficient reason to not put such records in your zone files. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 05:26:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10151 for ; Wed, 8 Dec 2004 05:26:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbz8U-0001XD-6K for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 05:33:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbyyN-0001OI-N2; Wed, 08 Dec 2004 05:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbywV-00015U-Bs for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 05:21:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09854 for ; Wed, 8 Dec 2004 05:21:02 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbz3C-0001Rh-VN for ipv6@ietf.org; Wed, 08 Dec 2004 05:28:03 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id iB8AKmwP019744; Wed, 8 Dec 2004 10:20:48 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id iB8AKmPT019741; Wed, 8 Dec 2004 10:20:48 GMT Date: Wed, 8 Dec 2004 10:20:48 +0000 From: bmanning@vacation.karoshi.com To: Brian E Carpenter Message-ID: <20041208102048.GC19470@vacation.karoshi.com.> References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <41B5A5B3.9040501@zurich.ibm.com> <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> <41B6C9B5.5070802@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B6C9B5.5070802@zurich.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ipv6@ietf.org, Bill Manning , Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c > >>Bill, you could do that if the prefixes are *routed* but that is > >>not going to be the case if the ULA spec is followed, except for > >>private routing arrangements. Since the spec says they MUST NOT > >>be globally routed, it seems entirely rational to apply the same > >>rule to your zone files. But as I said before, I can live with > >>SHOULD NOT. > >> > >> Brian > >> > > please define "globally routable" in technical terms. > > Why? I didn't use that phrase. The draft doesn't say that, it says > that ULA prefixes must not be globally routed. Different. i guess that i am confused here. what does it mean to be "globally routed"? and how is that different than "globally routable"? > > and since routing is not the same as lookup, your assertion > > about the "rational" nature of registration in a lookup system > > does not hold much credence. > > Not at all. As others have pointed out, if DNS returns AAA records > for prefixes that are not in fact routed, TCP timeouts will result. > That's sufficient reason to not put such records in your zone files. so your DNS server in Zurich is expected to have knowledge about the state of the routing system between ISPs in Argentina? This problem is functionally identical to the original route server concept that was used in the NSF NAPs. ISP A could talk to the RS and ISP B could talk to the RS, but they could not talk to each other ... From the RS point of view, it had no knowledge of the policy filters that prevented these two ISPs from exchanging traffic. DNS is a lookup system. It has zero idea about the currnet state of reachability/routedness ... telling me i should not place records in my DNS that are useful to me, just because they are not useful to you is presumptious at best. when/if the DNS carries explicit routing information, then i'll be willing to buy into your argument... not until then though. > > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 05:39:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11021 for ; Wed, 8 Dec 2004 05:39:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbzLO-0001mK-Rb for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 05:46:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbzCv-000491-RJ; Wed, 08 Dec 2004 05:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbz92-0002zh-Cm for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 05:34:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10468 for ; Wed, 8 Dec 2004 05:34:02 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbzFm-0001eZ-TL for ipv6@ietf.org; Wed, 08 Dec 2004 05:41:03 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB8AXVSZ210248 for ; Wed, 8 Dec 2004 10:33:31 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB8AXePv202390 for ; Wed, 8 Dec 2004 10:33:41 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iB8AXT2P024238 for ; Wed, 8 Dec 2004 10:33:29 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iB8AXSxv024221; Wed, 8 Dec 2004 10:33:29 GMT Received: from zurich.ibm.com (sig-9-145-132-59.de.ibm.com [9.145.132.59]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA91850; Wed, 8 Dec 2004 11:33:27 +0100 Message-ID: <41B6D878.2050603@zurich.ibm.com> Date: Wed, 08 Dec 2004 11:33:28 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: bmanning@vacation.karoshi.com References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <41B5A5B3.9040501@zurich.ibm.com> <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> <41B6C9B5.5070802@zurich.ibm.com> <20041208102048.GC19470@vacation.karoshi.com.> In-Reply-To: <20041208102048.GC19470@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Bill Manning , Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: >>>>Bill, you could do that if the prefixes are *routed* but that is >>>>not going to be the case if the ULA spec is followed, except for >>>>private routing arrangements. Since the spec says they MUST NOT >>>>be globally routed, it seems entirely rational to apply the same >>>>rule to your zone files. But as I said before, I can live with >>>>SHOULD NOT. >>>> >>>> Brian >>>> >>> >>> please define "globally routable" in technical terms. >> >>Why? I didn't use that phrase. The draft doesn't say that, it says >>that ULA prefixes must not be globally routed. Different. > > > i guess that i am confused here. what does it mean to be "globally routed"? Advertised in BGP4+ between all or most ISPs. > and how is that different than "globally routable"? I didn't attempt to define that since it is indeed a woolly phrase. Any prefix *could* be globally routed; the interesting question is whether it *is* globally routed. >>> and since routing is not the same as lookup, your assertion >>> about the "rational" nature of registration in a lookup system >>> does not hold much credence. >> >>Not at all. As others have pointed out, if DNS returns AAA records >>for prefixes that are not in fact routed, TCP timeouts will result. >>That's sufficient reason to not put such records in your zone files. > > > so your DNS server in Zurich is expected to have knowledge > about the state of the routing system between ISPs in Argentina? > This problem is functionally identical to the original route server > concept that was used in the NSF NAPs. ISP A could talk to the > RS and ISP B could talk to the RS, but they could not talk to each > other ... From the RS point of view, it had no knowledge of the > policy filters that prevented these two ISPs from exchanging traffic. > > DNS is a lookup system. It has zero idea about the currnet state > of reachability/routedness ... telling me i should not place records > in my DNS that are useful to me, just because they are not useful to > you is presumptious at best. > > when/if the DNS carries explicit routing information, then i'll be > willing to buy into your argument... not until then though. Perhaps you don't like the reality that most enterprises operate 2-faced DNS, but they do. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 07:47:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19030 for ; Wed, 8 Dec 2004 07:47:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc1Kr-00046Q-Jd for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 07:54:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc17F-0007XN-Gu; Wed, 08 Dec 2004 07:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc0zk-0006ab-1Q for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 07:32:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18296 for ; Wed, 8 Dec 2004 07:32:34 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc16V-0003qp-10 for ipv6@ietf.org; Wed, 08 Dec 2004 07:39:36 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id iB8CWIwP020158; Wed, 8 Dec 2004 12:32:19 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id iB8CWHTI020155; Wed, 8 Dec 2004 12:32:17 GMT Date: Wed, 8 Dec 2004 12:32:17 +0000 From: bmanning@vacation.karoshi.com To: Brian E Carpenter Message-ID: <20041208123217.GA19975@vacation.karoshi.com.> References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <41B5A5B3.9040501@zurich.ibm.com> <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> <41B6C9B5.5070802@zurich.ibm.com> <20041208102048.GC19470@vacation.karoshi.com.> <41B6D878.2050603@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B6D878.2050603@zurich.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ipv6@ietf.org, bmanning@vacation.karoshi.com, Bill Manning , Dan Lanciani Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b On Wed, Dec 08, 2004 at 11:33:28AM +0100, Brian E Carpenter wrote: > bmanning@vacation.karoshi.com wrote: > >>>>Bill, you could do that if the prefixes are *routed* but that is > >>>>not going to be the case if the ULA spec is followed, except for > >>>>private routing arrangements. Since the spec says they MUST NOT > >>>>be globally routed, it seems entirely rational to apply the same > >>>>rule to your zone files. But as I said before, I can live with > >>>>SHOULD NOT. > >>>> > >>>> Brian > >>>> > >>> > >>> please define "globally routable" in technical terms. > >> > >>Why? I didn't use that phrase. The draft doesn't say that, it says > >>that ULA prefixes must not be globally routed. Different. > > > > > > i guess that i am confused here. what does it mean to be "globally > > routed"? > > Advertised in BGP4+ between all or most ISPs. to borrow your term, thats pretty woolly as well. ISP is very nebulous. It has never been adaquately defined. given that the predominant EGP (BGPv4) has extensive knobs for policy control, there is not and can not be a common view of "globally routed". One can take snap shots from various "peepholes" but that does not global routed make. What really matters is can i get my packets to the folks who want/need then and can they get their packets to me? There is no such thing as a "globally routed" prefix. They do not exist. I would like to be proven wrong of course, but I don't think it can be done. Please prove me wrong. > > and how is that different than "globally routable"? > > I didn't attempt to define that since it is indeed a woolly phrase. > Any prefix *could* be globally routed; the interesting question is > whether it *is* globally routed. bingo! and since globally routed is nebulous, it does nto matter... what matters is, do my packets get to where they are going and will the desired replies get back. > > >>> and since routing is not the same as lookup, your assertion > >>> about the "rational" nature of registration in a lookup system > >>> does not hold much credence. > >> > >>Not at all. As others have pointed out, if DNS returns AAA records > >>for prefixes that are not in fact routed, TCP timeouts will result. > >>That's sufficient reason to not put such records in your zone files. > > > > > > so your DNS server in Zurich is expected to have knowledge > > about the state of the routing system between ISPs in Argentina? > > This problem is functionally identical to the original route server > > concept that was used in the NSF NAPs. ISP A could talk to the > > RS and ISP B could talk to the RS, but they could not talk to each > > other ... From the RS point of view, it had no knowledge of the > > policy filters that prevented these two ISPs from exchanging traffic. > > > > DNS is a lookup system. It has zero idea about the currnet state > > of reachability/routedness ... telling me i should not place records > > in my DNS that are useful to me, just because they are not useful to > > you is presumptious at best. > > > > when/if the DNS carries explicit routing information, then i'll be > > willing to buy into your argument... not until then though. > > Perhaps you don't like the reality that most enterprises operate > 2-faced DNS, but they do. what does that have to do with this question? > > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 09:44:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00388 for ; Wed, 8 Dec 2004 09:44:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc39m-000774-G6 for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 09:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2yh-0007F3-Tq; Wed, 08 Dec 2004 09:39:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2oO-0005PS-Jf for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 09:29:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29103 for ; Wed, 8 Dec 2004 09:28:58 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc2vA-0006nQ-Hy for ipv6@ietf.org; Wed, 08 Dec 2004 09:36:01 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.6385074; Wed, 08 Dec 2004 09:27:50 -0500 In-Reply-To: <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Wed, 8 Dec 2004 09:27:50 -0500 To: Alain Durand X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Bob Hinden , ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1472047992==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb --===============1472047992== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--345180870; protocol="application/pkcs7-signature" --Apple-Mail-1--345180870 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 7, 2004, at 18:46, Alain Durand wrote: > > On Dec 7, 2004, at 1:23 PM, Bob Hinden wrote: >> While I am sure everyone in this discussion has read the DNS text in >> the current draft, here it is just in case: >> >> 4.4 DNS Issues >> >> At the present time AAAA and PTR records for locally assigned local >> IPv6 addresses are not recommended to be installed in the global >> DNS. >> The operational issues relating to this are beyond the scope of >> this >> document. >> >> For background on this recommendation, the concern about adding >> AAAA >> and PTR records to the global DNS for locally assigned local IPv6 >> addresses stems from the lack of complete assurance that the >> prefixes >> are unique. There is a small possibility that the same PTR record >> might be registered by two different organizations. Due to this >> concern, adding AAAA records is thought to be unwise because >> matching >> PTR records can not be registered. > > Bob, > > This is unfortunately not the only concern. Actually, i would even say > this is > a somehow minor issue, as the risk of collision is small. > The real concern is similar to what is explain in the v6ops > IPv6onbydefault draft. > > Say that a well know host publish 2 AAAA in the global DNS, a > 'regular' one > and a ULA one, apparently to make local things works better. > What is going to happen is that remote hosts have statistically 50% > chance > to try the ULA first. Then, if TCP is in used, an application will > have to wait up to 3 minutes (according to present TCP specs) before > it can safely fall back to the 2nd address. Note that some > implementations > I know have lowered this timeout, but this is still a critical issue. > > In other words, the concern is not so much with publishing local > addresses > in a local branch of the DNS, but to publish both local and global > data for the same name. > I don't see this as being specific to ULAs. As the above referenced draft points out, this can happen with a mix of IPv4 and IPv6 addresses. It happens today with a mix of global IPv4 addresses and net 10 addresses being associated with the same name. I agree that it is a problem, but not one specific to ULAs. Now, the ULA draft tries to mitigate the issue by recommending that ULAs not be put in the global view DNS. I don't think we can do much more than that. What people do with their local DNS is their business. Regards, Brian --Apple-Mail-1--345180870 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjA4MTQyNzUxWjAjBgkqhkiG9w0B CQQxFgQUnJgroAokuN0VvMCQ0As606kNvCsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAMYlyMUNBYiSXPEkOG4pt1lKx9IXY1xUz9AHLXdNsaOdnL4rh8uqRjxJLQAJoIR6D48xd xrHZpqmMX6Q12eePpr5rFsH7uvOXBoDo4moLKrxUtd7PDZktMEKXLVLMUC/G1hH+FZprW4KV4QS+ bBwqlP/01vb0T07SL/FH2eIHPFcAg4jx5PvRVrrlOddHahBdZgAluVKFktGXB0+pUoqsviW/Jp/r HliwgnejzNpnKwJbnlc2tisHWfI98c8rQPbY+VPakqK6Z8t4X8AXMp3a8wbd5FjwCOllFocGUH4W 8vElT6mFLsUXYyAnr1hAWTf/m1cgJ2i7FaPkZus1poAycAAAAAAAAA== --Apple-Mail-1--345180870-- --===============1472047992== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1472047992==-- From ipv6-bounces@ietf.org Wed Dec 8 10:03:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01819 for ; Wed, 8 Dec 2004 10:03:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc3Sj-0007Za-4m for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 10:10:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc3KM-00036V-Iz; Wed, 08 Dec 2004 10:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc39G-0000cw-Tu for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 09:50:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00972 for ; Wed, 8 Dec 2004 09:50:33 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc3G3-0007HK-UL for ipv6@ietf.org; Wed, 08 Dec 2004 09:57:36 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB8EoKi3009127 for ; Wed, 8 Dec 2004 14:50:20 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA22050 for ; Wed, 8 Dec 2004 14:50:02 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB8Eo2S13185 for ipv6@ietf.org; Wed, 8 Dec 2004 14:50:02 GMT Date: Wed, 8 Dec 2004 14:50:02 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20041208145002.GH12005@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Wed, Dec 08, 2004 at 09:27:50AM -0500, Brian Haberman wrote: > > I agree that it is a problem, but not one specific to ULAs. Indeed, it's the dont-publish-unreachables's draft space... but that one never reached consensus or thus publication. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 15:13:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29726 for ; Wed, 8 Dec 2004 15:13:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc8IJ-0006Wp-H1 for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 15:20:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc86B-0001qn-UT; Wed, 08 Dec 2004 15:07:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc7zD-0003w3-Ie for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 15:00:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28458 for ; Wed, 8 Dec 2004 15:00:29 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc862-0006Gf-PL for ipv6@ietf.org; Wed, 08 Dec 2004 15:07:35 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.6398499; Wed, 08 Dec 2004 14:59:23 -0500 In-Reply-To: <200412072225.iB7MPFsO071015@drugs.dv.isc.org> References: <200412072225.iB7MPFsO071015@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Brian Haberman Date: Wed, 8 Dec 2004 14:59:22 -0500 To: Mark Andrews X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Bob Hinden , ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1586805975==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff --===============1586805975== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--325288981; protocol="application/pkcs7-signature" --Apple-Mail-2--325288981 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 7, 2004, at 17:25, Mark Andrews wrote: > >> Hi, >> >>> OK. Lot of shouting since this was sent but not much new text. >>> >>> How about >>> >>> Locally assigned ULA AAAA records MUST NOT appear in the global >>> DNS, >>> since there is an extremely small probability that the >>> corresponding >>> addresses are not unique. Even though these addresses will be >>> unrouteable in the global Internet, their leakage via DNS is >>> highly >>> undesirable. Such AAAA records MAY appear in local regions of >>> the DNS >>> corresponding to their region of routeability. >>> >>> (And I would put an equivalent SHOULD NOT on centrally assigned >>> ULAs.) >> >> While I am sure everyone in this discussion has read the DNS text in >> the >> current draft, here it is just in case: >> >> 4.4 DNS Issues >> >> At the present time AAAA and PTR records for locally assigned >> local >> IPv6 addresses are not recommended to be installed in the global >> DNS. >> The operational issues relating to this are beyond the scope of >> this >> document. >> >> For background on this recommendation, the concern about adding >> AAAA >> and PTR records to the global DNS for locally assigned local IPv6 >> addresses stems from the lack of complete assurance that the >> prefixes >> are unique. There is a small possibility that the same PTR record >> might be registered by two different organizations. Due to this >> concern, adding AAAA records is thought to be unwise because >> matching >> PTR records can not be registered. >> >> This text (in my view) is more or less equivalent to what is proposed >> above. The text in the draft doesn't use the upper case MUST/SHOULD >> language since this part of the document is operational guidelines >> and that >> language doesn't seem appropriate. I suppose something with lower >> case >> must/should would work. >> >> My personal view is that this is about all we can say now in this >> document. I continue to think that what is needed is a separate >> draft that >> discusses this topic in detail. This document might even relax the >> recommendation if warranted. It would be a good place to describe >> different approaches to the locally and centrally assigned ULAs as >> well. >> >> Chair hat on: >> >> The -08 draft is currently in the IESG. Almost all of the Discuss >> votes >> have been cleared. If we can go with the current text it may result >> in the >> document being approved soon. The more we try to fine tune it there >> is a >> risk of further delay. >> >> It would be good if we could move forward on this document. >> >> Bob > > Which completely ignores the operational problems caused by > leaking reverse lookups. We know these will exist and we > need to take steps to prevent them. > > The only complaint I saw against my proposed text was the level > of proscription against adding AAAA LAU LAs to the global DNS. > > Don't throw the baby out with the bath water. > The concern I have with putting these operational recommendations in this document is that they are applicable to other scenarios (e.g. net 10 addresses in the global DNS). So it seems more reasonable to have a generic guidelines document that discusses address placement in DNS. Regards, Brian --Apple-Mail-2--325288981 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjA4MTk1OTIyWjAjBgkqhkiG9w0B CQQxFgQUP82SMjeNdgs54+xw8RJa1Uc3WaYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAzK/zGPYV9MufYRorhYqebDtyL6sUpskfVAy5XRbW0SJQ/KQAq82KR5e5M40KJmHbq2Xq sT5xrP1IRIS2R8E5jaWxN0ZzCWq/RUMVQYDOhX4hyBa6YHZUmtIaxmco958HhtQtYxCIbnKZrP3z MToEb9WZaLsrBZajXdgsI11JP0bvQO64izD3ra1DWrku2P85w3LNJXC0UOr06celQjd8sDVxlBF1 YaHuhDj4MTAH6HF+QNC2sk8+3nrcRJS8VAM4INBTXkwc71W1GTToS06nDHl6xF8V2ej19QZm/gRK eQhi6cFVpsD5pM+7QBFLHM0ZJA9GT4DjX30eJZhYAb5DawAAAAAAAA== --Apple-Mail-2--325288981-- --===============1586805975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1586805975==-- From ipv6-bounces@ietf.org Wed Dec 8 17:27:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16379 for ; Wed, 8 Dec 2004 17:27:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcAOW-0003En-0H for ipv6-web-archive@ietf.org; Wed, 08 Dec 2004 17:34:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9kH-00083Y-0n; Wed, 08 Dec 2004 16:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9O9-0003PW-79 for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 16:30:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04872 for ; Wed, 8 Dec 2004 16:30:18 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc9Uy-0007zo-EK for ipv6@ietf.org; Wed, 08 Dec 2004 16:37:25 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 5C10A67503 for ; Wed, 8 Dec 2004 21:29:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB8LTZ4D051014; Thu, 9 Dec 2004 08:29:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412082129.iB8LTZ4D051014@drugs.dv.isc.org> To: Brian Haberman From: Mark Andrews In-reply-to: Your message of "Wed, 08 Dec 2004 14:59:22 CDT." Date: Thu, 09 Dec 2004 08:29:35 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 > > --===============1586805975== > Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--325288981 > ; > protocol="application/pkcs7-signature" > > > --Apple-Mail-2--325288981 > Content-Type: text/plain; > charset=US-ASCII; > format=flowed > Content-Transfer-Encoding: 7bit > > > On Dec 7, 2004, at 17:25, Mark Andrews wrote: > > > > >> Hi, > >> > >>> OK. Lot of shouting since this was sent but not much new text. > >>> > >>> How about > >>> > >>> Locally assigned ULA AAAA records MUST NOT appear in the global > >>> DNS, > >>> since there is an extremely small probability that the > >>> corresponding > >>> addresses are not unique. Even though these addresses will be > >>> unrouteable in the global Internet, their leakage via DNS is > >>> highly > >>> undesirable. Such AAAA records MAY appear in local regions of > >>> the DNS > >>> corresponding to their region of routeability. > >>> > >>> (And I would put an equivalent SHOULD NOT on centrally assigned > >>> ULAs.) > >> > >> While I am sure everyone in this discussion has read the DNS text in > >> the > >> current draft, here it is just in case: > >> > >> 4.4 DNS Issues > >> > >> At the present time AAAA and PTR records for locally assigned > >> local > >> IPv6 addresses are not recommended to be installed in the global > >> DNS. > >> The operational issues relating to this are beyond the scope of > >> this > >> document. > >> > >> For background on this recommendation, the concern about adding > >> AAAA > >> and PTR records to the global DNS for locally assigned local IPv6 > >> addresses stems from the lack of complete assurance that the > >> prefixes > >> are unique. There is a small possibility that the same PTR record > >> might be registered by two different organizations. Due to this > >> concern, adding AAAA records is thought to be unwise because > >> matching > >> PTR records can not be registered. > >> > >> This text (in my view) is more or less equivalent to what is proposed > >> above. The text in the draft doesn't use the upper case MUST/SHOULD > >> language since this part of the document is operational guidelines > >> and that > >> language doesn't seem appropriate. I suppose something with lower > >> case > >> must/should would work. > >> > >> My personal view is that this is about all we can say now in this > >> document. I continue to think that what is needed is a separate > >> draft that > >> discusses this topic in detail. This document might even relax the > >> recommendation if warranted. It would be a good place to describe > >> different approaches to the locally and centrally assigned ULAs as > >> well. > >> > >> Chair hat on: > >> > >> The -08 draft is currently in the IESG. Almost all of the Discuss > >> votes > >> have been cleared. If we can go with the current text it may result > >> in the > >> document being approved soon. The more we try to fine tune it there > >> is a > >> risk of further delay. > >> > >> It would be good if we could move forward on this document. > >> > >> Bob > > > > Which completely ignores the operational problems caused by > > leaking reverse lookups. We know these will exist and we > > need to take steps to prevent them. > > > > The only complaint I saw against my proposed text was the level > > of proscription against adding AAAA LAU LAs to the global DNS. > > > > Don't throw the baby out with the bath water. > > > > The concern I have with putting these operational recommendations in > this document is that they are applicable to other scenarios (e.g. net > 10 > addresses in the global DNS). We really should be making a *one stop* document. Sure the same problems apply to RFC 1918 and Link Local (both v4 and v6). We may want a overriding document as well but the same information with specific domain names needs to in all to the above documents. Whenever RFC 1918 gets revised (and it is long overdue for revision) this sort of thing needs to be added there. Along with filtering out packets with you prefix on entry. Most of what is in Section 4 is applicable to RFC 1918. You can connect multiple sites using the address in RFC 1918, you just need to ensure that each site chooses a different prefix. There really is nothing new with ULAs. We have been playing with this sort of stuff for years in one form or another. This document is about collecting what we know should be done and putting it on one place with specific details as they apply to FC00::/7. Thats why I said the DNS section was a "cop out". The DNS information hadn't been collected, distilled and put on paper. I attempted to do that. * Don't publish ambigious addresses global. * It is unwise (but not wrong) to publish unreachable addresses. * Don't let reverse queries for private address space leak. That it is common to leak the private net next to you and you should stop that as well as what you are using. * That you can the apex of the reverse zone for private space to create your own deleation tree (e.g. 10.in-addr.arpa, 168.192.in-addr.arpa) and not have to slave all the reverse zones everywhere. Mark > So it seems more reasonable to have a generic guidelines document > that discusses address placement in DNS. > > Regards, > Brian > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 23:53:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02565 for ; Wed, 8 Dec 2004 23:53:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGPT-0003fw-O9 for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 00:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcGH0-0004L2-Si; Wed, 08 Dec 2004 23:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcGAP-00031g-0N for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 23:44:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02043 for ; Wed, 8 Dec 2004 23:44:34 -0500 (EST) Received: from tm-gw.cictr.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGHI-0003X9-Hs for ipv6@ietf.org; Wed, 08 Dec 2004 23:51:45 -0500 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 231111; Wed, 08 Dec 2004 23:37:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <200412082129.iB8LTZ4D051014@drugs.dv.isc.org> References: <200412082129.iB8LTZ4D051014@drugs.dv.isc.org> Date: Wed, 8 Dec 2004 23:34:08 -0500 To: Mark Andrews From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Mark, > Thats why I said the DNS section was a "cop out". The DNS > information hadn't been collected, distilled and put on > paper. I attempted to do that. > > * Don't publish ambigious addresses global. > * It is unwise (but not wrong) to publish unreachable addresses. > * Don't let reverse queries for private address space leak. > That it is common to leak the private net next to you and > you should stop that as well as what you are using. > * That you can the apex of the reverse zone for private space > to create your own deleation tree (e.g. 10.in-addr.arpa, > 168.192.in-addr.arpa) and not have to slave all the reverse > zones everywhere. I agree that it would be good to document this information, but there are three reasons why I personally don't think that the ULA document is the right place to do this: (1) This is operational information, not part of the specification of these addresses, so it would be better published in a BCP. (2) The IPv6 WG is not the best group to make broad statements about what should/should not be included in the global DNS. The dnsop WG would be a better place for this work. (3) The ULA document has already passed IETF LC and is in the IESG. It should be re-opened for by the WG for critical technical flaws at this point, so I don't think it makes sense to use this document as a vehicle for publishing general information about how to handle local addresses in the DNS. We need to come to some closure on how/if the DNS portions of this document need to change before publication, and we need to do it quickly because this document is already in IESG evaluation. Brian Haberman, I think you are serving as WG chair for this document, right? Could you possibly figure out if this conversation has raised any new issues that need to be considered after IETF LC? If so, can you figure out if there is any IPv6 consensus regarding what to do about them? I need to understand if it is necessary to delay this document for resolution of this issue. Thanks, Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 8 23:58:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02885 for ; Wed, 8 Dec 2004 23:58:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGUP-0003uS-6f for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 00:05:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcGHA-0004SK-Hc; Wed, 08 Dec 2004 23:51:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcGCj-0003Ft-F8 for ipv6@megatron.ietf.org; Wed, 08 Dec 2004 23:47:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02197 for ; Wed, 8 Dec 2004 23:46:58 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGJd-0003Yy-2R for ipv6@ietf.org; Wed, 08 Dec 2004 23:54:10 -0500 Received: from jurassic.eng.sun.com ([129.146.85.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iB94krpv027117; Wed, 8 Dec 2004 20:46:53 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iB94krqr908032; Wed, 8 Dec 2004 20:46:53 -0800 (PST) Message-ID: <41B7D8FC.8050701@sun.com> Date: Wed, 08 Dec 2004 20:47:56 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> In-Reply-To: <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Alain Durand , Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Brian Haberman wrote: > I don't see this as being specific to ULAs. As the above referenced > draft points out, this can happen with a mix of IPv4 and IPv6 addresses. We have RFC 3484 which rationalizes the choice between IPv4 and IPv6 and as long as those are all global addresses the intent is that they all be reachable. ULAs are designed to be unreachable from the most part of the Internet. Thus the probability of trouble is very different. > It happens today with a mix of global IPv4 addresses and net 10 addresses > being associated with the same name. Did you really mean IPv4 and not IPv6? I've never seen a box that has had a net 10 *and* a global IPv4 address assigned to the same interface, but boxes with a ULA and a global IPv6 address on the same interface might become very common. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 00:29:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05138 for ; Thu, 9 Dec 2004 00:29:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGzD-0004Wz-65 for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 00:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcGfk-0002gG-5j; Thu, 09 Dec 2004 00:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcGea-00024u-PB for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 00:15:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04335 for ; Thu, 9 Dec 2004 00:15:45 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGlV-0004Gg-GO for ipv6@ietf.org; Thu, 09 Dec 2004 00:22:57 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id ECB5D67503 for ; Thu, 9 Dec 2004 05:15:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB95F8Zi017609; Thu, 9 Dec 2004 16:15:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412090515.iB95F8Zi017609@drugs.dv.isc.org> To: Margaret Wasserman From: Mark Andrews In-reply-to: Your message of "Wed, 08 Dec 2004 23:34:08 CDT." Date: Thu, 09 Dec 2004 16:15:08 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc > > Hi Mark, > > > Thats why I said the DNS section was a "cop out". The DNS > > information hadn't been collected, distilled and put on > > paper. I attempted to do that. > > > > * Don't publish ambigious addresses global. > > * It is unwise (but not wrong) to publish unreachable addresses. > > * Don't let reverse queries for private address space leak. > > That it is common to leak the private net next to you and > > you should stop that as well as what you are using. > > * That you can the apex of the reverse zone for private space > > to create your own deleation tree (e.g. 10.in-addr.arpa, > > 168.192.in-addr.arpa) and not have to slave all the reverse > > zones everywhere. > > I agree that it would be good to document this information, but there > are three reasons why I personally don't think that the ULA document > is the right place to do this: > > (1) This is operational information, not part of the specification of > these addresses, so it would be better published in a BCP. Then remove all the other operational content. Saying prefixes should be advertised / filtered is as much operational content as saying what should and should not be advertised in the DNS. What I said was specific to ULAs with different constraints on both types of ULA. > (2) The IPv6 WG is not the best group to make broad statements about > what should/should not be included in the global DNS. The dnsop WG > would be a better place for this work. Well run it past DNSOPS/DNSEXT. As far as I can see this was never refered to either group. You have my options from such a referral. > (3) The ULA document has already passed IETF LC and is in the IESG. > It should be re-opened for by the WG for critical technical flaws at > this point, so I don't think it makes sense to use this document as a > vehicle for publishing general information about how to handle local > addresses in the DNS. It is a critical flaw not to say how to prevent excessive load on critical parts of the global DNS infrastucture. > We need to come to some closure on how/if the DNS portions of this > document need to change before publication, and we need to do it > quickly because this document is already in IESG evaluation. > > Brian Haberman, I think you are serving as WG chair for this > document, right? Could you possibly figure out if this conversation > has raised any new issues that need to be considered after IETF LC? > If so, can you figure out if there is any IPv6 consensus regarding > what to do about them? > > I need to understand if it is necessary to delay this document for > resolution of this issue. > > Thanks, > Margaret > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 00:48:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06956 for ; Thu, 9 Dec 2004 00:48:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcHHZ-0004vR-0e for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 00:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcH5r-0000HN-KW; Thu, 09 Dec 2004 00:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcH3y-0008AU-Jg for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 00:42:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06289 for ; Thu, 9 Dec 2004 00:41:59 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcHAt-0004mS-A9 for ipv6@ietf.org; Thu, 09 Dec 2004 00:49:12 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iB95g0dt010079 for ; Wed, 8 Dec 2004 22:42:00 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I8F0005EX60PL@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 08 Dec 2004 22:42:00 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I8F0072EX5YOP@mail.sun.net> for ipv6@ietf.org; Wed, 08 Dec 2004 22:42:00 -0700 (MST) Date: Wed, 08 Dec 2004 21:41:57 -0800 From: Alain Durand In-reply-to: <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> To: Brian Haberman , Margaret Wasserman Message-id: <0A604DCE-49A5-11D9-B0C0-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7BIT Cc: Bob Hinden , "'IETF IPv6 Mailing List'" Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7BIT On Dec 8, 2004, at 6:27 AM, Brian Haberman wrote: >> This is unfortunately not the only concern. Actually, i would even >> say this is >> a somehow minor issue, as the risk of collision is small. >> The real concern is similar to what is explain in the v6ops >> IPv6onbydefault draft. >> >> Say that a well know host publish 2 AAAA in the global DNS, a >> 'regular' one >> and a ULA one, apparently to make local things works better. >> What is going to happen is that remote hosts have statistically 50% >> chance >> to try the ULA first. Then, if TCP is in used, an application will >> have to wait up to 3 minutes (according to present TCP specs) before >> it can safely fall back to the 2nd address. Note that some >> implementations >> I know have lowered this timeout, but this is still a critical issue. >> >> In other words, the concern is not so much with publishing local >> addresses >> in a local branch of the DNS, but to publish both local and global >> data for the same name. >> > > I don't see this as being specific to ULAs. As the above referenced > draft points out, this can happen with a mix of IPv4 and IPv6 > addresses. > It happens today with a mix of global IPv4 addresses and net 10 > addresses > being associated with the same name. > > I agree that it is a problem, but not one specific to ULAs. > > Now, the ULA draft tries to mitigate the issue by recommending that > ULAs not be put in the global view DNS. I don't think we can do much > more than that. What people do with their local DNS is their business. Brian, I'm of the opinion that those are important issues but it is unlikely they will be resolved in this wg. The problem I have with the current text is that it somehow goes too far. It provides a rationale why ULA SHOULD not be published that is not correct and would inevitably lead to confusion. I'd suggest to not publish any rationale and simply say something like: 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document and are discussed in the dnsop working group. Note: I do not think you need another last call, this can be simply fixed in the RFC 48h. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 04:44:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06220 for ; Thu, 9 Dec 2004 04:44:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcKxw-0000cj-C6 for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 04:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcKo9-0004DY-MM; Thu, 09 Dec 2004 04:41:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcKmt-0003yi-0P for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 04:40:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05959 for ; Thu, 9 Dec 2004 04:40:37 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcKtn-0000Xa-IH for ipv6@ietf.org; Thu, 09 Dec 2004 04:47:50 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:b130:5937:253a:915f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CDBD81521A for ; Thu, 9 Dec 2004 18:40:26 +0900 (JST) Date: Thu, 09 Dec 2004 18:40:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [rfc2462bis] a minor nit in creation of global addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 I've been editing a new version of rfc2462bis, mainly addressing AD comments, and I found one minor issue in Section 5.5.3 (creation of global addresses using RA): According to rfc2462bis-06, step (d) of the procedure can be represented as follows: d-1 check whether the prefix in RA is equal to the prefix of an address stateless autoconfiguration in the address list d-2 if not, do some sanity checks, and form an address by concatenating the prefix with the interface identifier d-3 add the new address to the list But what if an address identical which is not configured by stateless autoconfiguration (i.e., either manually or by DHCPv6) happens to be identical to the address being configured? The check in d-1 cannot detect this since it only checks the prefix of a stateless-autoconfigured address (note that this restriction is one of rfc2462bis clarifications based on the wg consensus). A naive implementation would configure duplicated addresses, which should not be the appropriate behavior (I actually made this mistake in my initial attempt of implementing rfc2462bis). Original RFC2462 also seems to have this issue, while the point is vaguer due to its own unclear wording. Such conflict should be rare, but I believe it makes sense to note this explicitly in rfc2462bis. The appropriate behavior in this case might also be controversial, but I think the natural reaction is to simply avoid configuring the duplicate address. So, I'd like to propose to revise the last paragraph of bullet (d) of Section 5.5.3 from: If an address is formed successfully, the host adds it to the list of addresses assigned to the interface, initializing its preferred and valid lifetime values from the Prefix Information option. to: If an address is formed successfully and the address is not yet in the list, the host adds it to the list of addresses assigned to the interface, initializing its preferred and valid lifetime values from the Prefix Information option. Note that the check against the prefix performed at the beginning of this step cannot always detect the address conflict in the list. It could be possible that an address already in the list, configured either manually or by DHCPv6, happens to be identical to the newly created address whereas such a case should be atypical. Comments? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 05:17:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08485 for ; Thu, 9 Dec 2004 05:17:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcLTj-0001N8-Ho for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 05:24:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcLJz-0001l2-3E; Thu, 09 Dec 2004 05:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcLG7-0000nz-MZ for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 05:10:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07973 for ; Thu, 9 Dec 2004 05:10:49 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcLN4-0001DZ-Qy for ipv6@ietf.org; Thu, 09 Dec 2004 05:18:03 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iB9AAji3000399 for ; Thu, 9 Dec 2004 10:10:45 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA19293 for ; Thu, 9 Dec 2004 10:10:30 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iB9AAU602047 for ipv6@ietf.org; Thu, 9 Dec 2004 10:10:30 GMT Date: Thu, 9 Dec 2004 10:10:30 +0000 From: Tim Chown To: "'IETF IPv6 Mailing List'" Message-ID: <20041209101030.GC32139@login.ecs.soton.ac.uk> Mail-Followup-To: 'IETF IPv6 Mailing List' References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> <0A604DCE-49A5-11D9-B0C0-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A604DCE-49A5-11D9-B0C0-00039376A6AA@sun.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Wed, Dec 08, 2004 at 09:41:57PM -0800, Alain Durand wrote: > > I'd suggest to not publish any rationale and simply say something like: > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local > IPv6 addresses are not recommended to be installed in the global DNS. > The operational issues relating to this are beyond the scope of this > document and are discussed in the dnsop working group. > > Note: I do not think you need another last call, this can be simply > fixed > in the RFC 48h. This sounds good to me. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 06:07:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12394 for ; Thu, 9 Dec 2004 06:07:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcMGO-0002Ru-RR for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 06:15:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcM6u-0001SW-W2; Thu, 09 Dec 2004 06:05:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcLuW-0000AU-VB for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 05:52:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11174 for ; Thu, 9 Dec 2004 05:52:34 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcM1U-00026Z-6R for ipv6@ietf.org; Thu, 09 Dec 2004 05:59:49 -0500 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iB9Aq3bP018672 for ; Thu, 9 Dec 2004 10:52:03 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB9AqG4g061712 for ; Thu, 9 Dec 2004 11:52:16 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB9Aq3J6029604 for ; Thu, 9 Dec 2004 11:52:03 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB9Aq3EL029589 for ; Thu, 9 Dec 2004 11:52:03 +0100 Received: from zurich.ibm.com (sig-9-145-250-79.de.ibm.com [9.145.250.79]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA91994 for ; Thu, 9 Dec 2004 11:52:02 +0100 Message-ID: <41B82E53.2050907@zurich.ibm.com> Date: Thu, 09 Dec 2004 11:52:03 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ipv6@ietf.org References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <41B5A5B3.9040501@zurich.ibm.com> <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> <41B6C9B5.5070802@zurich.ibm.com> <20041208102048.GC19470@vacation.karoshi.com.> <41B6D878.2050603@zurich.ibm.com> <20041208123217.GA19975@vacation.karoshi.com.> In-Reply-To: <20041208123217.GA19975@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Bill, this is my last go on this. Not that I specially want to leave you the last word, but if you don't get what I'm saying after all this, it's pointless to continue. Below... bmanning@vacation.karoshi.com wrote: > On Wed, Dec 08, 2004 at 11:33:28AM +0100, Brian E Carpenter wrote: > >>bmanning@vacation.karoshi.com wrote: >> >>>>>>Bill, you could do that if the prefixes are *routed* but that is >>>>>>not going to be the case if the ULA spec is followed, except for >>>>>>private routing arrangements. Since the spec says they MUST NOT >>>>>>be globally routed, it seems entirely rational to apply the same >>>>>>rule to your zone files. But as I said before, I can live with >>>>>>SHOULD NOT. >>>>>> >>>>>>Brian >>>>>> >>>>> >>>>> please define "globally routable" in technical terms. >>>> >>>>Why? I didn't use that phrase. The draft doesn't say that, it says >>>>that ULA prefixes must not be globally routed. Different. >>> >>> >>> i guess that i am confused here. what does it mean to be "globally >>> routed"? >> >>Advertised in BGP4+ between all or most ISPs. > > > to borrow your term, thats pretty woolly as well. > ISP is very nebulous. It has never been adaquately > defined. > given that the predominant EGP (BGPv4) has extensive > knobs for policy control, there is not and can not be a > common view of "globally routed". One can take snap shots > from various "peepholes" but that does not global routed make. > What really matters is can i get my packets to the folks who > want/need then and can they get their packets to me? There is no such > thing as a "globally routed" prefix. They do not exist. > I would like to be proven wrong of course, but I don't think > it can be done. Please prove me wrong. It is certainly true (and I check potaroo.net regularly) that the default-free zone is different according to where you sit in the network. But it's equally true (and the recent pseudoPI proposal confirms it) that having any particular view of the DFZ polluted by a few thousand non-aggregated long prefixes (for any definition of "long" that you prefer) doesn't actually matter. That's the beauty of BGP4, in fact. So, while you are correct that there is no unique definition of "globally routed", because there is no globally unique DFZ, I don't think this affects the logic here at all. If a prefix is advertised in one or more of the world's DFZ's, it's in practice globally routed. > > > >>> and how is that different than "globally routable"? >> >>I didn't attempt to define that since it is indeed a woolly phrase. >>Any prefix *could* be globally routed; the interesting question is >>whether it *is* globally routed. > > > bingo! and since globally routed is nebulous, it does nto > matter... what matters is, do my packets get to where they are going > and will the desired replies get back. Well indeed. I wasn't trying to say anything else. > > >>>>> and since routing is not the same as lookup, your assertion >>>>> about the "rational" nature of registration in a lookup system >>>>> does not hold much credence. >>>> >>>>Not at all. As others have pointed out, if DNS returns AAA records >>>>for prefixes that are not in fact routed, TCP timeouts will result. >>>>That's sufficient reason to not put such records in your zone files. >>> >>> >>> so your DNS server in Zurich is expected to have knowledge >>> about the state of the routing system between ISPs in Argentina? >>> This problem is functionally identical to the original route server >>> concept that was used in the NSF NAPs. ISP A could talk to the >>> RS and ISP B could talk to the RS, but they could not talk to each >>> other ... From the RS point of view, it had no knowledge of the >>> policy filters that prevented these two ISPs from exchanging traffic. >>> >>> DNS is a lookup system. It has zero idea about the currnet state >>> of reachability/routedness ... telling me i should not place records >>> in my DNS that are useful to me, just because they are not useful to >>> you is presumptious at best. >>> >>> when/if the DNS carries explicit routing information, then i'll be >>> willing to buy into your argument... not until then though. >> >>Perhaps you don't like the reality that most enterprises operate >>2-faced DNS, but they do. > > > what does that have to do with this question? Let's assume that server.example.com has an AAAA record that returns a ULA inside company example.com, but the AAAA record is not exported from example.com. (That's common practice today with A records that return RFC 1918 or even global IPv4 addresses that don't happen to be routed by example.com's ISP. In fact, that's what will happen when I press Send on this email.) I think all the ULA draft can say is that this should be normal practice - don't put an AAAA record outside your firewall if the underlying address isn't routed outside your firewall. And it isn't in fact anything specific to ULAs. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 06:46:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15065 for ; Thu, 9 Dec 2004 06:46:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcMrZ-00039e-48 for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 06:53:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcMjc-0002jC-Jh; Thu, 09 Dec 2004 06:45:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcMes-00028i-B0 for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 06:40:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14851 for ; Thu, 9 Dec 2004 06:40:27 -0500 (EST) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcMlq-000348-2o for ipv6@ietf.org; Thu, 09 Dec 2004 06:47:42 -0500 Received: from [128.9.176.163] (helo=[128.9.176.163]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1CcMeW-000A7W-29; Thu, 09 Dec 2004 11:40:09 +0000 In-Reply-To: <41B82E53.2050907@zurich.ibm.com> References: <200412032014.PAA09501@ss10.danlan.com> <41B426FF.6070709@zurich.ibm.com> <41B5A5B3.9040501@zurich.ibm.com> <7BE45DA2-48A2-11D9-89BF-000D9329F0D6@karoshi.com> <41B6C9B5.5070802@zurich.ibm.com> <20041208102048.GC19470@vacation.karoshi.com.> <41B6D878.2050603@zurich.ibm.com> <20041208123217.GA19975@vacation.karoshi.com.> <41B82E53.2050907@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3827A2F8-49D7-11D9-9BE0-000D9329F0D6@karoshi.com> Content-Transfer-Encoding: 7bit From: Bill Manning Date: Thu, 9 Dec 2004 06:41:09 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On Dec 9, 2004, at 5:52, Brian E Carpenter wrote: > Bill, this is my last go on this. Not that I specially want > to leave you the last word, but if you don't get what I'm > saying after all this, it's pointless to continue. Below... > we agree to disagree. only history will tell if the IESG is making the right choice here. as a final - this looks so much like RFC 1918 that it is frightening. esp when we look at the public query load of these supposedly private addresses. use of views, as common as it is, remains perverse and in contravention of the IAB statement on a common namespace. So i guess your right, this is not the end2end, common namespace Internet that I thought it was. This is the Internet of NAT, Walled Gardens, and incoherency.... The market is a powerful master. --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 08:03:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18987 for ; Thu, 9 Dec 2004 08:03:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcO3z-0004TS-3z for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 08:10:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcNsT-0001Uu-RE; Thu, 09 Dec 2004 07:58:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcNrP-0001Ak-51 for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 07:57:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18716 for ; Thu, 9 Dec 2004 07:57:30 -0500 (EST) Received: from tm-gw.cictr.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcNyN-0004NE-8q for ipv6@ietf.org; Thu, 09 Dec 2004 08:04:44 -0500 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 240005; Thu, 09 Dec 2004 07:50:38 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20041208145002.GH12005@login.ecs.soton.ac.uk> References: <6.1.2.0.2.20041207130532.0636e6a8@mailhost.iprg.nokia.com> <455E5020-48AA-11D9-B591-00039376A6AA@sun.com> <5702B970-4925-11D9-98B5-000D93330CAA@innovationslab.net> <20041208145002.GH12005@login.ecs.soton.ac.uk> Date: Thu, 9 Dec 2004 07:46:02 -0500 To: Tim Chown From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >On Wed, Dec 08, 2004 at 09:27:50AM -0500, Brian Haberman wrote: >> >> I agree that it is a problem, but not one specific to ULAs. > >Indeed, it's the dont-publish-unreachables's draft space... but that one >never reached consensus or thus publication. Right. And, while I personally agree with the don't-publish-unreachables concept, it has been a controversial one one in the DNS community. It is not fair to use the ULA document as a path to standardization of that concept, when we don't know if the people who objected to its publication in other fora are involved here. The whole question of how/if to handle local addressing in the DNS is a hairy one, and one that it isn't the IPv6 WG's job to solve. This document has already been reviewed by the IESG, and there is one discuss outstanding (from Ted Hardie). So, we need to be conservative at this point regarding what (if any) changes we make to the document. If we make substantial technical changes, the document will at least have to return to IETF LC and be re-reviewed by the IESG. We cannot, in good conscience slip in controversial DNS wording into the document at this point in the process. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 11:28:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07469 for ; Thu, 9 Dec 2004 11:28:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcRGP-0000dz-RL for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 11:35:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQtn-00057Q-V9; Thu, 09 Dec 2004 11:12:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQna-0003cj-6f for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 11:05:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05259 for ; Thu, 9 Dec 2004 11:05:44 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcQua-0008T3-Hy for ipv6@ietf.org; Thu, 09 Dec 2004 11:13:01 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Dec 2004 11:05:12 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Dec 2004 11:05:14 -0500 Message-ID: Thread-Topic: RFC2526 and node requirements document Thread-Index: AcTct5Cdqo1uUXEXQf2uIBY8ye0cQQBUS+sw From: "Soliman, Hesham" To: "Alain Durand" , , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 09 Dec 2004 16:05:12.0872 (UTC) FILETIME=[DD653A80:01C4DE08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Subject: RE: RFC2526 and node requirements document X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable >=20 > I couldn't find any mention of RFC2526 "Reserved IPv6 Subnet Anycast=20 > Addresses" > in the node requirement document. > Is it OK for an IPv6 node to ignore it? in practice, should/must an=20 > implementation > have some code to: > 1- prohibit such addresses to be configured on an interface > 2- make sure that no ICMP messages are ever sent to such addresses? =3D> Either of those options would break RFC 3775, which uses=20 ICMP for Dynamic HA address discovery.=20 Hesham >=20 > - Alain. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 9 21:03:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09370 for ; Thu, 9 Dec 2004 21:03:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcaFP-00007P-Ur for ipv6-web-archive@ietf.org; Thu, 09 Dec 2004 21:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cca0h-0001G4-80; Thu, 09 Dec 2004 20:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcZtp-0000Cl-KD for ipv6@megatron.ietf.org; Thu, 09 Dec 2004 20:48:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08488 for ; Thu, 9 Dec 2004 20:48:48 -0500 (EST) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cca0v-0008If-7Z for ipv6@ietf.org; Thu, 09 Dec 2004 20:56:09 -0500 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 17F00B89A for ; Thu, 9 Dec 2004 17:48:45 -0800 (PST) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05826-03 for ; Thu, 9 Dec 2004 17:48:42 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [IPv6:3ffe:1200:3033:1::158]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DE2E8B85F for ; Thu, 9 Dec 2004 17:48:41 -0800 (PST) Received: from [172.17.55.7] (69-174-161-251.frdrmd.adelphia.net [69.174.161.251]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id iBA1sm4J030477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 9 Dec 2004 17:54:54 -0800 Message-ID: <41B90027.6060009@innovationslab.net> Date: Thu, 09 Dec 2004 20:47:19 -0500 From: Brian Haberman User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 Mailing List References: <200412082129.iB8LTZ4D051014@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Please note that I am the shepherding chair for this document. I have gone through the mailing list discussions on this document several times. Everyone should note that this document has been through WG Last Call, IESG Review, and IETF Last Call. Given the level of reviews and comments, there is WG consensus to leave the DNS text as is in the -08 version. Given some of the operational issues raised, I am recommending that the more global issue of reachable-vs-unreachable addresses in the DNS be referred to the dnsops and/or v6ops WGs. The IPv6 WG does not have the expertise (nor the mission) to address this DNS operational issue. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 10 02:45:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19243 for ; Fri, 10 Dec 2004 02:45:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcfaI-0006Ok-SL for ipv6-web-archive@ietf.org; Fri, 10 Dec 2004 02:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcfQZ-0002c8-SX; Fri, 10 Dec 2004 02:42:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcfOp-0001tL-Dr for ipv6@megatron.ietf.org; Fri, 10 Dec 2004 02:41:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18829 for ; Fri, 10 Dec 2004 02:41:09 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcfVx-0006IR-DZ for ipv6@ietf.org; Fri, 10 Dec 2004 02:48:34 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:5c31:4b60:a406:2638]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 20E3A15210 for ; Fri, 10 Dec 2004 16:41:07 +0900 (JST) Date: Fri, 10 Dec 2004 16:41:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Re: [rfc2462bis] a minor nit in creation of global addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 >>>>> On Thu, 09 Dec 2004 18:40:33 +0900, >>>>> JINMEI Tatuya said: > I've been editing a new version of rfc2462bis, mainly addressing AD > comments, and I found one minor issue in Section 5.5.3 (creation of > global addresses using RA): (snip) > So, I'd like to propose to revise the last paragraph of bullet (d) of > Section 5.5.3 from: > If an address is formed successfully, the host adds it to the list > of addresses assigned to the interface, initializing its preferred > and valid lifetime values from the Prefix Information option. > to: > If an address is formed successfully and the address is not yet in > the list, the host adds it to the list of addresses assigned to > the interface, initializing its preferred and valid lifetime > values from the Prefix Information option. Note that the check > against the prefix performed at the beginning of this step cannot > always detect the address conflict in the list. It could be > possible that an address already in the list, configured either > manually or by DHCPv6, happens to be identical to the newly > created address whereas such a case should be atypical. I've not seen any responses to the proposal. I'll probably need to wait for a while, but I'd rather to send this version as proposed soon. Of course, comments on this change for the new version of the document will be welcome. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 10 04:43:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27738 for ; Fri, 10 Dec 2004 04:43:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CchQ9-0000NI-Fm for ipv6-web-archive@ietf.org; Fri, 10 Dec 2004 04:50:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CchGn-0004oy-Ob; Fri, 10 Dec 2004 04:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CchBe-0003Xy-Q3 for ipv6@megatron.ietf.org; Fri, 10 Dec 2004 04:35:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27262 for ; Fri, 10 Dec 2004 04:35:40 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CchIn-0000FZ-Qp for ipv6@ietf.org; Fri, 10 Dec 2004 04:43:07 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:5c31:4b60:a406:2638]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8BBDD1521A; Fri, 10 Dec 2004 18:35:39 +0900 (JST) Date: Fri, 10 Dec 2004 18:35:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200412060043.iB60hJ926432@windsor.research.att.com> References: <6.1.2.0.2.20041202124550.035c8dc8@mailhost.iprg.nokia.com> <200412030018.iB30I6gM025024@nest.sm.sony.co.jp> <200412031732.iB3HWWT17511@windsor.research.att.com> <200412060043.iB60hJ926432@windsor.research.att.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >>>>> On Sun, 5 Dec 2004 16:43:18 -0800, >>>>> Bill Fenner said: >> p.s. I've noticed the draft-ietf-ipv6-scoping-arch-02.txt has been in >> the RFC editor queue for over 3 months. Is anyone know whether this >> is a usual delay or the issues with the URI syntax is working as a >> showstopper? > The RFCs that have been published over the last couple of months have > had average delays of just over 4 months. As far as I know, nobody > has suggested delaying this document's publication as RFC. Ah, I see. Thanks for the clarification. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 10 05:03:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28726 for ; Fri, 10 Dec 2004 05:03:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CchjQ-0000jD-Gf for ipv6-web-archive@ietf.org; Fri, 10 Dec 2004 05:10:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccha8-0001B3-HB; Fri, 10 Dec 2004 05:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CchXt-0000h2-QQ for ipv6@megatron.ietf.org; Fri, 10 Dec 2004 04:58:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28506 for ; Fri, 10 Dec 2004 04:58:39 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cchf3-0000d8-Eb for ipv6@ietf.org; Fri, 10 Dec 2004 05:06:06 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I8I00MRP3OSD6@mailout1.samsung.com> for ipv6@ietf.org; Fri, 10 Dec 2004 18:58:04 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I8I00KZC3M1GH@mailout1.samsung.com> for ipv6@ietf.org; Fri, 10 Dec 2004 18:56:25 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I8I0063X3LX64@mmp1.samsung.com> for ipv6@ietf.org; Fri, 10 Dec 2004 18:56:25 +0900 (KST) Date: Fri, 10 Dec 2004 15:23:16 +0530 From: Syam Madanapalli To: ipv6@ietf.org Message-id: <004101c4de9e$14512dc0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7BIT Cc: Jinmei Tatuya Subject: Re: [rfc2462bis] a minor nit in creation of global addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7BIT Hi Jinmei, I am wondering whether you are talking about the duplicate address (/128) or duplicate prefix. Let us say, you have an address configured using DHCP with differe IID and if you are using SLAAC using differe IID but same prefix; is this okay? -Syam ----- Original Message ----- From: )> To: Sent: Thursday, December 09, 2004 3:10 PM Subject: [rfc2462bis] a minor nit in creation of global addresses > I've been editing a new version of rfc2462bis, mainly addressing AD > comments, and I found one minor issue in Section 5.5.3 (creation of > global addresses using RA): > > According to rfc2462bis-06, step (d) of the procedure can be > represented as follows: > > d-1 check whether the prefix in RA is equal to the prefix of an address > stateless autoconfiguration in the address list > d-2 if not, do some sanity checks, and form an address by concatenating > the prefix with the interface identifier > d-3 add the new address to the list > > But what if an address identical which is not configured by stateless > autoconfiguration (i.e., either manually or by DHCPv6) happens to be > identical to the address being configured? The check in d-1 cannot > detect this since it only checks the prefix of a > stateless-autoconfigured address (note that this restriction is one of > rfc2462bis clarifications based on the wg consensus). A naive > implementation would configure duplicated addresses, which should not > be the appropriate behavior (I actually made this mistake in my > initial attempt of implementing rfc2462bis). > > Original RFC2462 also seems to have this issue, while the point is > vaguer due to its own unclear wording. > > Such conflict should be rare, but I believe it makes sense to note > this explicitly in rfc2462bis. The appropriate behavior in this case > might also be controversial, but I think the natural reaction is to > simply avoid configuring the duplicate address. > > So, I'd like to propose to revise the last paragraph of bullet (d) of > Section 5.5.3 from: > > If an address is formed successfully, the host adds it to the list > of addresses assigned to the interface, initializing its preferred > and valid lifetime values from the Prefix Information option. > > to: > > If an address is formed successfully and the address is not yet in > the list, the host adds it to the list of addresses assigned to > the interface, initializing its preferred and valid lifetime > values from the Prefix Information option. Note that the check > against the prefix performed at the beginning of this step cannot > always detect the address conflict in the list. It could be > possible that an address already in the list, configured either > manually or by DHCPv6, happens to be identical to the newly > created address whereas such a case should be atypical. > > Comments? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 10 05:56:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03058 for ; Fri, 10 Dec 2004 05:56:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CciYf-0001j4-5C for ipv6-web-archive@ietf.org; Fri, 10 Dec 2004 06:03:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CciQ1-0004Yd-Ql; Fri, 10 Dec 2004 05:54:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CciPf-0004IJ-3N for ipv6@megatron.ietf.org; Fri, 10 Dec 2004 05:54:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02819 for ; Fri, 10 Dec 2004 05:54:12 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CciWo-0001gt-Rx for ipv6@ietf.org; Fri, 10 Dec 2004 06:01:40 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:5c31:4b60:a406:2638]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 221AA15210; Fri, 10 Dec 2004 19:54:08 +0900 (JST) Date: Fri, 10 Dec 2004 19:54:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Syam Madanapalli In-Reply-To: <004101c4de9e$14512dc0$59476c6b@sisodomain.com> References: <004101c4de9e$14512dc0$59476c6b@sisodomain.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] a minor nit in creation of global addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> On Fri, 10 Dec 2004 15:23:16 +0530, >>>>> Syam Madanapalli said: > I am wondering whether you are talking about the duplicate address (/128) or > duplicate prefix. Let us say, you have an address configured using DHCP > with differe IID and if you are using SLAAC using differe IID but same > prefix; is this okay? Yes, this should be okay (while DHCPv6 does not provide the "prefix" of an address, so we can detect those two have the same "prefix" only by applying the prefix of the SLAAC address to the DHCPv6 address). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 10 09:46:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18698 for ; Fri, 10 Dec 2004 09:46:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccm9Z-0006Jh-Ln for ipv6-web-archive@ietf.org; Fri, 10 Dec 2004 09:53:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccly2-0005jY-1D; Fri, 10 Dec 2004 09:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cclvt-0005Pf-HX for ipv6@megatron.ietf.org; Fri, 10 Dec 2004 09:39:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18023; Fri, 10 Dec 2004 09:39:43 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccm34-0006B4-95; Fri, 10 Dec 2004 09:47:12 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.10594006; Fri, 10 Dec 2004 09:38:53 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: minutes@ietf.org Message-Id: <36E0D3F2-4AB9-11D9-B05B-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Fri, 10 Dec 2004 09:38:53 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 Cc: IPv6 WG , Bob Hinden Subject: IPv6 WG Minutes from IETF61 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1760960649==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f5e3f76ec5b90a46b9b8bc53da20ed8e --===============1760960649== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--171718100; protocol="application/pkcs7-signature" --Apple-Mail-3--171718100 Content-Type: multipart/mixed; boundary=Apple-Mail-2--171718282 --Apple-Mail-2--171718282 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, Attached are the minutes of the IPv6 WG session at IETF61. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-2--171718282 Content-Type: text/plain; x-unix-mode=0644; name="ipv6wg_minutes.txt" Content-Disposition: attachment; filename=ipv6wg_minutes.txt Content-Transfer-Encoding: quoted-printable IP Version 6 WG (ipv6)=0D =0D Thursday, November 11 at 0900-1130=0D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D =0D Chair(s):=0D Robert Hinden =0D Brian Haberman =0D =0D Agenda:=0D =0D - Agenda Bashing Haberman 04 Minutes=0D =0D dupont - requests time to speak about getting /16 prefix allocated for = crypto generated id's.=0D hinden - if we have time=0D =0D haberman - tahi interop test announcement - similar structure to = previous tahi tests, some new things for ike, nemo, etc. more info at = tahi web page.=0D =0D - Document Status Haberman 01 Minute=0D http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html=0D= =0D no issues or comments on document status=0D =0D - Milestone Updates Hinden 10 Minutes=0D =0D http://www.ietf.org/html.charters/ipv6-charter.html=0D chairs have worked with ADs to update charter milestones. the = things-done list is bigger than the to-do list :).=0D hope to get outstanding work done within next couple of ietf meetings.=0D= =0D - Node Information Queries Hinden 10 Minutes=0D - Goal: determine direction of the work=0D =0D last draft is -10, now shipping in several implementations. need to get = this published. was consensus after vienna provided some clarifications = on privacy addresses are made. plan was to make those changes and then = submit as PS. is there anyone interested working on this? author hasn't = been active lately.=0D =0D no questions/comments=0D =0D - Privacy Addresses v2 Krishnan 15 Minutes=0D - Goal: Progress as Draft Standard=0D - draft-ietf-ipv6-privacy-addrs-v2-01.txt=0D =0D what's new? - see slides=0D =0D hinden - agrees there are no interop issues, nor is the new algorithm = better or worse, but the issues which caused the community to switch = don't relate to this. there is no reason for implementors to change. the = goal is not to get people to change code to comply with this. need to = make this clear in doc.=0D =0D krishnan - has change pending that may require code changes=0D =0D hinden - well we can't do that, but let's discuss it when you present = the change=0D =0D greg daley - we already understand well what well-distributed random = numbers are. just need references to docs that explain that.=0D =0D krishnan - does have reference=0D =0D open issues=0D - per-prefix knobs (will break backwards compatibility)=0D =0D ralph droms - how does it break backwards compatibility?=0D author - not required in previous version of rfc3041=0D thaler - don't make it a must, make it a may or a should and then it is = a non-issue=0D savola - this is connected to next issues regarding ULAs, so should = discuss these together=0D hain - this is no different to changing the default of generate or not. = if you get per-prefix knobs, nodes that do that don't break older = implementations. just means that older nodes are doing something = different. =0D nordmark - is there any possibility that the tie-breaker rules in = RFC3848 has any interaction with this?=0D hain - if you don't have one of these suffixes then tie-breaker won't = take effect.=0D thaler - longest-prefix match is last rule, so this comes in first. = prefix doesn't matter until you've looked at every other rule there is.=0D= =0D - isatap and rfc2526 downref=0D thaler - don't have problem with new text. avoiding isatap addrs isn't = really a MUST.=0D =0D - unique local addresses=0D do they need temp addrs?=0D =0D daley - don't treat them differently, at least don't explicitly exclude=0D= hinden - yes, they're just unicast prefixes, don't treat them = differently=0D hain - agrees shouldn't consider them to be different, but there is a = strong bias for operators to not want random values to show up in their = internal network. so probably don't want to do this in the ULA case. = per-prefix knobs solves this problem.=0D carpenter - ULAs special? yes and no. in large company they're not = special at all. outside that company those addrs are a bug. should be = prefix specific and then ULA is just a special prefix.=0D nordmark - agrees=0D thaler - only concern about per-prefix knobs is that hosts won't know = their prefix until they get RA, so how does host get configured?=0D krishnan - it is configured on host, hasn't thought about how this is = administered.=0D savola - assume many enterprises will want to use ULAs for local = communication only, but might still want to generate temp addrs for = global communication. therefore recommend that by default ULAs don't = generate temp addrs. but then you need normative ref to something that = defines ULA.=0D hinden - might be better to put text in ULA doc as this doc is going to = DS.=0D hain - are you considering lifetime support?=0D krishnan - higher lifetime is bound to RA, but max for temp addr is = independent of that.=0D hain - per-prefix knobs might require per-prefix temp valid lifetime=0D thaler - pleas make clear that prefix doesn't need to be subnet prefix = but something shorter could be used=0D hinden - that would work well for regular unicast addresses as well=0D =0D -02 version has been submitted, but hasn't been published yet. ULA text = is in there.=0D =0D -64-bit IID only?=0D will add clarifying text to say that IIDs don't have to be 64 bit, but = this text only applies to 64-bit IIDs.=0D =0D Any other issues?=0D droms - if there will be another rev and opportunity to comment, then he = has new text that doesn't need to be discussed here=0D krishnan - there will be another rev=0D =0D =0D - IPv6 over PPP v2 Varada 10 Minutes=0D - Goal: Progress as Draft Standard=0D - draft-ietf-ipv6-over-ppp-v2-01.txt=0D =0D no changes since last -01 rev was released in June=0D =0D is in last call now=0D =0D one editorial change planned, unless further comments come in=0D =0D please review and make any comments on the mailing list soon.=0D =0D savola - i have provided feedback a couple of times, but has not gone = anywhere other than author contacting me off list. what i see as = problematic is that DAD can be disabled under certain circumstances, but = doesn't say how implementations figure out whether these circumstances = are met.=0D =0D haberman - will take action to talk to author to see what's going on = with those comments.=0D =0D - AD feedback on 2462 update Jinmei 20 Minutes=0D - Goal: Resolve AD comments=0D - draft-ietf-ipv6-rfc2462bis-06.txt=0D =0D WGLC completed in July 2004, new rev -06 published in August=0D submitted to IESG in Sept, AD review finished in Oct=0D two major issues=0D - M/O flag clarification=0D - confusing wording regarding 'stateful' vs dhcpv6=0D would like to confirm mailing list consensus in this meeting=0D =0D M/O flag behaviour=0D - proposed resolution - describe details on flags in separate PS doc=0D - (draft-daniel-ipv6-ra-mo-flags-01.txt, just adopted as WG work item)=0D= =0D stateful vs dhcpv6=0D - wording used as part of the 'O' flag, clarify why we use 'stateful' = while RFC3736 calls it 'stateless', ugly but didn't want to introduce = radical change - AD comment - it's just confusing=0D proposed resolution - remove 'stateful' and just use dhcpv6 instead, = should be ok if we agree with the previous change, RFC2462bis won't use = the phrase of 'other stateful config' for the O flag. additional effects = - 2461bis and M/O doc will need to be modified.=0D =0D nordmark - 2461 uses 'stateful' in 4 or 5 places. if we change name of O = flag to 'other config' then we're fine. replace 'stateful' with dhcpv6 = as appropriate in 2461bis.=0D =0D droms - agrees with nordmark.=0D =0D other minor issues=0D - change on the 'A' flag=0D what happens if value of A flag changes over time=0D answer: nothing - should be pretty clear in section 5.5.3.=0D =0D droms - can't think of situation were previously advertised prefix = becomes unavailable for autonomous auto-config, but just wants to be = clear that this is being prohibited by this=0D =0D nordmark - prefixes should time out for SAAD. receiving a prefix means = nothing. this needs to be clarified=0D =0D tatuya - this doesn't seem to be a substantial issue=0D =0D nordmark - if setting A flag off doesn't result in prefixes timing out = for SAAD, then there is a problem, right?=0D =0D wasserman - if previously advertised prefix is re-advertised without A = flag, then don't stop using previously configured address. but if = lifetime times out, then you have to stop using the addr. needs = clarifications for implementors.=0D =0D hain - agrees with margaret. during multi6 discussion there was some = talk about prefixes in the RA used to determine whether this is the same = link, so there might be a reason for RAs to turn up with A flag off = (just to serve as link determinants).=0D =0D krishnan - thinks this is already clear from current text.=0D =0D daley - DNA is looking at link identification. link identification using = prefixes might be a product of DNA design team. there may be some = subtleties here. people may be relying on what they believe existing = behaviour to be, so clarification may be useful here.=0D =0D tatuya - let's confirm consensus on mailing list, if changes are = required then he will make them in next rev.=0D =0D other issues=0D terminology ordering - alphabetical or 'as is'?=0D wasserman - it's fine as it is=0D =0D need ref to addr-arch in LL conf - will do=0D =0D inconsistent wording regarding DAD section. just a wording issue - = replace lowercase 'must' with 'should' to avoid possible confusion.=0D =0D next steps=0D verify proposed resolutions to issues are OK. several positive responses = and no negative ones on list. so WG agreeing on course of action.=0D =0D revised draft will be issued including further clarifications and = changes and discussed above.=0D snapshot is available at = http://www.jinmei.org/draft-ietf-ipv6-rfc262bis-07beta1.txt=0D =0D hold it waiting for 2461bis? another AD comment=0D proceed to IETF LC anyway?=0D =0D Daley - has this already completed WG LC?=0D Tatuya - Yes. Initial AD review has also been done.=0D =0D Chairs - will send to IESG with 2461bis when that is ready.=0D =0D =0D =0D Router selection draft update - dave thaler=0D =0D draft -05 passed wg last call, submitted to IESG=0D several editorial nits, and 2 technical ones=0D draft-06 addresses all but 1 issue=0D editorial nits are available on issues list for this draft=0D all included in -06=0D =0D implicit deletion (issue from Thomas Narten)=0D - delete all routes if router lifetime -> 0?=0D - no, requires explicit deletion of each route, therefore no change in = -06=0D current behaviour is also consistent with Prefix Info Opts=0D Narten - when I made comment, I had notion that default router that = stops being router, doesn't make sense to forward traffic to it any = more. =0D nordmark - there might be a useful distinction between default router =3D = send me packet and i'll send it off where i can, and being a good router = for default...=0D thaler - draft addresses this already, there is some discussion and an = example or two=0D thaler - interpreation of router lifetime is lifetime of presence of = router in default router list=0D some discussion between narten and thaler that went too fast for me to = catch, but sounded like agreement :)=0D =0D last two issues are separate on issues list, but turn out to be the same = issue=0D 24 dynamic routes (alex zinin), 27 end-to-end reachability (steve = bellovin)=0D =0D zinin has submitted text=0D =0D savola - isn't this issue also in basic RA? are we trying to fix a = specific case of a more generic problem here? is this the right place to = fix this? maybe as this is a PS while ND is going for DS, but fixing it = in ND might be more appropriate as that is where the problem is.=0D =0D thaler - that's true=0D =0D nordmark - redirects should take care of this. introducing = more-specifics makes this more complex.=0D =0D thaler - having two on-link routers that don't co-operate can be made to = work with this.=0D =0D wasserman - doesn't think this is reasonable text. agrees that routers = dumping tables to hosts is obviously brain-dead, but this doesn't seem = like it makes sense.=0D =0D thaler - clarifies=0D =0D wasserman - this still seems over-constrained. why MUST routers have = this level of state complexity?=0D =0D thaler - zinin said that not doing route-damping in this scenrio is a = 'recipe for disaster'=0D =0D savola - operationally this damping-feature is not called for. not = typically implemented in IGPs. doesn't see the use here. does see the = benefit of only advertising a prefix if link is up.=0D =0D nordmark - two routers on link that don't co-operate is a scenario where = this doesn't help, so what are we really solving with this.=0D =0D arturo azcorra - involved in research project working on home-gateways. = thinks home gateway will typically have capabilities for routing, = security=0D =0D savola - what about damping?=0D =0D azcorra - don't know=0D =0D hinden - being a backup or master tied to state of uplink is = well-understood concept and there is lots of experience about that. = doesn't want to tie this to route-damping. if you're going to do this, = make sure it's stable - a general statement would help here, but the = proposed text is too prescriptive.=0D =0D pascal thubert - does MAY correspond to point 1 and point 2? point 2 = explicity excludes some potentially useful functionality.=0D =0D krishnan - this only usefully applies to home gateways, so don't need = damping=0D =0D savola - could be two home routers, then it might be useful. operational = status of link only goes so far.=0D =0D thaler - this is the 'better than nothing' case. authors have no = preference. sounds like there is rough consensus to keep the first = sentence, change point1 to SHOULD and remove point2.=0D =0D no objections=0D =0D - Multi6 Update Nordmark 20 Minutes=0D - Progress update=0D =0D WG is at:=0D identify proposals for further development - recharter=0D =0D soliman - have there been any discussions about failure discovery and = propagating that to the site=0D nordmark - there is a draft that talks about how to detect working path. = ipv6 transport protocols to give positive advice to L3 probes. also = link-layer indicators. there isn't anything about routers telling hosts = that prefixes aren't working.=0D =0D itojun - is the Design Team aware that the L3 shim is basically a = host-based NAT?=0D =0D nordmark - there have been exchanges about this on the multi6 list. = depends what you mean by NAT. this is 1:1 mapping across whole system, = which is not what NAT does. =0D =0D hinden - clarification - so IPsec would work?=0D =0D nordmark - yes=0D =0D itojun - presentation at app area meeting is required because you have = broken something at L3?=0D =0D nordmark - no, the issue is that if apps today are doing caching or = referalls then they won't get benefit of the existence of multiple other = locators. so apps need to switch to using FQDN or keep track of full = list of IP locators - this is the message that apps area needs to hear.=0D= =0D hinden - this is really cool stuff, good job. in last slide, this = provides multihoming to small sites that would never run BGP. People who = run BGP have a solution today. don't lose the benefits for small sites = by focussing on large sites.=0D =0D nordmark - issue is middle-ground where providing some policy tweaks = might reduce pressure for small sites to go to the BGP solution. is = there something easy that can be done to widen applicability.=0D =0D savola - of course small v4 sites solution is to use NAT.=0D =0D huston - BGP is BGP. the issue about why do it this way as distinct from = the way it is done with IPv4 is related to fundamental considerations = about the scalability of BGP. BGP won't handle the load if multihoming = for small sites gets popular.=0D =0D soliman - do you need this if you have mobileipv6?=0D =0D nordmark - interactions with mobility have to be considered. =0D =0D jason schiller - need a mechanism for doing multihoming for small orgs.=0D= =0D hinden - does this have characteristic that people who deploy it get to = be multihomed, or does it require other people to play ball too?=0D =0D nordmark - peers don't have to be multihomed, but have to implement = protocol to produce multihoming benefits. has been suggested that for = transition reasons a proxy might be a nice way to go, but that proxy = turns out to have nat-like characteristics.=0D =0D bagnulo - need to upgrade both hosts to preserve established = communications through outages, but there are other problems that are = solved without needing to upgrade peers. =0D nordmark - You're right. One can get multihoming benefits while the = communication is established without requiring the peer to implement the = protocol. But if you want the multihoming benefit for established = connections, both ends need to implement the protocol. =0D carpenter - full benefits needs both hosts to have code in their stacks, = but there is no flag-day. deployment is 'creeping'. conscious choice not = to solve mobility problem in multi6 - keen to keep these two problems = orthogonal.=0D =0D pascal hubert - could this replace nemo or mip route optimisation? = doesn't know, but both groups should keep track of what each other are = doing going forward. route-projection concept may be useful for multi6 = for example. lot of synergies to be gained, even if requirements are not = shared.=0D =0D =0D =0D - Address Selection for multihoming Matsumoto 10 Minutes=0D - Goal: Informational=0D - draft-arifumi-multi6-sas-policy-dist-00.txt=0D =0D same slides as were presented to multi6 mtg yesterday.=0D =0D thaler - src and dst come from common prefix. RFC3484 rule number 7? = says prefer longest-prefix match. don't see any other rule to override = that, so you'd get the desired behaviour already. these examples don't = seem to require this mechanism.=0D =0D hain - the issue is where end node is talking with someone *beyond* ISP = B. these examples don't show that.=0D =0D droms - initial example also needs prefix C added to WGP-A network that = has no more bits in common to prefixes A and B.=0D =0D thaler - right, but router selection draft also deals with this. =0D =0D droms - there are cases where the router selection draft isn't enough=0D =0D soliman - even if you construct a case where router selection draft = isn't enough, it doesn't seem practical. please come back with a = practical example.=0D =0D hain - case 2 is already a practical example.=0D =0D soliman - why isn't router selection sufficient=0D =0D hain - this is a different approach to the same problem that may be = desirable in some circumstances=0D =0D thaler - agrees with hain that router selection can't help here.=0D =0D soliman - but if you configure routers correctly router selection does = work=0D =0D hain - 'correctly' is a relative term, if you have two provider = provisioned routers that you have no control over, they are configured = according to each providers definition of 'correct', that may not be = useful=0D =0D tatuya - be more specific about prefix C that causes the problem - this = will help to clarify the problem and the need for the solution=0D =0D thaler - agrees this is a problem. not convinced this is the best way to = solve it.=0D =0D hinden - chairs view is that this needs more consideration and = discussion before there is any need for WG to consider what to do.=0D =0D =0D =0D =0D - Anycast Analysis Chairs 10 Minutes=0D - Goal: determine direction of the work=0D - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt=0D =0D basic problem is that there are disagreements on content of document in = IESG. chairs have discussed with ADs and asked them to return doc to WG = so that issues can be addressed. will go into 'AD-is-watching' state.=0D =0D also have another anycast BCP document that is being considered for = adoption by grow WG. this is dealing with IPv4 anycast BCP at the = moment. input on IPv6 anycast is appreciated.=0D =0D savola - it is useful to clarify somewhere that the role of anycast in = ipv6 specs may be slightly different than what people expect. but the = issue is that now that we have this document on 'shared-unicast', what = should the ipv6 wg be documenting? is it right to do this work here now = given that scope might change significantly?=0D =0D lindquist - this might be better in the grow WG - it's not IPv6 specific = - it's operational.=0D =0D haberman - need to decide this as a group - will have this discussion on = the mailing list after people have had time to digest work of itojun, = kurtis and new anycast mailing list.=0D =0D kitamura - is setting up anycast mailing list. issue is different from = current situation with anycast. don't care if itojun's work goes to BCP = in this WG or not - will start discussion anyway.=0D =0D hinden - another WG to focus on this may be a good idea=0D =0D lindquist - this is good work that needs to be done, wasn't trying to = prevent it being done.=0D --Apple-Mail-2--171718282-- --Apple-Mail-3--171718100 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjEwMTQzODUzWjAjBgkqhkiG9w0B CQQxFgQU3im573mxDNxvIbFzlzRV9CsfLGYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAtOMCrEiF3RtPfJ/viTM/FtDnMAKA6BGYjuTJFNeE3ao5EcoA01wlNc6Jwc3nvMYp87Ky eHf783FZMy7MAXWTyyawhi/XSklfS3E1olJg1Ka/vqKvBLQZpRSWbIAriZT6x1bl4Wwb4LuGAeof xJyBnQ9AsuSzNnm58mdjYW9AsFNtPOvupsQXKhItL0PTQg1wEMA6d0zoRRMtAb30moZTVTCdgd8J 4JT5zftHYj4uJSjxGYJ7jTh5WuhbK5yk+OVWzDxYVEfuNmbgBi1YrRNeIVFAMhMyTX7Njo88DAdw SUYfzYH80viFVRShZs49GyhJscbEJ/kFs3VaLpjr53LrYQAAAAAAAA== --Apple-Mail-3--171718100-- --===============1760960649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1760960649==-- From ipv6-bounces@ietf.org Fri Dec 10 15:01:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11618 for ; Fri, 10 Dec 2004 15:01:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccr43-0004AJ-Ak for ipv6-web-archive@ietf.org; Fri, 10 Dec 2004 15:08:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccqnz-0004lr-U1; Fri, 10 Dec 2004 14:51:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccqg9-0003er-Q9 for ipv6@megatron.ietf.org; Fri, 10 Dec 2004 14:43:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10118 for ; Fri, 10 Dec 2004 14:43:48 -0500 (EST) Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcqnN-0003hP-V8 for ipv6@ietf.org; Fri, 10 Dec 2004 14:51:19 -0500 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9BF881A4F; Fri, 10 Dec 2004 14:43:14 -0500 (EST) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 6EDAA2725; Fri, 10 Dec 2004 14:43:14 -0500 (EST) Received: from galen.zko.hp.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id iBAJhDl0002280640; Fri, 10 Dec 2004 14:43:13 -0500 (EST) From: Vlad Yasevich To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Organization: Linux and Open Source Lab Date: Fri, 10 Dec 2004 14:43:13 -0500 Message-Id: <1102707793.927.41.camel@galen.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] a minor nit in creation of global addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Hi Jinmei I am not sure I very much like the statement:=20 " and the address is not yet in the list" This requires an implementation of Stateless Autoconfig to keep track of all addresses assigned to an interface (even statically assigned ones) and not just prefixes from which an address is formed. This seems like a new requirement on Stateless Autoconfig. The "Note" is fine to have, plus implementations should be able to deal correctly with trying to configure the same address twice. -vlad On Thu, 2004-12-09 at 18:40 +0900, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: > So, I'd like to propose to revise the last paragraph of bullet (d) of > Section 5.5.3 from: >=20 > If an address is formed successfully, the host adds it to the lis= t > of addresses assigned to the interface, initializing its preferre= d > and valid lifetime values from the Prefix Information option. >=20 > to: >=20 > If an address is formed successfully and the address is not yet i= n > the list, the host adds it to the list of addresses assigned to > the interface, initializing its preferred and valid lifetime > values from the Prefix Information option. Note that the check > against the prefix performed at the beginning of this step cannot > always detect the address conflict in the list. It could be > possible that an address already in the list, configured either > manually or by DHCPv6, happens to be identical to the newly > created address whereas such a case should be atypical. >=20 > Comments? >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 12 00:07:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15249 for ; Sun, 12 Dec 2004 00:07:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdM4i-0002GX-M5 for ipv6-web-archive@ietf.org; Sun, 12 Dec 2004 00:15:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdLuW-0007gY-0e; Sun, 12 Dec 2004 00:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdLrD-000742-LS for ipv6@megatron.ietf.org; Sun, 12 Dec 2004 00:01:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14835 for ; Sun, 12 Dec 2004 00:01:16 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdLyh-0002A8-PN for ipv6@ietf.org; Sun, 12 Dec 2004 00:09:07 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 3318F3B7 for ; Sun, 12 Dec 2004 00:00:34 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 12 Dec 2004 00:00:34 -0500 Message-Id: <20041212050034.3318F3B7@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.67% | 11 | 14.87% | 62001 | brc@zurich.ibm.com 5.33% | 4 | 12.76% | 53208 | brian@innovationslab.net 6.67% | 5 | 9.83% | 40979 | mark_andrews@isc.org 6.67% | 5 | 5.16% | 21527 | bmanning@karoshi.com 6.67% | 5 | 4.21% | 17567 | fenner@research.att.com 5.33% | 4 | 4.57% | 19065 | j.schoenwaelder@iu-bremen.de 5.33% | 4 | 4.16% | 17359 | jinmei@isl.rdc.toshiba.co.jp 5.33% | 4 | 4.10% | 17090 | demizu@dd.iij4u.or.jp 4.00% | 3 | 4.27% | 17782 | margaret@thingmagic.com 4.00% | 3 | 4.08% | 17021 | dts@senie.com 4.00% | 3 | 3.45% | 14383 | alain.durand@sun.com 2.67% | 2 | 3.29% | 13721 | stephen@sprunk.org 2.67% | 2 | 2.82% | 11758 | bmanning@vacation.karoshi.com 2.67% | 2 | 2.48% | 10343 | bob.hinden@nokia.com 2.67% | 2 | 2.08% | 8660 | iesg-secretary@ietf.org 2.67% | 2 | 1.85% | 7719 | tjc@ecs.soton.ac.uk 2.67% | 2 | 1.67% | 6943 | onoe@sm.sony.co.jp 2.67% | 2 | 1.45% | 6050 | sob@harvard.edu 1.33% | 1 | 1.61% | 6723 | syam@samsung.com 1.33% | 1 | 1.55% | 6447 | albert.e.manfredi@boeing.com 1.33% | 1 | 1.49% | 6215 | internet-drafts@ietf.org 1.33% | 1 | 1.46% | 6085 | steve.dalberg@hp.com 1.33% | 1 | 1.29% | 5388 | kck@netcom.com 1.33% | 1 | 1.25% | 5215 | vladislav.yasevich@hp.com 1.33% | 1 | 1.16% | 4818 | nwnetworks@dial.pipex.com 1.33% | 1 | 1.06% | 4423 | sra+ipng@hactrn.net 1.33% | 1 | 1.06% | 4411 | h.soliman@flarion.com 1.33% | 1 | 0.96% | 3992 | erik.nordmark@sun.com --------+------+--------+----------+------------------------ 100.00% | 75 |100.00% | 416893 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 13 04:42:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16228 for ; Mon, 13 Dec 2004 04:42:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdmqk-0000CJ-SL for ipv6-web-archive@ietf.org; Mon, 13 Dec 2004 04:50:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdmd2-000098-Kr; Mon, 13 Dec 2004 04:36:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmUF-0004rH-O3 for ipv6@megatron.ietf.org; Mon, 13 Dec 2004 04:27:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15039 for ; Mon, 13 Dec 2004 04:27:21 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdmbx-0008K6-Rc for ipv6@ietf.org; Mon, 13 Dec 2004 04:35:26 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4EE7D15210; Mon, 13 Dec 2004 18:26:50 +0900 (JST) Date: Mon, 13 Dec 2004 18:27:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vlad Yasevich In-Reply-To: <1102707793.927.41.camel@galen.zko.hp.com> References: <1102707793.927.41.camel@galen.zko.hp.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] a minor nit in creation of global addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 >>>>> On Fri, 10 Dec 2004 14:43:13 -0500, >>>>> Vlad Yasevich said: > I am not sure I very much like the statement: > " and the address is not yet in the list" > This requires an implementation of Stateless Autoconfig > to keep track of all addresses assigned to an interface > (even statically assigned ones) and not just prefixes > from which an address is formed. This seems like a new > requirement on Stateless Autoconfig. But RFC2462 already required that a host maintain a list of addresses containing both autoconfigured and manually-configured addresses: A host also maintains a list of addresses together with their corresponding lifetimes. The address list contains both autoconfigured addresses and those configured manually. So, I don't think this is a new requirement. Additionally, RFC2462 noted that host configuration variables were "conceptual" ones and the actual implementation could be different. In that sense, the host implementation does not have to implement the additional note in rfc2462bis using a "list" data structure. (rfc2462bis will remove the note on the "conceptual" nature due to clarification/simplification regarding host's variables, but I believe the main point here still applies and is pretty obvious without the explicit notice). Does this address your concern? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 13 08:11:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04622 for ; Mon, 13 Dec 2004 08:11:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdq6Y-00052g-Nm for ipv6-web-archive@ietf.org; Mon, 13 Dec 2004 08:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdpl1-00067T-RA; Mon, 13 Dec 2004 07:56:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdpin-0005YP-9I for ipv6@megatron.ietf.org; Mon, 13 Dec 2004 07:54:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01541 for ; Mon, 13 Dec 2004 07:54:36 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdpqa-0004VO-Jd for ipv6@ietf.org; Mon, 13 Dec 2004 08:02:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2004 06:00:22 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from codc-mira-1.cisco.com (IDENT:mirapoint@codc-mira-1.cisco.com [192.122.173.20]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBDCrq5O017298 for ; Mon, 13 Dec 2004 04:54:00 -0800 (PST) Received: from cisco.com ([10.77.202.217]) by codc-mira-1.cisco.com (MOS 3.4.6-GR) with ESMTP id AGP57501; Mon, 13 Dec 2004 18:23:36 +0530 (IST) Message-ID: <41BD90A4.1080100@cisco.com> Date: Mon, 13 Dec 2004 18:22:52 +0530 From: Nilesh Simaria User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: IPv6 neighbor table entry states X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Hi, Every entry of IPv6 neighbor table will be having a state associated with it like, PROBE, RECH, STALE, etc. Can some one explain me or point me to the doc which clearly explain the State Diagram [Transition of states and all possible events that cause the transition]. Thanks and Regards, Nilesh -- Unix is simple, but it takes genius to understand the simplicity. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 13 11:25:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24745 for ; Mon, 13 Dec 2004 11:25:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdt8y-0002Ac-F4 for ipv6-web-archive@ietf.org; Mon, 13 Dec 2004 11:33:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdsv2-0001ej-Cx; Mon, 13 Dec 2004 11:19:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdshW-00065r-B5 for ipv6@megatron.ietf.org; Mon, 13 Dec 2004 11:05:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22926 for ; Mon, 13 Dec 2004 11:05:28 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdspL-0001fo-9Y for ipv6@ietf.org; Mon, 13 Dec 2004 11:13:36 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iBDG5Rdv027516 for ; Mon, 13 Dec 2004 09:05:27 -0700 (MST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I8O00G014LZVF@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for ipv6@ietf.org; Mon, 13 Dec 2004 11:05:26 -0500 (EST) Received: from 129.148.174.103 (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I8O008CP4P28Q@bur-mail2.east.sun.com>; Mon, 13 Dec 2004 11:05:26 -0500 (EST) Date: Mon, 13 Dec 2004 11:04:21 -0500 From: Sebastien Roy In-reply-to: <41BD90A4.1080100@cisco.com> To: Nilesh Simaria Message-id: <1102953861.20132.209.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Content-type: text/plain Content-transfer-encoding: 7BIT References: <41BD90A4.1080100@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: IPv6 neighbor table entry states X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7BIT On Mon, 2004-12-13 at 07:52, Nilesh Simaria wrote: > Every entry of IPv6 neighbor table will be having a state associated > with it like, PROBE, RECH, STALE, etc. > Can some one explain me or point me to the doc which clearly explain the > State Diagram [Transition of states > and all possible events that cause the transition]. RFC2461, Appendix C. -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 13 13:54:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08730 for ; Mon, 13 Dec 2004 13:54:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdvT7-0006H6-PO for ipv6-web-archive@ietf.org; Mon, 13 Dec 2004 14:02:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdvHU-0004ia-Q3; Mon, 13 Dec 2004 13:50:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdvCz-0003bN-LR for ipv6@megatron.ietf.org; Mon, 13 Dec 2004 13:46:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07825 for ; Mon, 13 Dec 2004 13:46:08 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdvKo-00063B-2I for ipv6@ietf.org; Mon, 13 Dec 2004 13:54:17 -0500 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel10.hp.com (Postfix) with ESMTP id 0047A112184; Mon, 13 Dec 2004 10:46:05 -0800 (PST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 2E10746B; Mon, 13 Dec 2004 10:46:04 -0800 (PST) Received: from galen.zko.hp.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id iBDIk3W0001803791; Mon, 13 Dec 2004 13:46:03 -0500 (EST) From: Vlad Yasevich To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: References: <1102707793.927.41.camel@galen.zko.hp.com> Content-Type: text/plain; charset=UTF-8 Organization: Linux and Open Source Lab Date: Mon, 13 Dec 2004 13:46:03 -0500 Message-Id: <1102963563.927.65.camel@galen.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] a minor nit in creation of global addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Jinmei On Mon, 2004-12-13 at 18:27 +0900, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: >=20 > Does this address your concern? Thanks you. Yes, this addresses my concern. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 13 16:04:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20072 for ; Mon, 13 Dec 2004 16:04:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdxUh-0001Jv-9Q for ipv6-web-archive@ietf.org; Mon, 13 Dec 2004 16:12:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdwxB-0004Lt-Hl; Mon, 13 Dec 2004 15:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdwtH-0001je-Jm; Mon, 13 Dec 2004 15:33:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16344; Mon, 13 Dec 2004 15:33:54 -0500 (EST) Message-Id: <200412132033.PAA16344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 13 Dec 2004 15:33:53 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ndproxy-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-00.txt Pages : 17 Date : 2004-12-13 Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-00.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-ipv6-ndproxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ndproxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-13145531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ndproxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ndproxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-13145531.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Dec 13 22:34:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24339 for ; Mon, 13 Dec 2004 22:34:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce3Zz-0002tX-3p for ipv6-web-archive@ietf.org; Mon, 13 Dec 2004 22:42:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce3Pb-0000Sj-Mp; Mon, 13 Dec 2004 22:31:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce3Nu-0000Dm-Rw for ipv6@megatron.ietf.org; Mon, 13 Dec 2004 22:29:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24158 for ; Mon, 13 Dec 2004 22:29:56 -0500 (EST) Received: from ns.64translator.com ([202.214.123.16] helo=mail.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce3Vq-0002oI-O9 for ipv6@ietf.org; Mon, 13 Dec 2004 22:38:11 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.11/8.12.6) with ESMTP id iBE3TQ1g072963 for ; Tue, 14 Dec 2004 12:29:26 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Received: from jp.yokogawa.com (fumi.local.ini.jp [10.21.254.6]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id iBE3TQEn052364 for ; Tue, 14 Dec 2004 12:29:26 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Message-ID: <41BE6041.1080303@jp.yokogawa.com> Date: Tue, 14 Dec 2004 12:38:41 +0900 From: Nobumichi Ozoe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Subject: [Reminder] 6th TAHI IPv6 Interoperability Test Event - 24 - 28 January 2005, Chiba, Japan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Dear All, This is a reminder that TAHI Projcet is organizing its 6th TAHI IPv6 Interoperability Test Event. The event will be held from 24th - 28th January 2005 at the Makuhari messe of Chiba Japan. Registration is avairable at: http://www.tahi.org/inop/6thinterop.html Deadline to register is 31 December 2004. !!! Early registration discount is untill 17 December 2004 !!! This time we will provide the following tests: o Conformance test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, NEMO Basic Support(MR), IKEv1, SNMP, MIB, SIP(terminal test), IPv6 Core Protocol, IPsec, MLDv1, Default Address Selection, Default Router Preference, RIPng, NAT-PT, 6to4 o Interoperability test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, NEMO Basic Support, SIP, IPv6 Core Protocol, IPsec, IKEv1/v2, Prefix Delegation, MLDv2 For more details, please visit our web site. * TAHI Project Home Page http://www.tahi.org/ * 6th TAHI IPv6 Interoperability Test Event Announce Page http://www.tahi.org/inop/6thinterop.html #I'm sorry if you have already received this mail. Regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 14 10:17:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07155 for ; Tue, 14 Dec 2004 10:17:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeEYF-0003xs-Nn for ipv6-web-archive@ietf.org; Tue, 14 Dec 2004 10:25:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeE6x-0008Pa-Ir; Tue, 14 Dec 2004 09:57:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeDvS-0003EJ-L7 for ipv6@megatron.ietf.org; Tue, 14 Dec 2004 09:45:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03110 for ; Tue, 14 Dec 2004 09:45:17 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeE3T-0002t9-1g for ipv6@ietf.org; Tue, 14 Dec 2004 09:53:36 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBEEiaS24540; Tue, 14 Dec 2004 16:44:37 +0200 Date: Tue, 14 Dec 2004 16:44:36 +0200 (EET) From: Pekka Savola To: H.Soliman@flarion.com In-Reply-To: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> Message-ID: References: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 On Mon, 1 Nov 2004, Brian Haberman wrote: > This begins a 2 week IPv6 working group last call on recycling: > > Title : Neighbor Discovery for IP version 6 (IPv6) > Author(s) : T. Narten, et al. > Filename : draft-ietf-ipv6-2461bis-01.txt > Pages : 86 > Date : 2004-10-29 > > at Draft Standard. Substantive comments should be directed to > the mailing list. Editorial comments can be sent to the document > editor. This last call will end on 11/15/2004. Sorry for being a _lot_ late, but this is a long document, and I didn't see other reviews.. so here goes. In short, this still needs at least one revision. Jinmei also had some O/M/DHCPv6 consistency issues which probably need to be addressed. There is some specification which I don't think has been implemented and should be removed unless anyone jumps up. There is a normative reference to addr-arch which is still PS, and this is not acceptable. substantial ----------- ==> this spec needs at least an IANA Considerations section, stating at least: 1) the allocation guidelines for ND option types/codes (Standards Action? IETF Consensus?) 2) that no IANA action is required for ICMPv6 types, beyond updating the ICMPv6 codepoints to refer to this RFC instead of RFC2461 in their registry. AdvValidLifetime The value to be placed in the Valid Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. Implementations MUST allow AdvValidLifetime to be specified in two ways: - a time that decrements in real time, that is, one that will result in a Lifetime of zero at the specified time in the future, or - a fixed time that stays the same in consecutive advertisements. ==> AFAIK, the first option has not been implemented; I've at least not seen in done. Therefore unless someone shows that there are two implementations of this, this must be removed. (The same for AdvPreferredLifetime, and a bit in section 6.2.7.) Note: Implementations can choose to process the on-link aspects of the prefixes separately from the address autoconfiguration aspects of the prefixes by, e.g., passing a copy of each valid Router Advertisement message to both an "on-link" and an "addrconf" function. Each function can then operate independently on the prefixes that have the appropriate flag set. ==> similar to above, has this been implemented ? Not a as big issue as above for me, because this is just an implementation note. A proxy MAY multicast Neighbor Advertisements when its link-layer address changes or when it is configured (by system management or other mechanisms) to proxy for an address. If there are multiple nodes that are providing proxy services for the same set of addresses the proxies SHOULD provide a mechanism that prevents multiple proxies from multicasting advertisements for any one address, in order to reduce the risk of excessive multicast traffic. ==> does anyone implement this SHOULD? Note that this does not give hints how to even go about doing that. If not, remove. NORMATIVE [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. ==>replace with 3513. However, there is one big problem here. addrarch is PS, while this is going for DS. DS cannot have normative ref to PS. It is not clear whether ADDR-ARCH can be put in as informative reference, the text seems to be relying on it pretty heavily. OK with me, but there may be problems.. [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999. ==> this is also PS and cannot be referred to normatively. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ==> this must be over at the normative refs semi-editorial -------------- Inbound load balancing - Nodes with replicated interfaces may want to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses. Load balancing is handled by allowing routers to omit the source link-layer address from Router Advertisement packets, [...] ==> this is conflicting. The first para discusses generic inbound load balancing, the second load balancing that applies only to routers w/ RAs. How do hosts perform inbound load balancing? Needs text tweaking.. Unlike in IPv4 Router Discovery the Router Advertisement messages do not contain a preference field. The preference field is not needed to handle routers of different "stability"; the Neighbor Unreachability Detection will detect dead routers and switch to a working one. ==> preference has been plugged back, though not for stability reasons. I'd suggest just removing this paragraph. Placing address resolution at the ICMP layer makes the protocol more media-independent than ARP and makes it possible to use standard IP authentication and security mechanisms as appropriate. ==> the latter part of this sentence is a bit questionable, as this probably referred to using IPsec. Still, there is a benefit of being able to use a single SEND mechanism for _all_ link types. Text tweaking needed. variable MTU - Neighbor Discovery allows routers to specify a MTU for the link, which all nodes then use. All nodes on a link must use the same MTU (or Maximum Receive Unit) in order for multicast to work properly. Otherwise when multicasting a sender, which can not know which nodes will receive the packet, could not determine a minimum packet size all receivers can process. ==> the last sentence is not 100% accurate. It's not MTU at stake, it's the receiver's MRU (for processing the packet) or last-hop router's MTU (for sending the packet on the last links). Might need minor text tweak. If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers use the MTU option to specify the maximum MTU value that is supported by all segments. ==> s/routers use/routers can be configured to use/ -- there is no magic to do this automatically.. 6.2.8. Link-local Address Change The link-local address on a router SHOULD change rarely, if ever. ==> this is an improper use of upper-caps. Just make it lowercase. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation and is outside the scope of this specification. ==> it might not hurt to discuss the potential pitfalls of this approach somewhere. For example, n case the link indications are shaky, or just hints, and there is a significant number of MNs on a link, this could result in an RS storm. - The Target Address is a "valid" unicast or anycast address assigned to the receiving interface [ADDRCONF], - The Target Address is a unicast address for which the node is offering proxy service, or - The Target Address is a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF]. [...] If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included, the Override flag SHOULD be set to zero. [...] ==> the middle bullet point appears to be inconsistent with the further specification. That is, shouldn't an anycast address also be acceptable (not that the node could tell it's anycast address :) If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. Otherwise, the receiving node performs the following steps: ==> "one of two" ? You do not specify or clearly refer to either one of these. Needs rewording. If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, processing becomes quite a bit more complex. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache. If the Override flag is set, both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: ==> AFAICS, you can remove 'both the Override flag is clear and' here, because the same result happens if the Override flag is set. A router MUST limit the rate at which Redirect messages are sent, in order to limit the bandwidth and processing costs incurred by the Redirect messages when the source does not correctly respond to the Redirects, or the source chooses to ignore unauthenticated Redirect messages. More details on the rate-limiting of ICMP error messages can be found in [ICMPv6]. ==> 'or the source chooses to ignore unauthenticated Redirect messages' smells quite a bit from a leftover of IPsec AH times. Reword? An example of denial of service attacks is that a node on the link that can send packets with an arbitrary IP source address can both advertise itself as a default router and also send "forged" Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes. ==> 'on-link' is not accurate. Using these mechanisms, you can't capture _all_ on-link traffic as that goes between the nodes. You can capture that e.g. by advertising more specifics in RAs, with NA/ND spoofing, etc., but the sentence does not seem to be 100% correct. o Removed the on-link assumption in section 5.2 ==> add an informational reference to draft-ietf-v6ops-onlinkassumption here, as that doc captures the reasoning for the change. editorial --------- link-layer address - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links and E.164 addresses for ISDN links. ==> please remove the ISDN E.164 example, that's too crufty to be here.. non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, but that does not support a native form of multicast or broadcast (e.g., X.25, ATM, frame relay, etc.). Note that all link types (including NBMA) are ==> kill the extra empty line. all-nodes multicast address - the link-local scope address to reach all nodes. FF02::1 ==> s/nodes./nodes,/, s/1/1./ -- the same with all-routers. A solicitation that passes the validity checks is called a "valid solicitation". ... An advertisement that passes the validity checks is called a "valid advertisement". ... A Neighbor Solicitation that passes the validity checks is called a "valid solicitation". ... A Neighbor Advertisements that passes the validity checks is called a "valid advertisement". ==> I'd rewrite these to be "valid router solicitation", "valid router advertisement", "valid neighbor solicitation", etc. 6.3.4. Processing Received Router Advertisements When multiple routers are present, the information advertised collectively by all routers may be a superset of the information contained in a single Router Advertisement. Moreover, information may also be obtained through other dynamic means, such as stateful autoconfiguration. Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently-received information is considered authoritative. ==> it might not hurt to add an explicit reference to section 6.2.7 on the consistency -- maybe even replacing the duplicate list here.. Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no need to delay again before sending the first Router Solicitation message. In some cases, the random delay MAY be omitted if necessary. [...] ==> please split this ridiculously long paragraph to at least two -- maybe before "In some cases,". interface should be used. Using the prompting packet's source address when possible insures that the recipient of the Neighbor Solicitation installs in its Neighbor Cache the IP address that is ==> s/insures/ensures/ [issuing redirects] - the router determines that a better first-hop node resides on the same link as the sending node for the Destination Address of the packet being forwarded, and ==> maybe s/determines/determines using unspecified mechanisms/ that this is out of scope of this spec. The trust model for redirects is the same as in IPv4. A redirect is accepted only if received from the same router that is currently being used for that destination. It is natural to trust the routers on the link. If a host has been redirected to another node (i.e., the destination is on-link) there is no way to prevent the target from issuing another redirect to some other destination. However, this exposure is no worse than it was; the target host, once subverted, could always act as a hidden router to forward traffic elsewhere. ==> add the empty line before the start of this paragraph ==> "than it was" --> what does this refer to ? On the other hand, many of the threats discussed in this section are less effective, or non-existent, on point-to-point links, or cellular links where hosts share links with one neighbor, i.e. the default router. ==> s/hosts share links with one/a host shares a link with only one/ ? [ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html ==> this should probably be replaced with RFC3232 ("Assigned Numbers: RFC 1700 is Replaced by an On-line Database"). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 14 10:30:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09321 for ; Tue, 14 Dec 2004 10:30:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeEl5-0004Ok-3V for ipv6-web-archive@ietf.org; Tue, 14 Dec 2004 10:38:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeERr-00016H-Oe; Tue, 14 Dec 2004 10:18:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeEEx-0002zA-IB for ipv6@megatron.ietf.org; Tue, 14 Dec 2004 10:05:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05266 for ; Tue, 14 Dec 2004 10:05:26 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeEMv-0003av-GL for ipv6@ietf.org; Tue, 14 Dec 2004 10:13:46 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.6606509; Tue, 14 Dec 2004 10:03:28 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <504A0BC4-4DE1-11D9-9E25-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Tue, 14 Dec 2004 10:03:29 -0500 X-Mailer: Apple Mail (2.619) X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Bob Hinden Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489500187==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============1489500187== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-175357889; protocol="application/pkcs7-signature" --Apple-Mail-2-175357889 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This starts a 2 week IPv6 working group last call on advancing: Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-00.txt Pages : 17 Date : 2004-12-13 as an Informational document. Substantive comments should be directed to the mailing list. Minor comments and editorial issues can be sent to the author. This last call will end on December 28, 2004. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-2-175357889 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjE0MTUwMzI5WjAjBgkqhkiG9w0B CQQxFgQUYptrQq8nviTg2n+QD9a3/jyGX+AweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEApEONuR+b2qaDT6jpcOZlKfMKpMDjZDsvayEnoC/ctNNHbiHUv3PWeXJuL0m1N5T+yvEi tlx2LquIFC1cVpXOw5lhSp0rVCWMywo7u71l/BFPpg2RQwF3/sFmxqhQWkqkhTXFFdkTtIVcqy2O c7UoJ4msap8jQkG6YSxmNOBA+M1Am6TQTI+8udJnuJmgr+lO8qVer8Q5wE6YM3yjdL3nctyZbu+2 0IvrQpYJAv55962e3JjdoQM6Ir4jn+PRZC50WRTtoYZWkxScdQDpplaHux56qJJz4qF+T9SLOWCc G8HXzTCb5EIbuRJ2yK8KBSEhdwMMsYZEAvryGo+XEEtTkQAAAAAAAA== --Apple-Mail-2-175357889-- --===============1489500187== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1489500187==-- From ipv6-bounces@ietf.org Tue Dec 14 13:34:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02213 for ; Tue, 14 Dec 2004 13:34:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeHdO-0001e9-U2 for ipv6-web-archive@ietf.org; Tue, 14 Dec 2004 13:42:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeHRB-00066c-0m; Tue, 14 Dec 2004 13:30:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeHML-00056w-3R for ipv6@megatron.ietf.org; Tue, 14 Dec 2004 13:25:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01402 for ; Tue, 14 Dec 2004 13:25:14 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeHUM-0001Ml-Hz for ipv6@ietf.org; Tue, 14 Dec 2004 13:33:37 -0500 Received: from mail pickup service by ftmailgfi.flariontech.com with Microsoft SMTPSVC; Tue, 14 Dec 2004 13:24:11 -0500 Received: from netcore.fi ([193.94.160.1]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Dec 2004 09:44:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBEEiaS24540; Tue, 14 Dec 2004 16:44:37 +0200 Date: Tue, 14 Dec 2004 16:44:36 +0200 (EET) From: Pekka Savola To: H.Soliman@flarion.com In-Reply-To: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> Message-ID: References: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Dec 2004 14:44:38.0704 (UTC) FILETIME=[70127B00:01C4E1EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 On Mon, 1 Nov 2004, Brian Haberman wrote: > This begins a 2 week IPv6 working group last call on recycling: > > Title : Neighbor Discovery for IP version 6 (IPv6) > Author(s) : T. Narten, et al. > Filename : draft-ietf-ipv6-2461bis-01.txt > Pages : 86 > Date : 2004-10-29 > > at Draft Standard. Substantive comments should be directed to > the mailing list. Editorial comments can be sent to the document > editor. This last call will end on 11/15/2004. Sorry for being a _lot_ late, but this is a long document, and I didn't see other reviews.. so here goes. In short, this still needs at least one revision. Jinmei also had some O/M/DHCPv6 consistency issues which probably need to be addressed. There is some specification which I don't think has been implemented and should be removed unless anyone jumps up. There is a normative reference to addr-arch which is still PS, and this is not acceptable. substantial ----------- ==> this spec needs at least an IANA Considerations section, stating at least: 1) the allocation guidelines for ND option types/codes (Standards Action? IETF Consensus?) 2) that no IANA action is required for ICMPv6 types, beyond updating the ICMPv6 codepoints to refer to this RFC instead of RFC2461 in their registry. AdvValidLifetime The value to be placed in the Valid Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. Implementations MUST allow AdvValidLifetime to be specified in two ways: - a time that decrements in real time, that is, one that will result in a Lifetime of zero at the specified time in the future, or - a fixed time that stays the same in consecutive advertisements. ==> AFAIK, the first option has not been implemented; I've at least not seen in done. Therefore unless someone shows that there are two implementations of this, this must be removed. (The same for AdvPreferredLifetime, and a bit in section 6.2.7.) Note: Implementations can choose to process the on-link aspects of the prefixes separately from the address autoconfiguration aspects of the prefixes by, e.g., passing a copy of each valid Router Advertisement message to both an "on-link" and an "addrconf" function. Each function can then operate independently on the prefixes that have the appropriate flag set. ==> similar to above, has this been implemented ? Not a as big issue as above for me, because this is just an implementation note. A proxy MAY multicast Neighbor Advertisements when its link-layer address changes or when it is configured (by system management or other mechanisms) to proxy for an address. If there are multiple nodes that are providing proxy services for the same set of addresses the proxies SHOULD provide a mechanism that prevents multiple proxies from multicasting advertisements for any one address, in order to reduce the risk of excessive multicast traffic. ==> does anyone implement this SHOULD? Note that this does not give hints how to even go about doing that. If not, remove. NORMATIVE [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. ==>replace with 3513. However, there is one big problem here. addrarch is PS, while this is going for DS. DS cannot have normative ref to PS. It is not clear whether ADDR-ARCH can be put in as informative reference, the text seems to be relying on it pretty heavily. OK with me, but there may be problems.. [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999. ==> this is also PS and cannot be referred to normatively. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ==> this must be over at the normative refs semi-editorial -------------- Inbound load balancing - Nodes with replicated interfaces may want to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses. Load balancing is handled by allowing routers to omit the source link-layer address from Router Advertisement packets, [...] ==> this is conflicting. The first para discusses generic inbound load balancing, the second load balancing that applies only to routers w/ RAs. How do hosts perform inbound load balancing? Needs text tweaking.. Unlike in IPv4 Router Discovery the Router Advertisement messages do not contain a preference field. The preference field is not needed to handle routers of different "stability"; the Neighbor Unreachability Detection will detect dead routers and switch to a working one. ==> preference has been plugged back, though not for stability reasons. I'd suggest just removing this paragraph. Placing address resolution at the ICMP layer makes the protocol more media-independent than ARP and makes it possible to use standard IP authentication and security mechanisms as appropriate. ==> the latter part of this sentence is a bit questionable, as this probably referred to using IPsec. Still, there is a benefit of being able to use a single SEND mechanism for _all_ link types. Text tweaking needed. variable MTU - Neighbor Discovery allows routers to specify a MTU for the link, which all nodes then use. All nodes on a link must use the same MTU (or Maximum Receive Unit) in order for multicast to work properly. Otherwise when multicasting a sender, which can not know which nodes will receive the packet, could not determine a minimum packet size all receivers can process. ==> the last sentence is not 100% accurate. It's not MTU at stake, it's the receiver's MRU (for processing the packet) or last-hop router's MTU (for sending the packet on the last links). Might need minor text tweak. If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers use the MTU option to specify the maximum MTU value that is supported by all segments. ==> s/routers use/routers can be configured to use/ -- there is no magic to do this automatically.. 6.2.8. Link-local Address Change The link-local address on a router SHOULD change rarely, if ever. ==> this is an improper use of upper-caps. Just make it lowercase. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation and is outside the scope of this specification. ==> it might not hurt to discuss the potential pitfalls of this approach somewhere. For example, n case the link indications are shaky, or just hints, and there is a significant number of MNs on a link, this could result in an RS storm. - The Target Address is a "valid" unicast or anycast address assigned to the receiving interface [ADDRCONF], - The Target Address is a unicast address for which the node is offering proxy service, or - The Target Address is a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF]. [...] If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included, the Override flag SHOULD be set to zero. [...] ==> the middle bullet point appears to be inconsistent with the further specification. That is, shouldn't an anycast address also be acceptable (not that the node could tell it's anycast address :) If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. Otherwise, the receiving node performs the following steps: ==> "one of two" ? You do not specify or clearly refer to either one of these. Needs rewording. If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, processing becomes quite a bit more complex. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache. If the Override flag is set, both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: ==> AFAICS, you can remove 'both the Override flag is clear and' here, because the same result happens if the Override flag is set. A router MUST limit the rate at which Redirect messages are sent, in order to limit the bandwidth and processing costs incurred by the Redirect messages when the source does not correctly respond to the Redirects, or the source chooses to ignore unauthenticated Redirect messages. More details on the rate-limiting of ICMP error messages can be found in [ICMPv6]. ==> 'or the source chooses to ignore unauthenticated Redirect messages' smells quite a bit from a leftover of IPsec AH times. Reword? An example of denial of service attacks is that a node on the link that can send packets with an arbitrary IP source address can both advertise itself as a default router and also send "forged" Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes. ==> 'on-link' is not accurate. Using these mechanisms, you can't capture _all_ on-link traffic as that goes between the nodes. You can capture that e.g. by advertising more specifics in RAs, with NA/ND spoofing, etc., but the sentence does not seem to be 100% correct. o Removed the on-link assumption in section 5.2 ==> add an informational reference to draft-ietf-v6ops-onlinkassumption here, as that doc captures the reasoning for the change. editorial --------- link-layer address - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links and E.164 addresses for ISDN links. ==> please remove the ISDN E.164 example, that's too crufty to be here.. non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, but that does not support a native form of multicast or broadcast (e.g., X.25, ATM, frame relay, etc.). Note that all link types (including NBMA) are ==> kill the extra empty line. all-nodes multicast address - the link-local scope address to reach all nodes. FF02::1 ==> s/nodes./nodes,/, s/1/1./ -- the same with all-routers. A solicitation that passes the validity checks is called a "valid solicitation". .. An advertisement that passes the validity checks is called a "valid advertisement". .. A Neighbor Solicitation that passes the validity checks is called a "valid solicitation". .. A Neighbor Advertisements that passes the validity checks is called a "valid advertisement". ==> I'd rewrite these to be "valid router solicitation", "valid router advertisement", "valid neighbor solicitation", etc. 6.3.4. Processing Received Router Advertisements When multiple routers are present, the information advertised collectively by all routers may be a superset of the information contained in a single Router Advertisement. Moreover, information may also be obtained through other dynamic means, such as stateful autoconfiguration. Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently-received information is considered authoritative. ==> it might not hurt to add an explicit reference to section 6.2.7 on the consistency -- maybe even replacing the duplicate list here.. Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no need to delay again before sending the first Router Solicitation message. In some cases, the random delay MAY be omitted if necessary. [...] ==> please split this ridiculously long paragraph to at least two -- maybe before "In some cases,". interface should be used. Using the prompting packet's source address when possible insures that the recipient of the Neighbor Solicitation installs in its Neighbor Cache the IP address that is ==> s/insures/ensures/ [issuing redirects] - the router determines that a better first-hop node resides on the same link as the sending node for the Destination Address of the packet being forwarded, and ==> maybe s/determines/determines using unspecified mechanisms/ that this is out of scope of this spec. The trust model for redirects is the same as in IPv4. A redirect is accepted only if received from the same router that is currently being used for that destination. It is natural to trust the routers on the link. If a host has been redirected to another node (i.e., the destination is on-link) there is no way to prevent the target from issuing another redirect to some other destination. However, this exposure is no worse than it was; the target host, once subverted, could always act as a hidden router to forward traffic elsewhere. ==> add the empty line before the start of this paragraph ==> "than it was" --> what does this refer to ? On the other hand, many of the threats discussed in this section are less effective, or non-existent, on point-to-point links, or cellular links where hosts share links with one neighbor, i.e. the default router. ==> s/hosts share links with one/a host shares a link with only one/ ? [ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html ==> this should probably be replaced with RFC3232 ("Assigned Numbers: RFC 1700 is Replaced by an On-line Database"). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 15 03:50:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12381 for ; Wed, 15 Dec 2004 03:50:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeUzk-00079j-NT for ipv6-web-archive@ietf.org; Wed, 15 Dec 2004 03:58:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeUmp-0004yl-QL; Wed, 15 Dec 2004 03:45:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeUiC-00046q-Q3 for ipv6@megatron.ietf.org; Wed, 15 Dec 2004 03:40:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11837 for ; Wed, 15 Dec 2004 03:40:42 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeUqN-0006wr-QG for ipv6@ietf.org; Wed, 15 Dec 2004 03:49:12 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBF8e6419546; Wed, 15 Dec 2004 10:40:06 +0200 Date: Wed, 15 Dec 2004 10:40:06 +0200 (EET) From: Pekka Savola To: H.Soliman@flarion.com In-Reply-To: Message-ID: References: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On Tue, 14 Dec 2004, Pekka Savola wrote: > In short, this still needs at least one revision. Jinmei also had some > O/M/DHCPv6 consistency issues which probably need to be addressed. There is > some specification which I don't think has been implemented and should be > removed unless anyone jumps up. There is a normative reference to addr-arch > which is still PS, and this is not acceptable. I went through one implementation and have a couple of additional comments wrt suitability for DS/clarify. 1) section 6.2.5: when AdvSendAdvertisements changes to FALSE, you SHOULD send a final RA with zero Router Lifetime. At least a couple of implementations do send out final RAs with zero lifetime when the RA process is killed, but do not have 'state' which monitors whether AdvSendAdvertisements gets disabled or not on an interface. (e.g., at HUP signal) Are there implementations of this? 2) section 6.2.5: if system management disables IP forwarding, subsequent RAs MUST set the Router Lifetime to zero. I've seen no one implementing this (though many implement checks whent the RA process starts up). This either requires polling forwarding status constantly, or providing some kind of notifications when IP forwarding changes from on to off. Implementations? 3) section 6.2.7: RA consistency says like: - Cur Hop Limit values (except for the unspecified value of zero). It is ambiguous what the ()'s means. A couple of possibilities: a) if "my Cur Hop Limit" is zero, ignore consistency completely b) if "my Cur Hop Limit" is zero, allow the others to have zero Cur Hop Limit, otherwise it's inconsistent c) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur Hop Limit, otherwise it's inconsistent d) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur Hop Limit or zero, otherwise it's inconsistent This needs to be clarified. 4) section 6.2.8: if the link-local address of the router changes, it should multicast a few RAs from the old address with zero router lifetime, and a few from the new address. (SHOULD). I haven't seen this implemented. Similar reasons as 2). Anyone ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 15 04:34:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15280 for ; Wed, 15 Dec 2004 04:34:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeVgG-0008O4-E4 for ipv6-web-archive@ietf.org; Wed, 15 Dec 2004 04:42:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeVRK-0003ZV-Sa; Wed, 15 Dec 2004 04:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeVKL-00022W-AZ for ipv6@megatron.ietf.org; Wed, 15 Dec 2004 04:20:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14241 for ; Wed, 15 Dec 2004 04:20:06 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeVSV-000818-AN for ipv6@ietf.org; Wed, 15 Dec 2004 04:28:37 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iBF9JZpN212350 for ; Wed, 15 Dec 2004 09:19:35 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBF9Jo3L038700 for ; Wed, 15 Dec 2004 09:19:51 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iBF9JYqa023697 for ; Wed, 15 Dec 2004 09:19:34 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iBF9JYdu023684 for ; Wed, 15 Dec 2004 09:19:34 GMT Received: from zurich.ibm.com (sig-9-145-132-186.de.ibm.com [9.145.132.186]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA54428 for ; Wed, 15 Dec 2004 10:19:33 +0100 Message-ID: <41C001A5.8040008@zurich.ibm.com> Date: Wed, 15 Dec 2004 10:19:33 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 References: <200412142057.PAA16803@ietf.org> In-Reply-To: <200412142057.PAA16803@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit > [4] FEA0::/10 was previously defined as a Site-Local scoped address > prefix. This definition has been deprecated as of September 2004 > [RFC3879]. > I think that's a typo for FEC0::/10 As soon as the ULA draft is approved, FC00::/7 can also be marked as Reserved by IETF. IANA's authority was conferred by RFC 1881, and maybe that should be mentioned. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 15 07:03:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24221 for ; Wed, 15 Dec 2004 07:03:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeY0K-0003PJ-8p for ipv6-web-archive@ietf.org; Wed, 15 Dec 2004 07:11:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeXp0-0006Al-BV; Wed, 15 Dec 2004 06:59:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeXj5-0004sz-FX for ipv6@megatron.ietf.org; Wed, 15 Dec 2004 06:53:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23151 for ; Wed, 15 Dec 2004 06:53:48 -0500 (EST) From: matthew.ford@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeXrI-00034I-VI for ipv6@ietf.org; Wed, 15 Dec 2004 07:02:21 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 15 Dec 2004 11:54:32 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Dec 2004 11:54:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Dec 2004 11:54:27 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A700BE1999B@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: I-D ACTION:draft-huston-ip6-iana-registry-01.txt Thread-Index: AcTiiYa1hus+T0zFSVOibEaJnR/uMgAEp6yA To: , X-OriginalArrivalTime: 15 Dec 2004 11:54:28.0200 (UTC) FILETIME=[D48CF680:01C4E29C] X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable On , ipv6-bounces@ietf.org (mailto:ipv6-bounces@ietf.org) wrote: > As soon as the ULA draft is approved, FC00::/7 can also be marked as > Reserved by IETF.=20 I think it would make more sense, and would be in keeping with the proposed format of the registry if it was marked as 'Unique Local Unicast' under the 'Allocation' column, and the accompanying RFC noted under the 'Reference' column. Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 15 10:14:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06928 for ; Wed, 15 Dec 2004 10:14:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeazE-0008DC-7S for ipv6-web-archive@ietf.org; Wed, 15 Dec 2004 10:22:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceahy-0003vS-6F; Wed, 15 Dec 2004 10:04:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceaag-0003pt-2H for ipv6@megatron.ietf.org; Wed, 15 Dec 2004 09:57:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05458 for ; Wed, 15 Dec 2004 09:57:19 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ceair-0007it-U9 for ipv6@ietf.org; Wed, 15 Dec 2004 10:05:53 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.10779026; Wed, 15 Dec 2004 09:56:22 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <7C29583A-4EA9-11D9-A377-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Wed, 15 Dec 2004 09:56:22 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Bob Hinden Subject: Review request: draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489567617==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --===============1489567617== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-261330840; protocol="application/pkcs7-signature" --Apple-Mail-4-261330840 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The chairs would like to make everyone aware of the following draft: draft-huston-ip6-iana-registry-01.txt The draft sets forth some proposals for updating the IANA registry for IPv6 addresses. Currently, the registry does not align with the existing IPv4 address registry or RFC 3513. The authors request community review and comments. This draft was recently written by Geoff Huston with the assistance of Kurt Lindqvist, Thomas Narten, Paul Wilson, David Kessens, Bob Hinden and Brian Haberman. Thanks, Bob & Brian --Apple-Mail-4-261330840 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjE1MTQ1NjIyWjAjBgkqhkiG9w0B CQQxFgQU+IvzQz99JGivNWPVvx3QioHH2C0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAXuQe/vgsBoz8G4jct7YinlSo0bw7EnDvh7fHRcObGpL5M2OttvVEem1QbobK1X6WmtFd r+rHwJgoQ1ySGIhkbTPmk7neTLb7L2GnPrul7MCoiJJ2bcscOp7fkCQjp5ngbgUbYtN6itlYVp4E GXQIKJ0FMGbUd0AJVtpFUcvixheclkkMiivcQrqj+sTbA/1GwS34vVoKDmGJxFE+gmflli6LHzc/ rJuNiXFJ6NusntQ/Qxl30wzXoOK+3+G86w6k7Hfmo89JZMgA+b0e/yDqj1vq2Y095GEP+5TfkepG 3NlenYMo1pcIvo56GBbzfDVnMwSfodQDbp4R8bFlE3TPXwAAAAAAAA== --Apple-Mail-4-261330840-- --===============1489567617== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1489567617==-- From ipv6-bounces@ietf.org Wed Dec 15 14:21:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29835 for ; Wed, 15 Dec 2004 14:21:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeeqG-0007Bc-92 for ipv6-web-archive@ietf.org; Wed, 15 Dec 2004 14:29:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceeb1-0004rz-GA; Wed, 15 Dec 2004 14:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeeOV-0002zo-95 for ipv6@megatron.ietf.org; Wed, 15 Dec 2004 14:01:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28639 for ; Wed, 15 Dec 2004 14:01:01 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeeWk-0006hg-Vu for ipv6@ietf.org; Wed, 15 Dec 2004 14:09:36 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Dec 2004 11:00:37 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Dec 2004 11:00:29 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Dec 2004 11:00:28 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Wed, 15 Dec 2004 11:00:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Dec 2004 11:00:27 -0800 Message-ID: Thread-Topic: Review request: draft-huston-ip6-iana-registry-01.txt Thread-Index: AcTiuRBmLiEogAvSTs+5XdbrOukRMgAHmeBw From: "Christian Huitema" To: "Brian Haberman" , "IPv6 WG" X-OriginalArrivalTime: 15 Dec 2004 19:00:28.0636 (UTC) FILETIME=[57C1F9C0:01C4E2D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden Subject: RE: Review request: draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable > The chairs would like to make everyone aware of the following draft: >=20 > draft-huston-ip6-iana-registry-01.txt >=20 > The draft sets forth some proposals for updating the IANA registry > for IPv6 addresses. Currently, the registry does not align with > the existing IPv4 address registry or RFC 3513. The authors request > community review and comments. Minor comment: it would be nice if the first table used a notation like "0000::/8", "0800::/6" instead of the abbreviated notation (0::/8). This would make the map easier to grasp. Major comment: I can foresee several occasions where the IETF will want to allocate an unicast address prefix for a specific purpose. Some are fairly large event, allocating a large block, e.g. a /16 for 6to4, a /7 for ULA. The current registry management is adequate for these large allocations. But=20 some are very small events, allocating a /32 (e.g. for Teredo) or maybe a /48 (e.g. for various special services). Which part of the registry will we use for these small allocations? What is the procedure? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 16 02:34:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28874 for ; Thu, 16 Dec 2004 02:34:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeqIE-00018Y-IY for ipv6-web-archive@ietf.org; Thu, 16 Dec 2004 02:43:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceq5U-0002vI-O7; Thu, 16 Dec 2004 02:30:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceq2N-0001oK-K1 for ipv6@megatron.ietf.org; Thu, 16 Dec 2004 02:27:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28282 for ; Thu, 16 Dec 2004 02:26:57 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeqAj-0000yu-Is for ipv6@ietf.org; Thu, 16 Dec 2004 02:35:39 -0500 Received: from gihz1.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iBG7PwdX078035; Thu, 16 Dec 2004 18:26:09 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041216114804.02206af8@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 16 Dec 2004 11:52:33 +1100 To: "Christian Huitema" , "Brian Haberman" , "IPv6 WG" From: Geoff Huston In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.6 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Bob Hinden Subject: RE: Review request: draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b At 06:00 AM 16/12/2004, Christian Huitema wrote: > > The chairs would like to make everyone aware of the following draft: > > > > draft-huston-ip6-iana-registry-01.txt > > > The draft sets forth some proposals for updating the IANA registry > > for IPv6 addresses. Currently, the registry does not align with > > the existing IPv4 address registry or RFC 3513. The authors request > > community review and comments. > >Minor comment: it would be nice if the first table used a notation like >"0000::/8", "0800::/6" instead of the abbreviated notation (0::/8). This >would make the map easier to grasp. thanks for this - I'll make this alteration in the next version of the draft. >Major comment: I can foresee several occasions where the IETF will want >to allocate an unicast address prefix for a specific purpose. Some are >fairly large event, allocating a large block, e.g. a /16 for 6to4, a /7 >for ULA. The current registry management is adequate for these large >allocations. But >some are very small events, allocating a /32 (e.g. for Teredo) or maybe >a /48 (e.g. for various special services). Which part of the registry >will we use for these small allocations? What is the procedure? This particular draft does not look at the allocation procedures per se - but the intent of the draft would be to ensure that all IANA allocations are recorded in a uniform fashion in the registry in a format that is both clear and machine parseble. Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 16 02:38:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29175 for ; Thu, 16 Dec 2004 02:38:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeqLk-0001DS-Lr for ipv6-web-archive@ietf.org; Thu, 16 Dec 2004 02:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceq5Y-0002wt-ST; Thu, 16 Dec 2004 02:30:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceq2R-0001q3-Je for ipv6@megatron.ietf.org; Thu, 16 Dec 2004 02:27:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28292 for ; Thu, 16 Dec 2004 02:27:01 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeqAp-0000yy-2E for ipv6@ietf.org; Thu, 16 Dec 2004 02:35:43 -0500 Received: from gihz1.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iBG7PwdZ078035; Thu, 16 Dec 2004 18:26:23 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041216182513.021b6dd8@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 16 Dec 2004 18:25:53 +1100 To: matthew.ford@bt.com, , From: Geoff Huston In-Reply-To: <0AAF93247C75E3408638B965DEE11A700BE1999B@i2km41-ukdy.domai n1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A700BE1999B@i2km41-ukdy.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: RE: I-D ACTION:draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 10:54 PM 15/12/2004, matthew.ford@bt.com wrote: >On , ipv6-bounces@ietf.org (mailto:ipv6-bounces@ietf.org) wrote: > > > As soon as the ULA draft is approved, FC00::/7 can also be marked as > > Reserved by IETF. > >I think it would make more sense, and would be in keeping with the >proposed format of the registry if it was marked as 'Unique Local >Unicast' under the 'Allocation' column, and the accompanying RFC noted >under the 'Reference' column. This would be consistent with the intent of this draft --- once it is published as an RFC Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 16 03:44:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03469 for ; Thu, 16 Dec 2004 03:44:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CerNz-0002fA-6B for ipv6-web-archive@ietf.org; Thu, 16 Dec 2004 03:53:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cer7A-0000v7-SF; Thu, 16 Dec 2004 03:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cer4A-0000GQ-96 for ipv6@megatron.ietf.org; Thu, 16 Dec 2004 03:32:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02833 for ; Thu, 16 Dec 2004 03:32:51 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CerCO-0002OW-Af for ipv6@ietf.org; Thu, 16 Dec 2004 03:41:34 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 93F2E24098; Thu, 16 Dec 2004 09:32:29 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04810-04; Thu, 16 Dec 2004 09:32:27 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 8122B24093; Thu, 16 Dec 2004 09:32:23 +0100 (CET) From: Jeroen Massar To: Geoff Huston In-Reply-To: <6.0.1.1.2.20041216182513.021b6dd8@localhost> References: <0AAF93247C75E3408638B965DEE11A700BE1999B@i2km41-ukdy.domain1.systemhost.net> <6.0.1.1.2.20041216182513.021b6dd8@localhost> Organization: Unfix Date: Thu, 16 Dec 2004 09:30:56 +0100 Message-Id: <1103185856.20370.72.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ipv6@ietf.org Subject: RE: I-D ACTION:draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0390304290==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --===============0390304290== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nR+qBvvnKIzc56BR0HDr" --=-nR+qBvvnKIzc56BR0HDr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-12-16 at 18:25 +1100, Geoff Huston wrote: > At 10:54 PM 15/12/2004, matthew.ford@bt.com wrote: > >On , ipv6-bounces@ietf.org (mailto:ipv6-bounces@ietf.org) wrote: > > > > > As soon as the ULA draft is approved, FC00::/7 can also be marked as > > > Reserved by IETF. > > > >I think it would make more sense, and would be in keeping with the > >proposed format of the registry if it was marked as 'Unique Local > >Unicast' under the 'Allocation' column, and the accompanying RFC noted > >under the 'Reference' column. >=20 > This would be consistent with the intent of this draft --- once it is pub= lished > as an RFC Geoff, what is your opinion on asking IANA to publish this prefix list through their whois interface (whois.iana.net) which currently does serve some domains like .int. This would be useful for redirection purposes to the correct RIR or simply finding out the RFC to which space this belongs to ;) Greets, Jeroen --=-nR+qBvvnKIzc56BR0HDr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBwUfAKaooUjM+fCMRAkXbAJ9vnDrVgLAsIbouXnpFmZuSDAOoRgCgk1ih qWjg8bJlJUvfNOpeLefnewc= =zJGQ -----END PGP SIGNATURE----- --=-nR+qBvvnKIzc56BR0HDr-- --===============0390304290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0390304290==-- From ipv6-bounces@ietf.org Thu Dec 16 04:40:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06668 for ; Thu, 16 Dec 2004 04:40:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CesG8-0003z3-Qp for ipv6-web-archive@ietf.org; Thu, 16 Dec 2004 04:49:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ces0V-0001uo-1D; Thu, 16 Dec 2004 04:33:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cerv8-0000th-L5 for ipv6@megatron.ietf.org; Thu, 16 Dec 2004 04:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05941 for ; Thu, 16 Dec 2004 04:27:36 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ces3X-0003gz-Ag for ipv6@ietf.org; Thu, 16 Dec 2004 04:36:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBG9QgO19024; Thu, 16 Dec 2004 11:26:47 +0200 Date: Thu, 16 Dec 2004 11:26:42 +0200 (EET) From: Pekka Savola To: Jeroen Massar In-Reply-To: <1103185856.20370.72.camel@firenze.zurich.ibm.com> Message-ID: References: <0AAF93247C75E3408638B965DEE11A700BE1999B@i2km41-ukdy.domain1.systemhost.net> <6.0.1.1.2.20041216182513.021b6dd8@localhost> <1103185856.20370.72.camel@firenze.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org, Geoff Huston Subject: RE: I-D ACTION:draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, 16 Dec 2004, Jeroen Massar wrote: > Geoff, what is your opinion on asking IANA to publish this prefix list > through their whois interface (whois.iana.net) which currently does > serve some domains like .int. > > This would be useful for redirection purposes to the correct RIR or > simply finding out the RFC to which space this belongs to ;) This would probably be bad idea, because every script in the world would be changed to query from the IANA whois, and they would get swamped. I symphatize with this, but it would seem that it might significantly alter the IANA whois service requirements.. not something that can be done overnight. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 16 04:52:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07636 for ; Thu, 16 Dec 2004 04:52:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CesRk-0004Jv-E8 for ipv6-web-archive@ietf.org; Thu, 16 Dec 2004 05:01:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CesDt-0004Ek-6c; Thu, 16 Dec 2004 04:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ces8x-00030E-3w for ipv6@megatron.ietf.org; Thu, 16 Dec 2004 04:41:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06749 for ; Thu, 16 Dec 2004 04:41:52 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CesHK-00040F-Tj for ipv6@ietf.org; Thu, 16 Dec 2004 04:50:36 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 603AC24093; Thu, 16 Dec 2004 10:41:46 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07163-01; Thu, 16 Dec 2004 10:41:45 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id A7E7624098; Thu, 16 Dec 2004 10:41:16 +0100 (CET) From: Jeroen Massar To: Pekka Savola In-Reply-To: References: <0AAF93247C75E3408638B965DEE11A700BE1999B@i2km41-ukdy.domain1.systemhost.net> <6.0.1.1.2.20041216182513.021b6dd8@localhost> <1103185856.20370.72.camel@firenze.zurich.ibm.com> Organization: Unfix Date: Thu, 16 Dec 2004 10:41:15 +0100 Message-Id: <1103190075.20370.104.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-6) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org, Geoff Huston Subject: RE: I-D ACTION:draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0987744429==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --===============0987744429== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FcjyAulmutS1NgKSOmhJ" --=-FcjyAulmutS1NgKSOmhJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-12-16 at 11:26 +0200, Pekka Savola wrote: > On Thu, 16 Dec 2004, Jeroen Massar wrote: > > Geoff, what is your opinion on asking IANA to publish this prefix list > > through their whois interface (whois.iana.net) which currently does > > serve some domains like .int. > > > > This would be useful for redirection purposes to the correct RIR or > > simply finding out the RFC to which space this belongs to ;) >=20 > This would probably be bad idea, because every script in the world=20 > would be changed to query from the IANA whois, and they would get=20 > swamped. Every "script in the world" also queries whois.{apnic|arin|ripe| lacnic}.net now where is the difference with that. Also note that for instance geektools have their own whois server which does exactly what is proposed, but that is hardly an official source... Notez bien that whois clients are already too smart and could easily cache this information. > I symphatize with this, but it would seem that it might significantly=20 > alter the IANA whois service requirements.. not something that can be=20 > done overnight. For what reason do they then run a whois server for .int ? Nobody queries it ? :) Another way for a whois client to find out who it needs to query could of course also be to fetch http://www.iana.org/assignments/ipv6-address- space every time and parse it to find out where it needs to query... Otherwise what is the reason for standardizing the format using the proposed document!? ~400 bytes of whois output versus ~4kb of http traffic... Also it does not have to be done overnight, but somewhere along the lines of next year would be fine by me ;) Greets, Jeroen --=-FcjyAulmutS1NgKSOmhJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBwVg7KaooUjM+fCMRAsqkAJ9mNCzMMGAkeTtNHtao81c5CI3RjgCgrb4l 6EPh3s+V6OzQNDhhAygRiA0= =fKoe -----END PGP SIGNATURE----- --=-FcjyAulmutS1NgKSOmhJ-- --===============0987744429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0987744429==-- From ipv6-bounces@ietf.org Thu Dec 16 12:28:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15375 for ; Thu, 16 Dec 2004 12:28:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CezYb-0000VL-NR for ipv6-web-archive@ietf.org; Thu, 16 Dec 2004 12:36:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CezNF-0001Wm-U7; Thu, 16 Dec 2004 12:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CezGX-0008BN-Ar; Thu, 16 Dec 2004 12:18:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14513; Thu, 16 Dec 2004 12:18:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CezP0-0000CD-Q5; Thu, 16 Dec 2004 12:26:58 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Cez60-0003tO-GL; Thu, 16 Dec 2004 12:07:20 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 16 Dec 2004 12:07:20 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Last Call: 'Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification' to Draft Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification ' as a Draft Standard 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 2005-1-2. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-06.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 16 14:07:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26939 for ; Thu, 16 Dec 2004 14:07:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf16p-0004JU-AF for ipv6-web-archive@ietf.org; Thu, 16 Dec 2004 14:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf0tq-0005au-8j; Thu, 16 Dec 2004 14:02:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf0r7-0004rF-6L for ipv6@megatron.ietf.org; Thu, 16 Dec 2004 14:00:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25974 for ; Thu, 16 Dec 2004 14:00:03 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf0zZ-0003zw-Pg for ipv6@ietf.org; Thu, 16 Dec 2004 14:08:51 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iBGIUBH03150; Thu, 16 Dec 2004 10:30:11 -0800 X-mProtect: <200412161830> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd9eI0Yr; Thu, 16 Dec 2004 10:30:10 PST Message-Id: <6.1.2.0.2.20041216104638.0215c5f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 16 Dec 2004 10:57:22 -0800 To: Pekka Savola From: Bob Hinden In-Reply-To: References: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Pekka, At 12:40 AM 12/15/2004, Pekka Savola wrote: >On Tue, 14 Dec 2004, Pekka Savola wrote: >>In short, this still needs at least one revision. Jinmei also had some >>O/M/DHCPv6 consistency issues which probably need to be addressed. There >>is some specification which I don't think has been implemented and should >>be removed unless anyone jumps up. There is a normative reference to >>addr-arch which is still PS, and this is not acceptable. > >I went through one implementation and have a couple of additional comments >wrt suitability for DS/clarify. I think we need some feedback from the ADs here. RFC2461 is already at Draft standard. I don't think we need to do an extensive implementation review again (except, of course, if were adding new features). If we are all very sure that a feature isn't implemented, then I don't have any personal objections to removing it. As long as we are very sure. Likewise, the reference to the Address Architecture (currently at Proposed standard) existed in RFC2461, so it's not clear it is a problem. Getting the Address Arch to Draft standard is a good idea that we will try to make more progress on. Thanks, Bob >1) section 6.2.5: when AdvSendAdvertisements changes to FALSE, you SHOULD >send a final RA with zero Router Lifetime. > >At least a couple of implementations do send out final RAs with zero >lifetime when the RA process is killed, but do not have 'state' which >monitors whether AdvSendAdvertisements gets disabled or not on an >interface. (e.g., at HUP signal) > >Are there implementations of this? > >2) section 6.2.5: if system management disables IP forwarding, subsequent >RAs MUST set the Router Lifetime to zero. > >I've seen no one implementing this (though many implement checks whent the >RA process starts up). This either requires polling forwarding status >constantly, or providing some kind of notifications when IP forwarding >changes from on to off. Implementations? > >3) section 6.2.7: RA consistency says like: > - Cur Hop Limit values (except for the unspecified value of zero). > >It is ambiguous what the ()'s means. A couple of possibilities: > a) if "my Cur Hop Limit" is zero, ignore consistency completely > b) if "my Cur Hop Limit" is zero, allow the others to have zero Cur Hop > Limit, otherwise it's inconsistent > c) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur > Hop Limit, otherwise it's inconsistent > d) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur > Hop Limit or zero, otherwise it's inconsistent > >This needs to be clarified. > >4) section 6.2.8: if the link-local address of the router changes, it >should multicast a few RAs from the old address with zero router lifetime, >and a few from the new address. (SHOULD). > >I haven't seen this implemented. Similar reasons as 2). Anyone ? > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 17 18:51:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06985 for ; Fri, 17 Dec 2004 18:51:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfS1K-00067J-Sj for ipv6-web-archive@ietf.org; Fri, 17 Dec 2004 19:00:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfRnU-0001YL-Au; Fri, 17 Dec 2004 18:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfRlT-00085E-7q for ipv6@megatron.ietf.org; Fri, 17 Dec 2004 18:44:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06355 for ; Fri, 17 Dec 2004 18:44:00 -0500 (EST) Received: from bay20-f6.bay20.hotmail.com ([64.4.54.95] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfRu7-0005r1-T1 for ipv6@ietf.org; Fri, 17 Dec 2004 18:53:02 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 17 Dec 2004 15:42:00 -0800 Message-ID: Received: from 63.117.239.165 by by20fd.bay20.hotmail.msn.com with HTTP; Fri, 17 Dec 2004 23:41:34 GMT X-Originating-IP: [63.117.239.165] X-Originating-Email: [fredricklowery@hotmail.com] X-Sender: fredricklowery@hotmail.com From: "Rick LOWERY" To: ipv6@ietf.org Date: Fri, 17 Dec 2004 18:41:34 -0500 Mime-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2004 23:42:00.0679 (UTC) FILETIME=[0106AF70:01C4E492] X-Spam-Score: 1.7 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA06355 Subject: Question on Default Address Selection X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0010301134==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 --===============0010301134== Content-Type: text/html; format=flowed Content-Transfer-Encoding: quoted-printable

Hello,

 

I ran into a scenario where I was using 6to= 4 on a XP machine and it preferred the IPv4 address (A) over IPv6 AAAA re= cord for communication with sites that had both AAAA and A. I thought IPv= 6 was always supposed to be preferred over IPv4 when you have a valid glo= bal address.

When I connect with a tunnel broker (freene= t6) it prefers the AAAA over the A. I=92m hoping someone can help me furt= her understand this. I did do some research by reading RFC 3484, but I do= n=92t understand how to interrupt the below Prefix precedence list

 

Would someone please help me untangle how t= o interpret the below prefixes? I read in RFC 3484 that ::FFFF:0:0/96 mea= ns native IPv4, but I don=92t know how they derived that from ::FFFF:0:0/= 96<= /SPAN>

 

Thanks,

 

Rick

 

 

Precedence  Label  Prefix
----= ------  -----  --------------------------------
  =        5  p;    5&n= bsp; 3ffe:831f::/32
        10 = ;     4  ::ffff:0:0/96
   &nbs= p;    20      3  ::/96
&n= bsp;       30     = 2  2002::/16
        40 =      1  ::/0
     &n= bsp;  50      0  ::1/128

 

<= /html> --===============0010301134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0010301134==-- From ipv6-bounces@ietf.org Fri Dec 17 19:37:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10859 for ; Fri, 17 Dec 2004 19:37:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfSji-0007Xu-2D for ipv6-web-archive@ietf.org; Fri, 17 Dec 2004 19:46:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfSUX-0005N7-Qx; Fri, 17 Dec 2004 19:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfSRe-0004BB-Mz for ipv6@megatron.ietf.org; Fri, 17 Dec 2004 19:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09866 for ; Fri, 17 Dec 2004 19:27:35 -0500 (EST) Message-Id: <200412180027.TAA09866@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfSaN-0007Ez-R9 for ipv6@ietf.org; Fri, 17 Dec 2004 19:36:40 -0500 Received: from eaglet (127.0.0.1:3362) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 17 Dec 2004 16:24:09 -0800 From: "Tony Hain" To: "'Rick LOWERY'" , Date: Fri, 17 Dec 2004 16:27:32 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcTkkthj6molPG9sTeGzYgZjQ2SGKAABFgig In-Reply-To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Subject: RE: Question on Default Address Selection X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0707013829==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d This is a multi-part message in MIME format. --===============0707013829== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F5_01C4E455.4F456EC0" This is a multi-part message in MIME format. ------=_NextPart_000_03F5_01C4E455.4F456EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The best place to ask for product specific help is from the vendor. In = this case there is a news group set up specifically to deal with questions = like this: microsoft.public.platformsdk.networking.ipv6 (found off of ms.com/ipv6 support). =20 As far as interpreting ::FFFF:0:0 /96 as an IPv4 address, see RFC 3513 section 2.5.5 . The ::FFFF prefix identifies IPv4-only endpoints to IPv6 aware environments. =20 Tony=20 =20 _____ =20 From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Rick LOWERY Sent: Friday, December 17, 2004 3:42 PM To: ipv6@ietf.org Subject: Question on Default Address Selection =20 Hello, =20 I ran into a scenario where I was using 6to4 on a XP machine and it preferred the IPv4 address (A) over IPv6 AAAA record for communication = with sites that had both AAAA and A. I thought IPv6 was always supposed to be preferred over IPv4 when you have a valid global address. When I connect with a tunnel broker (freenet6) it prefers the AAAA over = the A. I=12m hoping someone can help me further understand this. I did do = some research by reading RFC 3484, but I don=12t understand how to interrupt = the below Prefix precedence list =20 Would someone please help me untangle how to interpret the below = prefixes? I read in RFC 3484 that ::FFFF:0:0/96 means native IPv4, but I don=12t = know how they derived that from ::FFFF:0:0/96 =20 Thanks, =20 Rick =20 =20 Precedence Label Prefix ---------- ----- -------------------------------- 5  p; 5 3ffe:831f::/32 10 4 ::ffff:0:0/96 20 3 ::/96 30 2 2002::/16 40 1 ::/0 50 0 ::1/128 =20 ------=_NextPart_000_03F5_01C4E455.4F456EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The best place to ask for product = specific help is from the vendor. In this case there is a news group set up = specifically to deal with questions like this: = microsoft.public.platformsdk.networking.ipv6  (found off of ms.com/ipv6  support).

 

As far as interpreting ::FFFF:0:0 = /96 as an IPv4 address, see RFC 3513 section 2.5.5 . The ::FFFF prefix = identifies IPv4-only endpoints to IPv6 aware = environments.

 

Tony

 

From: = ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf Of Rick LOWERY
Sent: Friday, December = 17, 2004 3:42 PM
To: ipv6@ietf.org
Subject: Question on = Default Address Selection

 

Hello,

 

I ran into a scenario where I was using 6to4 on a XP = machine and it preferred the IPv4 address (A) over IPv6 AAAA record for = communication with sites that had both AAAA and A. I thought IPv6 was always supposed = to be preferred over IPv4 when you have a valid global = address.

When I connect with a tunnel broker (freenet6) it = prefers the AAAA over the A. Im hoping someone can help me further = understand this. I did do some research by reading RFC 3484, but I dont = understand how to interrupt the below Prefix precedence = list

 

Would someone please help me untangle how to = interpret the below prefixes? I read in RFC 3484 that ::FFFF:0:0/96 means native IPv4, = but I dont know how they derived that from = ::FFFF:0:0/96

 

Thanks,

 

Rick

 

 

Precedence  Label  Prefix
----------  -----  --------------------------------
         5 &nbspp;    5  3ffe:831f::/32
        = 10      4  ::ffff:0:0/96
        = 20      3  ::/96
        = 30      2  2002::/16
        = 40      1  ::/0
        = 50      0  ::1/128

 

------=_NextPart_000_03F5_01C4E455.4F456EC0-- --===============0707013829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0707013829==-- From ipv6-bounces@ietf.org Sat Dec 18 13:35:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07759 for ; Sat, 18 Dec 2004 13:35:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfjZL-0000hD-Rz for ipv6-web-archive@ietf.org; Sat, 18 Dec 2004 13:44:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfjIL-0003jK-WF; Sat, 18 Dec 2004 13:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfjGd-0003Df-Sb for ipv6@megatron.ietf.org; Sat, 18 Dec 2004 13:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07175 for ; Sat, 18 Dec 2004 13:25:20 -0500 (EST) Received: from mail2.noc.n-bone.net ([138.243.50.142] helo=mail201.noc.n-bone.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfjPU-0000Ux-AJ for ipv6@ietf.org; Sat, 18 Dec 2004 13:34:35 -0500 Received: from NECPCuser (unknown [138.243.65.22]) by mail201.noc.n-bone.net (NBONE-MTA) with SMTP id 82941136E for ; Sun, 19 Dec 2004 03:24:47 +0900 (JST) Message-ID: <002f01c4e52f$3a4d8900$6e25150a@NECPCuser> From: "masuda yuko" To: Date: Sun, 19 Dec 2004 03:27:27 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: (no subject) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0801533092==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. --===============0801533092== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C4E57A.AA02D660" This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C4E57A.AA02D660 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit ------=_NextPart_000_002B_01C4E57A.AA02D660 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_002B_01C4E57A.AA02D660-- --===============0801533092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0801533092==-- From ipv6-bounces@ietf.org Sat Dec 18 13:39:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07981 for ; Sat, 18 Dec 2004 13:39:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cfjd5-0000mJ-4b for ipv6-web-archive@ietf.org; Sat, 18 Dec 2004 13:48:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfjIM-0003jR-Uz; Sat, 18 Dec 2004 13:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfjGd-0003Dg-Sb for ipv6@megatron.ietf.org; Sat, 18 Dec 2004 13:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07174 for ; Sat, 18 Dec 2004 13:25:20 -0500 (EST) Received: from mail2.noc.n-bone.net ([138.243.50.142] helo=mail201.noc.n-bone.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfjPU-0000Uj-9Z for ipv6@ietf.org; Sat, 18 Dec 2004 13:34:35 -0500 Received: from NECPCuser (unknown [138.243.65.22]) by mail201.noc.n-bone.net (NBONE-MTA) with SMTP id D988C1024 for ; Sun, 19 Dec 2004 03:24:38 +0900 (JST) Message-ID: <002501c4e52f$3531db60$6e25150a@NECPCuser> From: "masuda yuko" To: Date: Sun, 19 Dec 2004 03:27:18 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: (no subject) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0353021307==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. --===============0353021307== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C4E57A.A4BDF5E0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C4E57A.A4BDF5E0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0021_01C4E57A.A4BDF5E0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0021_01C4E57A.A4BDF5E0-- --===============0353021307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0353021307==-- From ipv6-bounces@ietf.org Sat Dec 18 15:33:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18549 for ; Sat, 18 Dec 2004 15:33:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CflPb-0003dO-4W for ipv6-web-archive@ietf.org; Sat, 18 Dec 2004 15:42:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cfl7t-0008U1-S0; Sat, 18 Dec 2004 15:24:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cfl6e-0007WM-N9 for ipv6@megatron.ietf.org; Sat, 18 Dec 2004 15:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17528 for ; Sat, 18 Dec 2004 15:23:10 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CflFY-0003LZ-Gw for ipv6@ietf.org; Sat, 18 Dec 2004 15:32:25 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 18 Dec 2004 15:22:40 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Dec 2004 15:22:39 -0500 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcTiCi1UE7VYs0reRM2rQYgYmWW4LQDMinWA From: "Soliman, Hesham" To: "Pekka Savola" X-OriginalArrivalTime: 18 Dec 2004 20:22:40.0449 (UTC) FILETIME=[52962B10:01C4E53F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06 Content-Transfer-Encoding: quoted-printable Pekka, Thanks for the comments.=20 My response inline. If I don't address a comment below, it means I have no problem updating the draft with the comment. Others please take a look and voice opinions if you have them. We should try to make this LC have a deadline :) > substantial > ----------- >=20 > =3D=3D> this spec needs at least an IANA Considerations section,=20 > stating at > least: > 1) the allocation guidelines for ND option types/codes=20 > (Standards Action?=20 > IETF Consensus?) > 2) that no IANA action is required for ICMPv6 types,=20 > beyond updating > the ICMPv6 codepoints to refer to this RFC instead of=20 > RFC2461 in their > registry. =3D> ok. I didn't think IANA sections had to be included but I'll add 2) above. >=20 > AdvValidLifetime > The value to be placed in the Valid > Lifetime in the Prefix Information > option, in seconds. The=20 > designated value > of all 1's (0xffffffff) represents > infinity. Implementations MUST allow > AdvValidLifetime to be specified in two > ways: >=20 > - a time that decrements in=20 > real time, > that is, one that will result in a > Lifetime of zero at the specified > time in the future, or >=20 > - a fixed time that stays the same in > consecutive advertisements. >=20 > =3D=3D> AFAIK, the first option has not been implemented; I've=20 > at least not seen > in done. Therefore unless someone shows that there are two=20 > implementations > of this, this must be removed. (The same for=20 > AdvPreferredLifetime, and a bit > in section 6.2.7.) =3D> There are three issues to consider:=20 1. The second option actually (evidently more implemented) seems strange. If the time is decremented, then why not reflect that in advertisements?=20 2. One could argue that this is an implementation issue. The=20 receiver will update the Valid Lifetime field each time it gets an adv. So does it matter if it's a different value each time or the same? 3. As Bob mentioned, this is already a DS and I'm not sure if we want to remove this now, especially if we don't know 100 % that it's not implemented.=20 >=20 > Note: Implementations can choose to process the=20 > on-link aspects of > the prefixes separately from the address=20 > autoconfiguration aspects > of the prefixes by, e.g., passing a copy of each valid Router > Advertisement message to both an "on-link" and an "addrconf" > function. Each function can then operate independently on the > prefixes that have the appropriate flag set. >=20 > =3D=3D> similar to above, has this been implemented ? Not a as=20 > big issue as > above for me, because this is just an implementation note. =3D> Agreed, this is just an implementation issue. >=20 > A proxy MAY multicast Neighbor Advertisements when its link-layer > address changes or when it is configured (by system management or > other mechanisms) to proxy for an address. If there are multiple > nodes that are providing proxy services for the same set=20 > of addresses > the proxies SHOULD provide a mechanism that prevents=20 > multiple proxies > from multicasting advertisements for any one address, in order to > reduce the risk of excessive multicast traffic. >=20 > =3D=3D> does anyone implement this SHOULD? Note that this does=20 > not give hints > how to even go about doing that. If not, remove. =3D> I don't know if anyone implements it, but they SHOULD ;) This is what the spec recommends, is it wise to change the (preumably) reocmmended mechanism because some don't follow it?=20 >=20 > NORMATIVE >=20 > [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 2373, July 1998. >=20 > =3D=3D>replace with 3513. However, there is one big problem=20 > here. addrarch is > PS, while this is going for DS. DS cannot have normative=20 > ref to PS. It is > not clear whether ADDR-ARCH can be put in as informative=20 > reference, the text > seems to be relying on it pretty heavily. OK with me, but=20 > there may be > problems.. =3D> Agreed. It seems to be normative. I'll change the references and let the WG chairs/ADs provide suggestions on how to handle this. >=20 > [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast > Listener Discovery for IPv6", RFC 2710,=20 > October 1999. >=20 > =3D=3D> this is also PS and cannot be referred to normatively. =3D> This one can be informative. >=20 > [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > =3D=3D> this must be over at the normative refs =3D> ok. >=20 > semi-editorial > -------------- >=20 > Inbound load balancing - Nodes with replicated=20 > interfaces may want > to load balance the reception of incoming packets across > multiple network interfaces on the same link. Such nodes > have multiple link-layer addresses assigned to the same > interface. For example, a single network driver could > represent multiple network interface cards as a single > logical interface having multiple link-layer addresses. >=20 > Load balancing is handled by allowing routers to omit the > source link-layer address from Router=20 > Advertisement packets, > [...] >=20 > =3D=3D> this is conflicting. The first para discusses generic=20 > inbound load > balancing, the second load balancing that applies only to=20 > routers w/ RAs.=20 > How do hosts perform inbound load balancing? Needs text tweaking.. =3D> ok, suggestions are welcome. >=20 > Unlike in IPv4 Router Discovery the Router=20 > Advertisement messages > do not contain a preference field. The preference=20 > field is not > needed to handle routers of different "stability";=20 > the Neighbor > Unreachability Detection will detect dead routers and=20 > switch to a > working one. >=20 > =3D=3D> preference has been plugged back, though not for stability=20 > reasons. I'd suggest just removing this paragraph. =3D> As you said, the preference is not used for stability reasons. I can clarify that it might be used for other reasons and leave it at that because this statement is still correct. The preference is=20 optional in v6. >=20 > Placing address resolution at the ICMP layer makes=20 > the protocol > more media-independent than ARP and makes it possible to use > standard IP authentication and security mechanisms as=20 > appropriate. >=20 > =3D=3D> the latter part of this sentence is a bit questionable,=20 > as this probably > referred to using IPsec. Still, there is a benefit of being=20 > able to use a > single SEND mechanism for _all_ link types. Text tweaking needed. >=20 > variable MTU - Neighbor Discovery allows routers to=20 > specify a MTU > for the link, which all nodes then=20 > use. All nodes > on a link must use the same MTU (or Maximum > Receive Unit) in order for multicast to work > properly. Otherwise when=20 > multicasting a sender, > which can not know which nodes will=20 > receive the > packet, could not determine a minimum=20 > packet size > all receivers can process. >=20 > =3D=3D> the last sentence is not 100% accurate. It's not MTU at=20 > stake, it's the > receiver's MRU (for processing the packet) or last-hop=20 > router's MTU (for > sending the packet on the last links). Might need minor text tweak. >=20 > If the bridges do not generate ICMP > Packet Too Big messages, communicating=20 > nodes will > be unable to use Path MTU to=20 > dynamically determine > the appropriate MTU on a per-neighbor=20 > basis. In > such cases, routers use the MTU option=20 > to specify > the maximum MTU value that is supported by all > segments. >=20 > =3D=3D> s/routers use/routers can be configured to use/ -- there=20 > is no magic to > do this automatically.. >=20 > 6.2.8. Link-local Address Change >=20 > The link-local address on a router SHOULD change rarely, if ever. >=20 > =3D=3D> this is an improper use of upper-caps. Just make it = lowercase. >=20 > For instance, a > mobile node, using [MIPv6], moving to a new link would need to > discover such movement as soon as possible to minimize=20 > the amount of > packet losses resulting from the change in its=20 > topological movement. > Router Solicitations provide a useful tool for movement=20 > detection in > Mobile IPv6 as they allow mobile nodes to determine=20 > movement to new > links. Hence, if a mobile node received link layer information > indicating that movement might have taken place, it MAY=20 > send a Router > Solicitation immediately, without random delays. The=20 > strength of such > indications should be assessed by the mobile node's=20 > implementation > and is outside the scope of this specification. >=20 > =3D=3D> it might not hurt to discuss the potential pitfalls of=20 > this approach > somewhere. For example, n case the link indications are=20 > shaky, or just hints, > and there is a significant number of MNs on a link, this=20 > could result in an > RS storm. >=20 > - The Target Address is a "valid" unicast or anycast address > assigned to the receiving interface [ADDRCONF], >=20 > - The Target Address is a unicast address for which the node is > offering proxy service, or >=20 > - The Target Address is a "tentative" address on which Duplicate > Address Detection is being performed [ADDRCONF]. > [...] >=20 >=20 > If the Target Address is either an anycast address or a unicast > address for which the node is providing proxy service,=20 > or the Target > Link-Layer Address option is not included, the Override=20 > flag SHOULD > be set to zero. [...] >=20 > =3D=3D> the middle bullet point appears to be inconsistent with=20 > the further > specification. That is, shouldn't an anycast address also=20 > be acceptable > (not that the node could tell it's anycast address :) >=20 > If the target's Neighbor Cache entry is in the=20 > INCOMPLETE state when > the advertisement is received, one of two things happens. > Otherwise, the receiving node performs the following > steps: >=20 > =3D=3D> "one of two" ? You do not specify or clearly refer to either > one of these. Needs rewording. >=20 > If the target's Neighbor Cache entry is in any state other than > INCOMPLETE when the advertisement is received, processing becomes > quite a bit more complex. If the Override flag is clear and the > supplied link-layer address differs from that in the=20 > cache, then one > of two actions takes place: if the state of the entry is=20 > REACHABLE, > set it to STALE, but do not update the entry in any other way; > otherwise, the received advertisement should be ignored=20 > and MUST NOT > update the cache. If the Override flag is set, both the Override > flag is clear and the supplied link-layer address is the=20 > same as that > in the cache, or no Target Link-layer address option was=20 > supplied, > the received advertisement MUST update the Neighbor=20 > Cache entry as > follows: >=20 > =3D=3D> AFAICS, you can remove 'both the Override flag is clear=20 > and' here, > because the same result happens if the Override flag is set. >=20 > A router MUST limit the rate at which Redirect messages=20 > are sent, in > order to limit the bandwidth and processing costs incurred by the > Redirect messages when the source does not correctly=20 > respond to the > Redirects, or the source chooses to ignore=20 > unauthenticated Redirect > messages. More details on the rate-limiting of ICMP=20 > error messages > can be found in [ICMPv6]. >=20 > =3D=3D> 'or the source chooses to ignore unauthenticated Redirect > messages' smells quite a bit from a leftover of IPsec AH=20 > times. Reword? =3D> Hmm, ok let me take a good look at it. In general, it's an acceptable statement, of course in reality there is no way of securing it for large scale deployment. AFAIK SEND didn't secure redirects.=20 >=20 > An example of denial of service attacks is that a node=20 > on the link > that can send packets with an arbitrary IP source=20 > address can both > advertise itself as a default router and also send=20 > "forged" Router > Advertisement messages that immediately time out all=20 > other default > routers as well as all on-link prefixes. >=20 > =3D=3D> 'on-link' is not accurate. Using these mechanisms, you=20 > can't capture > _all_ on-link traffic as that goes between the nodes. You=20 > can capture that > e.g. by advertising more specifics in RAs, with NA/ND=20 > spoofing, etc., but > the sentence does not seem to be 100% correct. >=20 > o Removed the on-link assumption in section 5.2 >=20 > =3D=3D> add an informational reference to=20 > draft-ietf-v6ops-onlinkassumption here, as that doc captures the=20 > reasoning for the change. >=20 > editorial > --------- >=20 > link-layer address > - a link-layer identifier for an interface. Examples > include IEEE 802 addresses for Ethernet=20 > links and E.164 > addresses for ISDN links. >=20 > =3D=3D> please remove the ISDN E.164 example, that's too crufty=20 > to be here.. >=20 > non-broadcast multi-access (NBMA) > - a link to which more than two=20 > interfaces can attach, > but that does not support a native form=20 > of multicast > or broadcast (e.g., X.25, ATM, frame=20 > relay, etc.). >=20 >=20 > Note that all link types (including NBMA) are >=20 > =3D=3D> kill the extra empty line. >=20 > all-nodes multicast address > - the link-local scope address to reach all nodes. > FF02::1 >=20 > =3D=3D> s/nodes./nodes,/, s/1/1./ -- the same with all-routers. >=20 > A solicitation that passes the validity checks is called a "valid > solicitation". > .. > An advertisement that passes the validity checks is=20 > called a "valid > advertisement". > .. > A Neighbor Solicitation that passes the validity checks=20 > is called a > "valid solicitation". > .. > A Neighbor Advertisements that passes the validity=20 > checks is called a > "valid advertisement". >=20 > =3D=3D> I'd rewrite these to be "valid router solicitation",=20 > "valid router > advertisement", "valid neighbor solicitation", etc. >=20 > 6.3.4. Processing Received Router Advertisements >=20 > When multiple routers are present, the information advertised > collectively by all routers may be a superset of the information > contained in a single Router Advertisement. Moreover,=20 > information > may also be obtained through other dynamic means, such=20 > as stateful > autoconfiguration. Hosts accept the union of all received > information; the receipt of a Router Advertisement MUST NOT > invalidate all information received in a previous=20 > advertisement or > from another source. However, when received information for a > specific parameter (e.g., Link MTU) or option (e.g.,=20 > Lifetime on a > specific Prefix) differs from information received=20 > earlier, and the > parameter/option can only have one value, the most=20 > recently-received > information is considered authoritative. >=20 > =3D=3D> it might not hurt to add an explicit reference to=20 > section 6.2.7 on the > consistency -- maybe even replacing the duplicate list here.. >=20 > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. This serves to alleviate=20 > congestion when > many hosts start up on a link at the same time, such as=20 > might happen > after recovery from a power failure. If a host has=20 > already performed > a random delay since the interface became (re)enabled=20 > (e.g., as part > of Duplicate Address Detection [ADDRCONF]) there is no=20 > need to delay > again before sending the first Router Solicitation=20 > message. In some > cases, the random delay MAY be omitted if necessary. [...] >=20 > =3D=3D> please split this ridiculously long paragraph to at=20 > least two -- maybe > before "In some cases,". >=20 > interface should be used. Using the prompting packet's source > address when possible insures that the recipient of the Neighbor > Solicitation installs in its Neighbor Cache the IP=20 > address that is >=20 > =3D=3D> s/insures/ensures/ >=20 > [issuing redirects] > - the router determines that a better first-hop node=20 > resides on > the same link as the sending node for the=20 > Destination Address of > the packet being forwarded, and >=20 > =3D=3D> maybe s/determines/determines using unspecified=20 > mechanisms/ that this is > out of scope of this spec. >=20 > The trust model for redirects is the same as in IPv4. A=20 > redirect is > accepted only if received from the same router that is currently > being used for that destination. It is natural to trust=20 > the routers > on the link. If a host has been redirected to another=20 > node (i.e., > the destination is on-link) there is no way to prevent the target > from issuing another redirect to some other destination.=20 > However, > this exposure is no worse than it was; the target host, once > subverted, could always act as a hidden router to forward traffic > elsewhere. >=20 > =3D=3D> add the empty line before the start of this paragraph > =3D=3D> "than it was" --> what does this refer to ? >=20 > On the > other hand, many of the threats discussed in this=20 > section are less > effective, or non-existent, on point-to-point links, or cellular > links where hosts share links with one neighbor, i.e. the default > router. >=20 > =3D=3D> s/hosts share links with one/a host shares a link with=20 > only one/ ? >=20 > [ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED=20 > NUMBERS", STD 2, > RFC 1700, October 1994. See also: > http://www.iana.org/numbers.html >=20 > =3D=3D> this should probably be replaced with RFC3232 ("Assigned=20 > Numbers: RFC > 1700 is Replaced by an On-line Database"). >=20 >=20 >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 19 00:04:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17886 for ; Sun, 19 Dec 2004 00:04:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CftO8-0004Op-DO for ipv6-web-archive@ietf.org; Sun, 19 Dec 2004 00:13:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CftCj-0006ZE-5d; Sun, 19 Dec 2004 00:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CftBw-0006QJ-7E for ipv6@megatron.ietf.org; Sun, 19 Dec 2004 00:01:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17799 for ; Sun, 19 Dec 2004 00:01:08 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CftKu-0004LZ-6X for ipv6@ietf.org; Sun, 19 Dec 2004 00:10:28 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id AE0C9379 for ; Sun, 19 Dec 2004 00:00:33 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 19 Dec 2004 00:00:33 -0500 Message-Id: <20041219050033.AE0C9379@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.54% | 3 | 17.05% | 28472 | pekkas@netcore.fi 3.85% | 1 | 14.07% | 23491 | h.soliman@flarion.com 7.69% | 2 | 9.02% | 15058 | brian@innovationslab.net 7.69% | 2 | 7.10% | 11864 | jeroen@unfix.org 7.69% | 2 | 4.75% | 7936 | gih@apnic.net 7.69% | 2 | 4.70% | 7849 | mdy-616-ydm@leo-net.jp 3.85% | 1 | 7.92% | 13222 | alh-ietf@tndh.net 3.85% | 1 | 4.43% | 7391 | fredricklowery@hotmail.com 3.85% | 1 | 3.90% | 6507 | bob.hinden@nokia.com 3.85% | 1 | 3.49% | 5832 | internet-drafts@ietf.org 3.85% | 1 | 2.78% | 4648 | sra+ipng@hactrn.net 3.85% | 1 | 2.78% | 4643 | huitema@windows.microsoft.com 3.85% | 1 | 2.68% | 4473 | jinmei@isl.rdc.toshiba.co.jp 3.85% | 1 | 2.60% | 4342 | nobumichi.ozoe@jp.yokogawa.com 3.85% | 1 | 2.43% | 4063 | brc@zurich.ibm.com 3.85% | 1 | 2.17% | 3616 | sebastien.roy@sun.com 3.85% | 1 | 2.08% | 3473 | matthew.ford@bt.com 3.85% | 1 | 2.07% | 3449 | vladislav.yasevich@hp.com 3.85% | 1 | 2.05% | 3424 | nsimaria@cisco.com 3.85% | 1 | 1.94% | 3232 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 26 |100.00% | 166985 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 21 02:50:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12816 for ; Tue, 21 Dec 2004 02:50:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgewb-0004AD-3b for ipv6-web-archive@ietf.org; Tue, 21 Dec 2004 03:00:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgeid-0001Uw-5d; Tue, 21 Dec 2004 02:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgebS-0008RU-8v for ipv6@megatron.ietf.org; Tue, 21 Dec 2004 02:38:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11984 for ; Tue, 21 Dec 2004 02:38:40 -0500 (EST) Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgeks-0003pG-1n for ipv6@ietf.org; Tue, 21 Dec 2004 02:48:26 -0500 Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id iBL7c4qK010084 for ; Tue, 21 Dec 2004 16:38:04 +0900 (envelope-from shinomiya.daisu@jp.fujitsu.com) Received: from s0.gw.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id iBL7c3f1003946 for ; Tue, 21 Dec 2004 16:38:03 +0900 (envelope-from shinomiya.daisu@jp.fujitsu.com) Received: from s0.gw.fujitsu.co.jp (s0 [127.0.0.1]) by s0.gw.fujitsu.co.jp (Postfix) with ESMTP id 95A0CA7D3D for ; Tue, 21 Dec 2004 16:38:03 +0900 (JST) Received: from fjm503.ms.jp.fujitsu.com (fjm503.ms.jp.fujitsu.com [10.56.99.77]) by s0.gw.fujitsu.co.jp (Postfix) with ESMTP id 31B7AA7D3B for ; Tue, 21 Dec 2004 16:38:03 +0900 (JST) Received: from THE-Judgement.jp.fujitsu.com (fjmscan502.ms.jp.fujitsu.com [10.56.99.142])by fjm503.ms.jp.fujitsu.com with ESMTP id iBL7bcnS008935 for ; Tue, 21 Dec 2004 16:37:39 +0900 Message-Id: <6.0.0.20.2.20041221161703.070f33a0@pop.jp.fujitsu.com> X-Sender: shinomiya.daisu@pop.jp.fujitsu.com X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 21 Dec 2004 16:37:12 +0900 To: ipv6@ietf.org From: Daisuke Shinomiya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: Question on Site Local-Scope Multicast Addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Dear all, I have a question on Site Local-Scope Multicast Addresses. In RFC3897, the Site Local address was deprecated. Is not Site Local-Scope Multicast Address used likewise? (For example, All Routers Address (FF05::2)) [RFC2373]) Thanks. --- Daisuke Shinomiya -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 21 03:06:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13611 for ; Tue, 21 Dec 2004 03:06:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgfAk-0004VW-1S for ipv6-web-archive@ietf.org; Tue, 21 Dec 2004 03:15:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgeuT-0003Iq-O2; Tue, 21 Dec 2004 02:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgen3-00028G-VD for ipv6@megatron.ietf.org; Tue, 21 Dec 2004 02:50:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12805 for ; Tue, 21 Dec 2004 02:50:40 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgewT-00049c-7x for ipv6@ietf.org; Tue, 21 Dec 2004 03:00:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Dec 2004 00:57:58 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from codc-mira-1.cisco.com (IDENT:mirapoint@codc-mira-1.cisco.com [192.122.173.20]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBL7o0oB016755 for ; Mon, 20 Dec 2004 23:50:05 -0800 (PST) Received: from cisco.com ([10.77.202.217]) by codc-mira-1.cisco.com (MOS 3.4.6-GR) with ESMTP id AGT65972; Tue, 21 Dec 2004 13:20:50 +0530 (IST) Message-ID: <41C7D5A8.5070503@cisco.com> Date: Tue, 21 Dec 2004 13:20:00 +0530 From: Nilesh Simaria User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: Solicited Node Multicast Address question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi, Solicited Node Multicast addresses are using last 24bits of MAC address. Assume in a given link, if there exists few nodes with unique MAC addresses (but same last 24 bits). In this case both all will be listening to same Solicited Node Multicast Address. Won't it create a problem in normal IPv6 neighbour discovery process ? Thanks and Reply, Nilesh -- Unix is simple, but it takes genius to understand the simplicity. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 21 07:04:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29226 for ; Tue, 21 Dec 2004 07:04:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgitz-0001Ll-Dg for ipv6-web-archive@ietf.org; Tue, 21 Dec 2004 07:14:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgieN-0002B2-3G; Tue, 21 Dec 2004 06:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgiab-0001f3-JX for ipv6@megatron.ietf.org; Tue, 21 Dec 2004 06:54:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28779 for ; Tue, 21 Dec 2004 06:54:02 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgik3-0001Al-Pw for ipv6@ietf.org; Tue, 21 Dec 2004 07:03:52 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:dc6c:5b7:eaf4:4e98]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3831915218; Tue, 21 Dec 2004 20:53:56 +0900 (JST) Date: Tue, 21 Dec 2004 20:54:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Daisuke Shinomiya In-Reply-To: <6.0.0.20.2.20041221161703.070f33a0@pop.jp.fujitsu.com> References: <6.0.0.20.2.20041221161703.070f33a0@pop.jp.fujitsu.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: Question on Site Local-Scope Multicast Addresses X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >>>>> On Tue, 21 Dec 2004 16:37:12 +0900, >>>>> Daisuke Shinomiya said: > I have a question on Site Local-Scope Multicast Addresses. > In RFC3897, the Site Local address was deprecated. You should mean RFC3879, and the RFC only affects unicast site-local addresses. > Is not Site Local-Scope Multicast Address used likewise? > (For example, All Routers Address (FF05::2)) [RFC2373]) Site-local multicast addresses are still valid as currently defined. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 21 07:08:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29505 for ; Tue, 21 Dec 2004 07:08:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgiy8-0001Se-A7 for ipv6-web-archive@ietf.org; Tue, 21 Dec 2004 07:18:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgin6-0003vE-Tx; Tue, 21 Dec 2004 07:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgifd-0002N6-PH for ipv6@megatron.ietf.org; Tue, 21 Dec 2004 06:59:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28926 for ; Tue, 21 Dec 2004 06:59:12 -0500 (EST) Received: from postfix.iai.uni-bonn.de ([131.220.8.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgip3-0001Ef-Oo for ipv6@ietf.org; Tue, 21 Dec 2004 07:09:02 -0500 X-IAI-Env-From: : [131.220.4.211] Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 0778D5C940; Tue, 21 Dec 2004 12:58:42 +0100 (MET) (envelope-from ignatios@cello.cs.uni-bonn.de) (envelope-to VARIOUS) (2) (internal use: ta=0, tu=1, te=0, am=-, au=-) Received: from cello.cs.uni-bonn.de (cello.cs.uni-bonn.de [131.220.4.178]) by theory.cs.uni-bonn.de (8.12.9/8.12.9) with SMTP id iBLBwfpp010223; Tue, 21 Dec 2004 12:58:41 +0100 (MET) Received: (from ignatios@cello.cs.uni-bonn.de) by cello.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb4 7oct2003); Tue, 21 Dec 2004 12:58:41 CET (sender ignatios@cello.cs.uni-bonn.de) Date: Tue, 21 Dec 2004 12:58:41 +0100 From: Ignatios Souvatzis To: Nilesh Simaria Message-ID: <20041221115841.GB17226@cs.uni-bonn.de> References: <41C7D5A8.5070503@cisco.com> Mime-Version: 1.0 In-Reply-To: <41C7D5A8.5070503@cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipv6@ietf.org Subject: Re: Solicited Node Multicast Address question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0144390578==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 --===============0144390578== Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Dec 21, 2004 at 01:20:00PM +0530, Nilesh Simaria wrote: > Solicited Node Multicast addresses are using last 24bits of MAC address.= =20 > Assume in a given link, if there exists few nodes with > unique MAC addresses (but same last 24 bits). In this case both all will= =20 > be listening to same Solicited Node Multicast Address. > Won't it create a problem in normal IPv6 neighbour discovery process ? = =20 No, because they're still supposed to look inside the solicitation packet at the "target address" field to find out which node's address is requested, and only reply if it's their own address. Using multicast is an optimization over IPv4's ARP: most nodes on a big network won't ever see the neighbour discovery packet, while with IPv4's ARP (which is broadcasted) all have to do the comparison. I very much hope your employer's equipment does compare the target address... -is --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBQcgP7TCn4om+4LhpAQGCoQgAroZLaWSOYbagDHk1eMHRgVSFhMCPPn4r 0LsPh5D9dG6DewN0nLO6a3yRzw9E5Zqa4Q9RD05AGFQzoNhBeUbMhP6ihVWRxbsS 1lbzfMdkiMWEYkMz7oMLm4oS5mcnq3kth69hnGemzhzZBtQfggsq4udnMZHNH6is tGucwzheSQwuy281mvP23B6Y6sEdY7aOFLfeA1944t5AXFNE4D+jQhAddZ7pBHSu XAJJ9DKcQRD5sDz1+1aWTtxKxXzfVVNqNdCjmIJD+TTs3fV0tXRIJWdWhOb2HQvV Fa9s06NLxl8Lyeb1/ABoFre1JGqmHb79R5Wp2JnGCiTBe5CGj9J3zA== =muv2 -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V-- --===============0144390578== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0144390578==-- From ipv6-bounces@ietf.org Wed Dec 22 14:47:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26631 for ; Wed, 22 Dec 2004 14:47:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChCc3-0000pt-L2 for ipv6-web-archive@ietf.org; Wed, 22 Dec 2004 14:57:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChCLD-00036X-1Y; Wed, 22 Dec 2004 14:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChCHy-0001Zk-P1 for ipv6@megatron.ietf.org; Wed, 22 Dec 2004 14:36:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26061 for ; Wed, 22 Dec 2004 14:36:48 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChCRg-0000Ya-S0 for ipv6@ietf.org; Wed, 22 Dec 2004 14:46:54 -0500 Received: from gihz1.apnic.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iBMJaAdZ013958; Thu, 23 Dec 2004 06:36:12 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041223063019.021d1970@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 23 Dec 2004 06:34:51 +1100 To: Jeroen Massar From: Geoff Huston In-Reply-To: <1103185856.20370.72.camel@firenze.zurich.ibm.com> References: <0AAF93247C75E3408638B965DEE11A700BE1999B@i2km41-ukdy.domain1.systemhost.net> <6.0.1.1.2.20041216182513.021b6dd8@localhost> <1103185856.20370.72.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: RE: I-D ACTION:draft-huston-ip6-iana-registry-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 07:30 PM 16/12/2004, Jeroen Massar wrote: >Geoff, what is your opinion on asking IANA to publish this prefix list >through their whois interface (whois.iana.net) which currently does >serve some domains like .int. > >This would be useful for redirection purposes to the correct RIR or >simply finding out the RFC to which space this belongs to ;) I'm personally not sure about this Jeroen - I would've thought the RIRs could construct a comprehensive whois service from their own data, if thats what their community wants them to do. This particular draft is concerned specifically with the text of the two IPv6 address registries, and does not wander into the areas of modes of publication and the manner by which the registry may be queried. regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 22 15:13:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28646 for ; Wed, 22 Dec 2004 15:13:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChD0n-0001U3-JN for ipv6-web-archive@ietf.org; Wed, 22 Dec 2004 15:23:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChCpm-0002XW-Ck; Wed, 22 Dec 2004 15:11:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChCmD-0000oE-Fp for ipv6@megatron.ietf.org; Wed, 22 Dec 2004 15:08:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28066 for ; Wed, 22 Dec 2004 15:08:02 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChCvv-0001LE-OK for ipv6@ietf.org; Wed, 22 Dec 2004 15:18:09 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBMK7K105663; Wed, 22 Dec 2004 22:07:24 +0200 Date: Wed, 22 Dec 2004 22:07:20 +0200 (EET) From: Pekka Savola To: "Soliman, Hesham" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: IPv6 WG Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Inline.. On Sat, 18 Dec 2004, Soliman, Hesham wrote: > > substantial > > ----------- > > > > ==> this spec needs at least an IANA Considerations section, > > stating at > > least: > > 1) the allocation guidelines for ND option types/codes > > (Standards Action? > > IETF Consensus?) > > 2) that no IANA action is required for ICMPv6 types, > > beyond updating > > the ICMPv6 codepoints to refer to this RFC instead of > > RFC2461 in their > > registry. > > => ok. I didn't think IANA sections had to be included but I'll > add 2) above. Yes, in all new drafts will have to have an IANA Considerations section, even if empty .. and currently there's no policy on ICMPv6 ND assignments, so this doc needs to spell it out. > > > > AdvValidLifetime > > The value to be placed in the Valid > > Lifetime in the Prefix Information > > option, in seconds. The > > designated value > > of all 1's (0xffffffff) represents > > infinity. Implementations MUST allow > > AdvValidLifetime to be specified in two > > ways: > > > > - a time that decrements in > > real time, > > that is, one that will result in a > > Lifetime of zero at the specified > > time in the future, or > > > > - a fixed time that stays the same in > > consecutive advertisements. > > > > ==> AFAIK, the first option has not been implemented; I've > > at least not seen > > in done. Therefore unless someone shows that there are two > > implementations > > of this, this must be removed. (The same for > > AdvPreferredLifetime, and a bit > > in section 6.2.7.) > > => There are three issues to consider: > 1. The second option actually (evidently more implemented) > seems strange. If the time is decremented, then why not > reflect that in advertisements? I see nothing strange there at all. E.g., if you advertise AdvValidLifetime of 1 hour, and the service is expected to continue to be available, it is natural that each advertisement has the same value. > 2. One could argue that this is an implementation issue. The > receiver will update the Valid Lifetime field each time > it gets an adv. So does it matter if it's a different value > each time or the same? I don't understand what you're trying to say. The first option is clearly meant to be used when renumbering a network at a specific time, and you want to convey that in the advertisement. The second is used everywhere else. > 3. As Bob mentioned, this is already a DS and I'm not sure > if we want to remove this now, especially if we don't know > 100 % that it's not implemented. KAME implements the first option, but I am not aware of anyone else. No matter what, even if it stays, MUST for both is clearly inappropriate. MAY for the first might be OK. > > A proxy MAY multicast Neighbor Advertisements when its link-layer > > address changes or when it is configured (by system management or > > other mechanisms) to proxy for an address. If there are multiple > > nodes that are providing proxy services for the same set > > of addresses > > the proxies SHOULD provide a mechanism that prevents > > multiple proxies > > from multicasting advertisements for any one address, in order to > > reduce the risk of excessive multicast traffic. > > > > ==> does anyone implement this SHOULD? Note that this does not > > give hints how to even go about doing that. If not, remove. > > => I don't know if anyone implements it, but they SHOULD ;) > This is what the spec recommends, is it wise to change the > (preumably) reocmmended mechanism because some don't follow it? The idea of the implementation requirement is to remove those recommendations which implementations really don't want to do, or have proven to be too difficult to implement to make it worth the while. I think this is caused by the latter. > > semi-editorial > > -------------- > > > > Inbound load balancing - Nodes with replicated > > interfaces may want > > to load balance the reception of incoming packets across > > multiple network interfaces on the same link. Such nodes > > have multiple link-layer addresses assigned to the same > > interface. For example, a single network driver could > > represent multiple network interface cards as a single > > logical interface having multiple link-layer addresses. > > > > Load balancing is handled by allowing routers to omit the > > source link-layer address from Router > > Advertisement packets, > > [...] > > > > ==> this is conflicting. The first para discusses generic inbound > > load balancing, the second load balancing that applies only to > > routers w/ RAs. How do hosts perform inbound load balancing? > > Needs text tweaking.. > > => ok, suggestions are welcome. Replace: Load balancing is handled by allowing routers to omit the source link-layer address from Router Advertisement packets, thereby forcing neighbors to use Neighbor Solicitation messages to learn link-layer addresses of routers. Returned Neighbor Advertisement messages can then contain link-layer addresses that differ depending on who issued the solicitation. With: Load balancing is handled by allowing nodes to omit the source link-layer address from neighbor discovery packets, thereby forcing neighbors to use Neighbor Solicitation messages to learn link-layer addresses. Returned Neighbor Advertisement messages can then contain link-layer addresses that differ depending on who issued the solicitation. > > A router MUST limit the rate at which Redirect messages > > are sent, in > > order to limit the bandwidth and processing costs incurred by the > > Redirect messages when the source does not correctly > > respond to the > > Redirects, or the source chooses to ignore > > unauthenticated Redirect > > messages. More details on the rate-limiting of ICMP > > error messages > > can be found in [ICMPv6]. > > > > ==> 'or the source chooses to ignore unauthenticated Redirect > > messages' smells quite a bit from a leftover of IPsec AH > > times. Reword? > > => Hmm, ok let me take a good look at it. In general, it's an > acceptable statement, of course in reality there is no way > of securing it for large scale deployment. AFAIK SEND didn't > secure redirects. True, but IMHO the context of the word 'unauthenticated' is not clear. SEND supports redirects. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 22 16:16:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04004 for ; Wed, 22 Dec 2004 16:16:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChE09-0003W4-E0 for ipv6-web-archive@ietf.org; Wed, 22 Dec 2004 16:26:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChDhZ-00029o-CM; Wed, 22 Dec 2004 16:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChDWt-0004P8-AE for ipv6@megatron.ietf.org; Wed, 22 Dec 2004 15:56:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02592 for ; Wed, 22 Dec 2004 15:56:16 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDgd-0002t9-GC for ipv6@ietf.org; Wed, 22 Dec 2004 16:06:23 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.6950472; Wed, 22 Dec 2004 15:55:15 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Brian Haberman Date: Wed, 22 Dec 2004 15:55:15 -0500 To: Pekka Savola X-Mailer: Apple Mail (2.619) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "Soliman, Hesham" , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1824288601==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 --===============1824288601== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-887663804; protocol="application/pkcs7-signature" --Apple-Mail-1-887663804 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 22, 2004, at 15:07, Pekka Savola wrote: > Inline.. > > On Sat, 18 Dec 2004, Soliman, Hesham wrote: >> > substantial >> > ----------- >> > >> > ==> this spec needs at least an IANA Considerations section, >> > stating at >> > least: >> > 1) the allocation guidelines for ND option types/codes >> > (Standards Action? >> > IETF Consensus?) >> > 2) that no IANA action is required for ICMPv6 types, >> > beyond updating >> > the ICMPv6 codepoints to refer to this RFC instead of >> > RFC2461 in their >> > registry. >> >> => ok. I didn't think IANA sections had to be included but I'll >> add 2) above. > > Yes, in all new drafts will have to have an IANA Considerations > section, even if empty .. and currently there's no policy on ICMPv6 ND > assignments, so this doc needs to spell it out. We need to keep in mind that Section 7 of RFC 2780 deals with Type/Code assignments for ICMPv6. Regards, Brian --Apple-Mail-1-887663804 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjIyMjA1NTE1WjAjBgkqhkiG9w0B CQQxFgQUj5Q4L7bPnVUAMoZ4u4YPjpyoTD8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAnIQkcVTOS6s3hCljIZ2o1qsMvMIlIxhp/7VzLhd4v24iKQYCDkqmRfea4AYSV3C0J0y4 uTAfoVgwSXsA2Obj54Q9YwY3u8Ae5YIVyONuYmtMhanAqdANLXZi3ip+9gCVSSFtrfwtLWUx6dTC Vv0PJZKSW3P3llsH9awZik9+taQW2rvo0oZT63ebiNGh/APv0C/9PyD5v1idyr843/MKNFaK/IgL k1wobL2iFOlIIGe8oRAVnmbXWlU5wKNGPC6cG7kRD6wKtMtwMBj+V2uaQlYiWTGirDbi1d0HB0TD RG1FE3XDBQejGksxY4MxjLXWfCKyaP2v8vmNEFztag4M2QAAAAAAAA== --Apple-Mail-1-887663804-- --===============1824288601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1824288601==-- From ipv6-bounces@ietf.org Sun Dec 26 00:06:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07552 for ; Sun, 26 Dec 2004 00:06:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiQmj-0003Ta-2p for ipv6-web-archive@ietf.org; Sun, 26 Dec 2004 00:17:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiQZ8-0007zQ-RP; Sun, 26 Dec 2004 00:03:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiQX1-0007ee-3V for ipv6@megatron.ietf.org; Sun, 26 Dec 2004 00:01:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07247 for ; Sun, 26 Dec 2004 00:01:24 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiQhQ-0003Lg-93 for ipv6@ietf.org; Sun, 26 Dec 2004 00:12:13 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 1A2E01CE for ; Sun, 26 Dec 2004 00:00:43 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 26 Dec 2004 00:00:43 -0500 Message-Id: <20041226050043.1A2E01CE@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.50% | 1 | 23.27% | 9938 | pekkas@netcore.fi 12.50% | 1 | 19.52% | 8335 | brian@innovationslab.net 12.50% | 1 | 13.28% | 5672 | ignatios@cs.uni-bonn.de 12.50% | 1 | 9.79% | 4181 | sra+ipng@hactrn.net 12.50% | 1 | 8.79% | 3754 | shinomiya.daisu@jp.fujitsu.com 12.50% | 1 | 8.76% | 3741 | gih@apnic.net 12.50% | 1 | 8.41% | 3592 | jinmei@isl.rdc.toshiba.co.jp 12.50% | 1 | 8.18% | 3493 | nsimaria@cisco.com --------+------+--------+----------+------------------------ 100.00% | 8 |100.00% | 42706 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 28 16:21:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00223 for ; Tue, 28 Dec 2004 16:21:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjOxo-0006eY-O0 for ipv6-web-archive@ietf.org; Tue, 28 Dec 2004 16:33:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOMc-00043u-MI; Tue, 28 Dec 2004 15:54:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOJG-00020y-E6; Tue, 28 Dec 2004 15:51:14 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25459; Tue, 28 Dec 2004 15:51:11 -0500 (EST) Message-Id: <200412282051.PAA25459@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 28 Dec 2004 15:51:11 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2462bis-07.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson, et al. Filename : draft-ietf-ipv6-rfc2462bis-07.txt Pages : 31 Date : 2004-12-28 This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-07.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-ipv6-rfc2462bis-07.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-ipv6-rfc2462bis-07.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-12-28152706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2462bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2462bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-28152706.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Dec 28 16:24:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00797 for ; Tue, 28 Dec 2004 16:24:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjP04-0006qJ-SY for ipv6-web-archive@ietf.org; Tue, 28 Dec 2004 16:35:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOMf-00045P-Pd; Tue, 28 Dec 2004 15:54:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOJK-00022s-E0; Tue, 28 Dec 2004 15:51:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25467; Tue, 28 Dec 2004 15:51:16 -0500 (EST) Message-Id: <200412282051.PAA25467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 28 Dec 2004 15:51:15 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-privacy-addrs-v2-02.txt Pages : 30 Date : 2004-12-28 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-02.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-ipv6-privacy-addrs-v2-02.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-ipv6-privacy-addrs-v2-02.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-12-28152712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-privacy-addrs-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-28152712.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Dec 31 05:11:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16957 for ; Fri, 31 Dec 2004 05:11:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkJwB-0004Pm-Iv for ipv6-web-archive@ietf.org; Fri, 31 Dec 2004 05:23:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkJZE-0005qj-24; Fri, 31 Dec 2004 04:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkJY0-0005fy-Cp for ipv6@megatron.ietf.org; Fri, 31 Dec 2004 04:58:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16455 for ; Fri, 31 Dec 2004 04:58:13 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkJjV-0004AJ-Ir for ipv6@ietf.org; Fri, 31 Dec 2004 05:10:10 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I9K00I09ZO6AW@mailout3.samsung.com> for ipv6@ietf.org; Fri, 31 Dec 2004 18:57:42 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I9K00057ZO439@mailout3.samsung.com> for ipv6@ietf.org; Fri, 31 Dec 2004 18:57:40 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I9K003A1ZO24K@mmp1.samsung.com> for ipv6@ietf.org; Fri, 31 Dec 2004 18:57:40 +0900 (KST) Date: Fri, 31 Dec 2004 15:23:57 +0530 From: Radhakrishnan Suryanarayanan To: ipv6@ietf.org Message-id: <01a901c4ef1e$a5ceb020$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: MLDv2 router support in Linux X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radhakrishnan Suryanarayanan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1702105243==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. --===============1702105243== Content-type: multipart/alternative; boundary="Boundary_(ID_eWXCLxgS+cuYhauHrPE4DQ)" This is a multi-part message in MIME format. --Boundary_(ID_eWXCLxgS+cuYhauHrPE4DQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi all, Does anyone have any information about MLDv2 Router support implementation for Linux? regards Radhakrishnan --Boundary_(ID_eWXCLxgS+cuYhauHrPE4DQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi all,
  Does anyone have any information about MLDv2 Router support implementation for Linux?
 
regards
Radhakrishnan
--Boundary_(ID_eWXCLxgS+cuYhauHrPE4DQ)-- --===============1702105243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1702105243==-- From ipv6-bounces@ietf.org Fri Dec 31 09:30:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00400 for ; Fri, 31 Dec 2004 09:30:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkNzE-0001C1-7i for ipv6-web-archive@ietf.org; Fri, 31 Dec 2004 09:42:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkNhK-0007gK-Ja; Fri, 31 Dec 2004 09:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkNgC-0007HR-Tn for ipv6@megatron.ietf.org; Fri, 31 Dec 2004 09:23:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00126 for ; Fri, 31 Dec 2004 09:22:58 -0500 (EST) Received: from yue.linux-ipv6.org ([203.178.140.15] helo=yue.st-paulia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkNra-00012n-50 for ipv6@ietf.org; Fri, 31 Dec 2004 09:34:57 -0500 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8417433CC2; Fri, 31 Dec 2004 23:22:58 +0900 (JST) Date: Fri, 31 Dec 2004 23:22:56 +0900 (JST) Message-Id: <20041231.232256.54816907.yoshfuji@linux-ipv6.org> To: rkrishnan.s@samsung.com From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <01a901c4ef1e$a5ceb020$3a476c6b@sisodomain.com> References: <01a901c4ef1e$a5ceb020$3a476c6b@sisodomain.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: yoshfuji@linux-ipv6.org, ipv6@ietf.org Subject: Re: MLDv2 router support in Linux X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit In article <01a901c4ef1e$a5ceb020$3a476c6b@sisodomain.com> (at Fri, 31 Dec 2004 15:23:57 +0530), Radhakrishnan Suryanarayanan says: > Does anyone have any information about MLDv2 Router support implementation for Linux? I don't think it is the right place to ask such question (and it is easy to search) but anyway: http://clarinet.u-strasbg.fr/~hoerdt/pim6sd_linux/?topic=Intro http://clarinet.u-strasbg.fr/~hoerdt/linux_ipv6_mforwarding/?topic=Intro --yoshfuji -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------