From mailman-bounces@ietf.org Sat Jan 1 08:15:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17983 for ; Sat, 1 Jan 2005 08:15:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkjIX-0000id-9x for ipv6-web-archive@ietf.org; Sat, 01 Jan 2005 08:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgST-000422-Lj for ipv6-web-archive@ietf.org; Sat, 01 Jan 2005 05:26:05 -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: Sat, 01 Jan 2005 05:11:07 -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 Sun Jan 2 00:10:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23768 for ; Sun, 2 Jan 2005 00:10:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkyD1-0007H9-9T for ipv6-web-archive@ietf.org; Sun, 02 Jan 2005 00:23:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckxyi-0007o0-Hw; Sun, 02 Jan 2005 00:08:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckxrg-0005vl-EP for ipv6@megatron.ietf.org; Sun, 02 Jan 2005 00:01: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 AAA23238 for ; Sun, 2 Jan 2005 00:01:13 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cky3Z-00077i-4d for ipv6@ietf.org; Sun, 02 Jan 2005 00:13:33 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 57428687 for ; Sun, 2 Jan 2005 00:00:38 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 02 Jan 2005 00:00:38 -0500 Message-Id: <20050102050038.57428687@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: 79899194edc4f33a41f49410777972f8 Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 2 | 44.05% | 12406 | internet-drafts@ietf.org 16.67% | 1 | 17.81% | 5017 | rkrishnan.s@samsung.com 16.67% | 1 | 13.04% | 3673 | yoshfuji@linux-ipv6.org 16.67% | 1 | 12.83% | 3615 | mailman-owner@ietf.org 16.67% | 1 | 12.27% | 3455 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 28166 | 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 Jan 3 09:39:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01892 for ; Mon, 3 Jan 2005 09:39:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClTYd-0005Ux-Pd for ipv6-web-archive@ietf.org; Mon, 03 Jan 2005 09:51:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClTKa-0001KV-Sx; Mon, 03 Jan 2005 09:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClTBr-0006zY-7Z for ipv6@megatron.ietf.org; Mon, 03 Jan 2005 09:28: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 JAA01045 for ; Mon, 3 Jan 2005 09:28:09 -0500 (EST) Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClTO0-0005Gt-Ts for ipv6@ietf.org; Mon, 03 Jan 2005 09:40:46 -0500 Received: (qmail 17225 invoked from network); 3 Jan 2005 14:26:23 -0000 Received: from 200-70-176-129.mrse.com.ar (HELO fernando.gont.com.ar) (gont-fernando@200.70.176.129) by server.frh.utn.edu.ar with SMTP; 3 Jan 2005 14:26:23 -0000 Message-Id: <4.3.2.7.2.20050103113237.00c59b50@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jan 2005 11:43:02 -0300 To: ipv6@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: ICMP attacks against TCP 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: 5011df3e2a27abcc044eaa15befcaa87 Folks, I'm an active member of the TCPM working group, and have authored a draft that discusses a number of attacks that can be performed against TCP by means of ICMPv4 and ICMPv6. The draft also proposes several counter-measures that either eliminate or mitigate the impact of these attacks. Brian Haberman (co-chair) agreed it would be useful to raise this issues in this mailing list, and thus I'm posting this message so that maybe I can get some feedback from IPv6 folks. Here's the announcement of the last version of the draft, which includes the Abstract and information on how to get the draft: >Date: Tue, 28 Dec 2004 15:50:50 -0500 >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-gont-tcpm-icmp-attacks-03.txt >To: i-d-announce@ietf.org >Message-ID: <200412282050.PAA25415@ietf.org> >Content-Type: text/plain; charset="us-ascii" > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : ICMP attacks against TCP > Author(s) : F. Gont > Filename : draft-gont-tcpm-icmp-attacks-03.txt > Pages : 28 > Date : 2004-12-28 > >This document discusses the use of the Internet Control Message > Protocol (ICMP) to perform a variety of attacks against the > Transmission Control Protocol (TCP) and other similar protocols. It > proposes several counter-measures to eliminate or minimize the impact > of these attacks. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-03.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-gont-tcpm-icmp-attacks-03.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-gont-tcpm-icmp-attacks-03.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. Any comments are more than welcome. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.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 Jan 3 16:35:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20273 for ; Mon, 3 Jan 2005 16:35:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cla3k-00021a-B4 for ipv6-web-archive@ietf.org; Mon, 03 Jan 2005 16:48:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZ48-00010U-H6; Mon, 03 Jan 2005 15:44:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZ15-0006pn-EG; Mon, 03 Jan 2005 15:41:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07944; Mon, 3 Jan 2005 15:41:25 -0500 (EST) Message-Id: <200501032041.PAA07944@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, 03 Jan 2005 15:41:25 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-optimistic-dad-03.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 : Optimistic Duplicate Address Detection for IPv6 Author(s) : N. Moore Filename : draft-ietf-ipv6-optimistic-dad-03.txt Pages : 17 Date : 2005-1-3 Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case and to remain interoperable with unmodified hosts and routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-03.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-optimistic-dad-03.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-optimistic-dad-03.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: <2005-1-3151316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-optimistic-dad-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-3151316.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 Jan 3 17:29:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29412 for ; Mon, 3 Jan 2005 17:29:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clau9-0004iQ-Ub for ipv6-web-archive@ietf.org; Mon, 03 Jan 2005 17:42:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaZh-0002G2-OM; Mon, 03 Jan 2005 17:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaJD-00006Q-2V for ipv6@megatron.ietf.org; Mon, 03 Jan 2005 17:04: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 RAA26302 for ; Mon, 3 Jan 2005 17:04:12 -0500 (EST) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClaVG-0003r8-EX for ipv6@ietf.org; Mon, 03 Jan 2005 17:16:54 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id B9632700817; Tue, 4 Jan 2005 09:03:54 +1100 (EST) Date: Tue, 4 Jan 2005 09:03:54 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20050103220354.GA27241@zoic.org> Mail-Followup-To: ipv6@ietf.org References: <200501032041.PAA07944@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501032041.PAA07944@ietf.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Re: I-D ACTION:draft-ietf-ipv6-optimistic-dad-03.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: b19722fc8d3865b147c75ae2495625f2 On 2005-01-03, Internet-Drafts@ietf.org wrote: > > Title : Optimistic Duplicate Address Detection for IPv6 > Author(s) : N. Moore > Filename : draft-ietf-ipv6-optimistic-dad-03.txt > Pages : 17 > Date : 2005-1-3 Happy New Year, folks! well, it didn't quite make it through the process in December, but so it goes. I'm hoping that this edition makes it through with just grammar nits (I've learned that these are inevitable!) and can go through Last Call soon. It hasn't actually got any much longer, I've just been a bit less frugal with pagination in the interests of readability. The changes basically take into account Jinmei and James K's comments, and add Appendix A, which contains some discussion of collision probabilities based on the work in the expired draft-soto-mobileip-random-iids-00 ... the appendix text is new, and needs a little work, but it's non-normative so I figure the nits can get hammered out without slowing the LC. Best wishes for 2005! -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 4 02:58:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21195 for ; Tue, 4 Jan 2005 02:58:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cljm8-0007LN-Au for ipv6-web-archive@ietf.org; Tue, 04 Jan 2005 03:10:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CljUB-0007RF-HY; Tue, 04 Jan 2005 02:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chrq0-0005pR-6Y for ipv6@megatron.ietf.org; Fri, 24 Dec 2004 10:58: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 KAA24622 for ; Fri, 24 Dec 2004 10:58:41 -0500 (EST) Received: from web21323.mail.yahoo.com ([216.136.175.209]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Chs05-0005SQ-S3 for ipv6@ietf.org; Fri, 24 Dec 2004 11:09:11 -0500 Received: (qmail 14122 invoked by uid 60001); 24 Dec 2004 15:58:30 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=tkFz1TWtOXd7IGETF8JhLbfTyA9wPEXiCfEuibv9xQMmkl6W8Wq53Wf1TK1QyCC8qcvAEHgTofN9+MgktNpTGA4tgHiSlZE8LGPT9IDAbolWBPxENxIAZPBnImn6yomZmFT3bV+14VMMex8vUiaTQE3WwCkCQXaaWq3sxgzykiU= ; Message-ID: <20041224155830.14120.qmail@web21323.mail.yahoo.com> Received: from [152.118.24.3] by web21323.mail.yahoo.com via HTTP; Fri, 24 Dec 2004 07:58:30 PST Date: Fri, 24 Dec 2004 07:58:30 -0800 (PST) From: Yudi To: ipv6@ietf.org MIME-Version: 1.0 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Tue, 04 Jan 2005 02:52:09 -0500 Subject: set the flow-label field in ipv6 header 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="===============0045882415==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============0045882415== Content-Type: multipart/alternative; boundary="0-1750063472-1103903910=:13020" --0-1750063472-1103903910=:13020 Content-Type: text/plain; charset=us-ascii I'm student whose doing final project about QoS in IPv6. I would like to asked some question How to set the flow-label field in ipv6 header ? I read that someone already asked it in mailing list a few year ago (1998) , here are the site : http://mailman.isi.edu/pipermail/6bone/1998-May/001583.html but maybe now, there is a way to set the flow label header. I try to setup it with sysctl (in freeBSD) with this syntag : net.inet6.ip6.auto_flowlabel=0 (for deactivate) and net.inet6.ip6.auto_flowlabel=1 (for activate) But I saw with ethereal, the header still no different. nb : I'm using freebsd v 4.9 and v5.3 Thanks before, Best Regard Suyudiana Student at Electricall Engineering University of Indonesia --------------------------------- Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. --0-1750063472-1103903910=:13020 Content-Type: text/html; charset=us-ascii
I'm student whose doing final project about QoS in
IPv6.
I would like to asked some question
 
How to set the flow-label field in ipv6 header ?
I read that someone already asked it in mailing list a few
year ago (1998) , here are the site :
http://mailman.isi.edu/pipermail/6bone/1998-May/001583.html
but maybe now, there is a way to set the flow label header.
I try to setup it with sysctl (in freeBSD) with this syntag :
net.inet6.ip6.auto_flowlabel=0 (for deactivate)
and
net.inet6.ip6.auto_flowlabel=1 (for activate)
But I saw with ethereal, the header still no different.
 
nb : I'm using freebsd v 4.9 and v5.3

Thanks before,
Best Regard



Suyudiana
Student at Electricall Engineering
University of Indonesia

Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less. --0-1750063472-1103903910=:13020-- --===============0045882415== 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 -------------------------------------------------------------------- --===============0045882415==-- From ipv6-bounces@ietf.org Tue Jan 4 05:10:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29113 for ; Tue, 4 Jan 2005 05:10:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CllqQ-0001Vr-49 for ipv6-web-archive@ietf.org; Tue, 04 Jan 2005 05:23:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CllXW-0006Zx-L9; Tue, 04 Jan 2005 05:03:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CllSr-0003yE-Pc for ipv6@megatron.ietf.org; Tue, 04 Jan 2005 04:58: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 EAA28145 for ; Tue, 4 Jan 2005 04:58:55 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CllfC-0001HI-C2 for ipv6@ietf.org; Tue, 04 Jan 2005 05:11:43 -0500 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 4 Jan 2005 09:58:50 +0000 (GMT) Date: Tue, 4 Jan 2005 09:58:49 +0000 From: David Malone To: Yudi Message-ID: <20050104095849.GA12314@walton.maths.tcd.ie> References: <20041224155830.14120.qmail@web21323.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041224155830.14120.qmail@web21323.mail.yahoo.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: set the flow-label field in ipv6 header 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 On Fri, Dec 24, 2004 at 07:58:30AM -0800, Yudi wrote: > I try to setup it with sysctl (in freeBSD) with this syntag : > net.inet6.ip6.auto_flowlabel=0 (for deactivate) > and > net.inet6.ip6.auto_flowlabel=1 (for activate) > But I saw with ethereal, the header still no different. The auto_flowlabel stuff in FreeBSD only works for TCP connections, and there was a bug that resulted in it only being set for one side of the connection. This bug is fixed in 5.3. (There was also an interesting issue about setting the flowlabel consistently in the syncookie case, where the kernel needs to generate the flowlabel from the syncookie if the label on the SYN|ACK packet is to be the same as on the rest of the flow.) David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 6 16:34:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25453 for ; Thu, 6 Jan 2005 16:34:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmfTy-0003bu-R7 for ipv6-web-archive@ietf.org; Thu, 06 Jan 2005 16:47:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmei0-00070X-GT; Thu, 06 Jan 2005 15: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 1CmeYH-0008S4-4P for ipv6@megatron.ietf.org; Thu, 06 Jan 2005 15:48: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 PAA15020 for ; Thu, 6 Jan 2005 15:48:11 -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 1Cmel4-0008HC-Kc for ipv6@ietf.org; Thu, 06 Jan 2005 16:01:29 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.11542296; Thu, 06 Jan 2005 15:47:12 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Thu, 6 Jan 2005 15:47:12 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Bob Hinden Subject: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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="===============0985117173==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============0985117173== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-35697516; protocol="application/pkcs7-signature" --Apple-Mail-3-35697516 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This starts an IPv6 WG Last Call on advancing: Title : Optimistic Duplicate Address Detection for IPv6 Author(s) : N. Moore Filename : draft-ietf-ipv6-optimistic-dad-03.txt Pages : 17 Date : 2005-1-3 as a Proposed Standard. This last call will end on Jan 20, 2005. Substantive comments should be directed to the IPv6 WG mailing list. Editorial comments can be sent to the list or the document editor. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-3-35697516 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTA2MjA0NzEzWjAjBgkqhkiG9w0B CQQxFgQULu9Gs4Y9i24C5Ta7YxDStluHZnoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAOVxnHvWYxMxnziaWEYRwsJ2BcMI+CoMtvcPABRZH/9n+UmYBCQ64PBHZ0sF0Ihg4lDVY pB4Ze+NtjwBm2378vaYc6H2hWDPZ1Z/1O7p3h0vCz9YIxrOnqc8Fk4r4YC6dEE7hzjQ7j8c2KRnq nLgGIOLONCUkdBu5x/FvWz3AttQVf1irnVxwIfQxIpnSJis12PjZeStkZ1pEuKGWwCc53TVUoGu1 4dMrDlfT4mlmTCmtyOeK3wkqbsY5suw0g5yqQ/WNmK4qj9aHUFYBmSOnnIIN6SG1t3MI5S9tCs10 J9ZO+E1793etkRq8rYz5CZVWgi0RUXvfNJeJk8r0O5XDWgAAAAAAAA== --Apple-Mail-3-35697516-- --===============0985117173== 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 -------------------------------------------------------------------- --===============0985117173==-- From ipv6-bounces@ietf.org Sun Jan 9 00:08:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03244 for ; Sun, 9 Jan 2005 00:08:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnVWS-0001ee-Hk for ipv6-web-archive@ietf.org; Sun, 09 Jan 2005 00:21:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnVG1-0007RP-Pp; Sun, 09 Jan 2005 00:04:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnVCR-0006hD-JC for ipv6@megatron.ietf.org; Sun, 09 Jan 2005 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 AAA02612 for ; Sun, 9 Jan 2005 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 1CnVPj-0001Lu-D3 for ipv6@ietf.org; Sun, 09 Jan 2005 00:14:58 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 070DE51B for ; Sun, 9 Jan 2005 00:00:34 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 09 Jan 2005 00:00:33 -0500 Message-Id: <20050109050034.070DE51B@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: 7d33c50f3756db14428398e2bdedd581 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 1 | 24.70% | 7319 | brian@innovationslab.net 16.67% | 1 | 20.35% | 6031 | fernando@gont.com.ar 16.67% | 1 | 19.71% | 5841 | internet-drafts@ietf.org 16.67% | 1 | 12.52% | 3710 | sharkey@zoic.org 16.67% | 1 | 11.56% | 3425 | dwmalone@maths.tcd.ie 16.67% | 1 | 11.15% | 3305 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 29631 | 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 Jan 9 05:51:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05624 for ; Sun, 9 Jan 2005 05:51:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnasg-000291-N6 for ipv6-web-archive@ietf.org; Sun, 09 Jan 2005 06:05:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnabz-0007Mb-Az; Sun, 09 Jan 2005 05:47:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnaaw-00078f-Tl for ipv6@megatron.ietf.org; Sun, 09 Jan 2005 05:46: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 FAA05536 for ; Sun, 9 Jan 2005 05:46:45 -0500 (EST) Received: from [219.150.144.124] (helo=mail.ndsc.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cnanm-0001qS-2o for ipv6@ietf.org; Sun, 09 Jan 2005 06:00:38 -0500 Received: from Foxmail ([192.168.199.165] RDNS failed) by mail.ndsc.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Sun, 9 Jan 2005 18:46:44 +0800 Date: Sun, 9 Jan 2005 18:49:22 +0800 From: "=?gb2312?B?ufm52r78?=" To: "ipv6" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 09 Jan 2005 10:46:45.0377 (UTC) FILETIME=[833F1F10:01C4F638] X-Spam-Score: 2.4 (++) X-Scan-Signature: d7d3f294c642eb492c2d44336474db48 Subject: ipv6 over wlan 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="===============2042956037==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: dce614827510b4050294eeec86a3642d This is a multi-part message in MIME format. --===============2042956037== Content-Type: multipart/related; boundary="=====002_Dragon167653843133_====="; type="multipart/alternative" This is a multi-part message in MIME format. --=====002_Dragon167653843133_===== Content-Type: multipart/alternative; boundary="=====003_Dragon167653843133_=====" --=====003_Dragon167653843133_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQppcHY2o6zE47rDo6ENCg0KoaGhoSBJIHRoaW5rIHRoZSBpbnRlbnRpb24gaXMgdG8gY3JlYXRl IGFuIHVwcGVyIGxheWVyIG9uIHRvcCBvZiA4MDIuMTFiIHRoYXQgcmVsaWVzIG9uIElQVjYgLG9z OmxpbnV4OyBrZXJuZWw6Mi40LjE4O2NwdTpweGEyNTUsd2hhdCBzaGFsbCBpIGRvPw0KDQoNCmJl c3QgUmVnYXJkcywNCg0KR3Vhbmp1biBHdW8NCg0KT2ZmaWNlIFBob25lIE51bWJlcg0KODYtMzcx LTM1MzI5MTMNCk5hdGlvbmFsIERpZ2l0YWwgU3dpdGNoaW5nIENlbnRlciAgDQoxMDAxQk9YIDc4 MyMgNDUwMDAyDQpaaGVuZ3pob3UgQ2hpbmEgUC5SLkMuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoSAg DQoyMDA1LTAxLTA5oaEgICANCg== --=====003_Dragon167653843133_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5mb3htYWlsIDUuMDwvVElUTEU+DQo8TUVUQSBodHRw LWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9Z2IyMzEyIj48 TElOSyANCmhyZWY9ImltYWdlcy9CRyIgdHlwZT10ZXh0L2NzcyByZWw9c3R5bGVzaGVldD4NCjxN RVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFE Pg0KPEJPRFkgbGVmdE1hcmdpbj0wIHRvcE1hcmdpbj0wPg0KPFRBQkxFIGhlaWdodD0iMTAwJSIg Y2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4NCiAgPFRC T0RZPg0KICA8VFI+DQogICAgPFREIGNsYXNzPUJHIHZBbGlnbj10b3Agd2lkdGg9MTAzIGJhY2tn cm91bmQ9Y2lkOl9fMUBGb3htYWlsLm5ldD48Rk9OVCANCiAgICAgIHNpemU9ND48SU1HIGhlaWdo dD01MDAgc3JjPSJjaWQ6X18wQEZveG1haWwubmV0IiB3aWR0aD0xMzI+PC9GT05UPjwvVEQ+DQog ICAgPFREIHZBbGlnbj10b3A+DQogICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48 Rk9OVCBzaXplPTU+PEZPTlQgZmFjZT3LzszlPjxTUEFOIA0KICAgICAgaWQ9X0ZveFRPTkFNRT5p cHY2PC9TUEFOPqOsPC9GT05UPjxGT05UIGZhY2U9y87M5T7E47rDo6E8L0ZPTlQ+PC9GT05UPjwv RElWPg0KICAgICAgPERJVj48Rk9OVCBzaXplPTQ+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAg PERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT00PqGhoaEgSSB0aGluayB0aGUgaW50ZW50aW9uIGlz IHRvIGNyZWF0ZSBhbiB1cHBlciANCiAgICAgIGxheWVyIG9uIHRvcCBvZiA4MDIuMTFiIHRoYXQg cmVsaWVzIG9uIElQVjYgLG9zOmxpbnV4OyANCiAgICAgIGtlcm5lbDoyLjQuMTg7Y3B1OnB4YTI1 NSx3aGF0IHNoYWxsIGkgZG8/PEJSPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgc2l6 ZT00PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT3LzszlPjxGT05U IGZhY2U9y87M5T48Rk9OVCBmYWNlPcvOzOU+PEZPTlQgDQogICAgICBzdHlsZT0iQkFDS0dST1VO RC1DT0xPUjogI2ZmZmZmZiIgY29sb3I9I2ZmMDAwMCBzaXplPTQ+PFNUUk9ORz5iZXN0IA0KICAg ICAgUmVnYXJkcyw8L1NUUk9ORz48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQog ICAgICA8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT3LzszlPjxGT05UIGZhY2U9y87M5T48Rk9O VCBzaXplPTQ+PEZPTlQgDQogICAgICBmYWNlPcvOzOU+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9G T05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9y87M5T48 Rk9OVCBmYWNlPcvOzOU+PEZPTlQgc2l6ZT00PjxGT05UIA0KICAgICAgZmFjZT3LzszlPkd1YW5q dW4gR3VvPC9GT05UPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVYgYWxpZ249bGVmdD48Rk9OVCBm YWNlPcvOzOUgc2l6ZT00PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVYgYWxpZ249bGVm dD48Rk9OVCBmYWNlPcvOzOUgc2l6ZT00Pk9mZmljZSBQaG9uZSBOdW1iZXI8L0ZPTlQ+PC9ESVY+ DQogICAgICA8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT3LzszlIHNpemU9ND44Ni0zNzEtMzUz MjkxMzxCUj5OYXRpb25hbCBEaWdpdGFsIA0KICAgICAgU3dpdGNoaW5nIENlbnRlciZuYnNwOyZu YnNwOzxCUj4xMDAxQk9YIDc4MyMgNDUwMDAyPEJSPlpoZW5nemhvdSBDaGluYSANCiAgICAgIFAu Ui5DLjwvRk9OVD48L0ZPTlQ+PC9GT05UPjxGT05UIGZhY2U9y87M5T48L0RJVj4NCiAgICAgIDxE SVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPcvOzOUgc2l6ZT00PqGhoaGhoaGhoaGhoaGhoaGhoaGh Jm5ic3A7IDwvRk9OVD48L0RJVj4NCiAgICAgIDxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPcvO zOUgDQogICAgICBzaXplPTQ+MjAwNS0wMS0wOaGhJm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwv Rk9OVD48L0RJVj48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon167653843133_=====-- --=====002_Dragon167653843133_===== Content-Type: image/gif; name="back2_8.gif" Content-Transfer-Encoding: base64 Content-ID: <__0@Foxmail.net> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhhAD0AfcAANHs1+//8fL99Oz67O307dv02vT/7vf+99//6Pj99+Ts5PL58vL88vT6+OH5 5OH34Or56vz++9Hu2NTt2On/7uLz4fL/7/f9+PH18enx6fD+7u//77Hess/v2Or66vr8+sf41uXw 5bXhtvn6+P7+/fP/8czw0tXw0/r++e3x7fr+/eru6ub35dHx2PP78/n++tDm1PT+9PD/7+r06fb8 9fT79O/58M/m0vX39Oz/7+L+6Mvsy7rju/j59+//6uT04/P/6vT/7+j55+D23+L/6vP49PT/8vT/ 9sHixOb/7O/278PoxOf15r7iwvD67+v86ur36M3o1ez56/L38uD/6fr898vkz+7478vo0vD88Pj+ 8OHx3/H/7PX89vH48OT96Ob76PL/7Of/6NXr2On/8Pb/9Pv//+v56/D/8+z57OT/6vT77Ob/6szo 0sbrzeX+6fL+8uL/7O767fb/8s7s1uTy4u367e7z79//6/b39/L58dv437bht+3/7PL18/z8/Mfl y9jy1+n66O787fb79e3+7NT73s3w0Or76ej76vb/7vD46c7tzsvs0vb99v7//vv/+/X89fv++/z+ /Pz//fj9+P3+/fT89Pn/+fX89Pf99/D78Pr++vn9+fH78fj/+P3//e767u/77/7///v/+vr/+fn/ +Pj9+f7+/vb89v///vH78Pn++e777u/67/H78vj/+fn++Pz+/fD78fz/++n56fn9+PT89f3+/Pf8 9vr++/X99fr/+/v++vb99/L78un56rjht/3//PP88+b96ff99vL88ff8+Pr9+vD68fX69vb79+/6 7vb89/7+//j++O/77u767+777+v16/D68Oz27Pn///L7+PH88f/+//v9++/97v/+/vj++fT59Ofv 5vDy8Ovy6+L96u747fb49Nfu3OX86vT99fb87/X99PT99Pv7/Ofx5vz8/vn9/PT28fT88eDu3ff7 +r3mv+L76u/97PL677Hgs+z96+v97fH68NLv0OT44cfsyN723v///yH5BAAAAAAALAAAAACEAPQB AAj/AP0JHEiwoL8tTARg4sWwSKlSDF4dyKSMkpkGRwQQkeDDB5UOJUrkgBEAzZsJFiyImWDAAAUs Mix8mSBDBqQaByBhchEJk5dSkBxFOoAJkqlpW37UgjDgzIABduSEEiVq06pVvxi4cHHpUqZIu3zl OlaJVSdWyJBJWhthEi5Llh49+jfqn91/BvMO/GEHFiZKgL19I/rpgJ4ikC5m3NjxY8iRJU+mXNny ZcyZNXlCghTJiyOgn5SEc7T5k6lhLCosbQrVjmtoVDfN8vTr17CutyKlylVMU6VKp9Ai07V2EmBc oOTKvYtXb14mRmAlq0hpGYEDMZIdMHUqMUYBajhy/9HR4jFJNBtz5Aif0rIFc2NSRiIN6RMmTI5c OFrgpegBLzF8gs8WwEBwhlNp2BFKK1SJMgtWDAxz2yVgpSLWMRd00gkynXCyliTGUQIXKKjYpcpd zuUFxQEMKLDCMi8sY4opV0zjCHfeZRSeD+OVJ9J56a0nQXswvRefBZ84UhQmB3wSyWil3OcIAd+w c8AGFQDjgVOt2dEKNE6IcpUxWXFFoW6paKImcBoiow2Ik0wCypyPoPJIXSimWBAEZbyigALKvHCM C4UdkQkBd+QInng6SBBEECNtYAEeHagXx5AWvGRBCWAcWUMkmy2QQX9K5nefEn+WIcMPEHjA1FOu hf8y1SbUZPGLMVt1BZYjzTSTQCW2sILCC2qxRYkscMWlCp526bmnEUdMg8ELkAxqCiywOJJBChZ9 t+N4jkIKg6SUWoqpppweeUANQNUQTn+flGLqTQQw8wmWBb4KayiuVLXJJrRFOIw6XzniSJqVdNPJ sJwQF6cwlAgzp53MNeesQExs88knLwB2TCmmvCJRDUV0OxEbE3ARRqOPRmrBRgEEkMQERhhBQRub wpcSZznhJxQB8RJVSmGmlIFIlhAYCKuXzFSljyfYCNxVJrvsouYFlTyjYcMOTyILsqCQYOco2eR5 sT9MrFgUYMpk4sgVV8R7zAsXnZzyyuG6DLPMNNv/jHMJOltQA30HNHkAAY4coB9QRq2SmiCtPjVA KwrOugrUtg1Tg1e7pGLhr888gwwnyPTyYZyUkCCXMxWfLVAdTGSQDGC8pJBB4tkqsYzJmaDMhQVJ ADCHuJLuPXPNFNxw2QQbbHCAkjp5sUApOC1AwAKlVcPOD6x6wJprCsK2ydPGMBDhJbdQSIMjuWiS wDOVbDg6nICFrVzZZl/8Qx0K2ADYC3dQQA2kFI6S1a13KXuZ8OYQgHG9TAIxO57NlCcT5m3AYPbZ zwJA9YlwKMALm3FENUKQlKVsSXIKkgZVZvMKrUjoTLvgTQKwpiEUkI4toEBOch7BOua4zh+wm8YB /yjBixcUwQUHSIYA1tWxA/rOAmoAgBEy5UDj9e1mMWlU86A3tOd15gCdYVeUjFGNChDIe5IbgKwa dDlsZA43u6CBWNx3ClsszEPFkRMoLLHDE+XPWVvYhl+ISIljkOIoNjDFJxjixAQGzwL1SEIVIcg3 5LUhixLYYlF0gsEM5CRKjCuaELYAAS1xKVah2ISDZmM+CWWCQl1wxNXit6GGgSgCuJBFcuw0Fx+6 7gdlYNIxeEEJbygBO0kiwBTo1oCJzCwlRKDDBvpAgUlG8IpFmklIDAaUAyjBC4X7hAu88AlIlCIS ZTBFIbKkpTQsrRXRiA1t3niJc9AgFb3xTfxYwf8JPIJIFiLaISqYZbGLnaEMyWBHCk5BiTtc5xOw 0MM3MMC7ZyrQAjKoZvEoKUH3aLMEzwPKk65THyWQVFQzKMMGlKI0ycnBDszo14M80crbpAMsvcEa sNCiC+JEQBKWeIslUIEKVXDDl2cbQAmq4aKKTKFJSsyEEipyQIvGoQMy2EASrGCEPpijHCWwQA7G sAYt5MANMelUSJq0mUgoYQGYWIDBIpFMBYRApUjbkju9FIqY/ssTND3fJdKxC1617zd2fAEe4xSn ocZlOX/UExRK8IoZrKBkvDDYFY5Aikws4xRVRYkFrto8SW70mshDqwXUWgKcDC0SdIWEEoZSzk// eCEcMzDFBkh5Qli1Qg4MAhhgXzEMF9zmHJ2TpT5ZISxOvAlOdJKLKvzYLNdlDBOw+MAotAGOFSSA FJ9Qhjd6QIJR9GAiG2keArC6gThw1atgFStZzUrBRgEBCI7IRAQe8YcR9CAPtKCFFzJQsn+MwBQH GGW+BiAFqLSiFf2qShZaGKHNwTYsxbgA1szCiV4sVo+WUJ1cmDWEEpv4xCgeQh0gEANYgGIUoMhD LHIxOFLkogfLOm8m0ruB9WbVtA9E7QQxeV+DycW/H5BFLOQViVOcoh3/OIAxWEAgLQ3AnZQLhTT6 BbCsaGVqYPGFLyrxq1OMLi1sccucHnunu6T4/80mrsMPbPCJEWsjAQk4QClokYARPEIxGsmkDE7y KAq896thHWtZIYOGRqXkecIQhiXWEQFh3IcogGHdKmZQgQokrbetgYZMZ3Gr4k6osJooRi6Ac4pO EIs4a6HEHoc6YubAGc77q8YBhBEBbXygCLQghSMSUIr9Ajq9MkCZAYKQhBuUwKtj0MAgOrXo8zga SZlAgTDsEoERkGYnHfvHOpi6BRYsRV+tiWdVPPGKX7igBreB7fo0gaGyCCePOtzj6mx96xTXoQ5X gMUjtDECHMSis1MlBa+tcY3FYIoNY0AHOvpgzUraDAZoQI8E1pqJWNDiD+sgOAhL4YUpnMIZo/8w BjuSkjSluQa4/aKGcMv3Qnkr9zccnh+IRCSi5fSyumerg9rkEgEcKIMQmYiXN3AQAYY7PCXEiLgW NlDxjmJc49s8QIDz4Ac/F64GLjjFC1BuCif8YAu18B6XoCKHaLjCKpgz7uZucTBH9AZYrU7LYikx CT7Wqc2RTRETNIBdhj5iBAQgFClIoQcc/Pk7yD6JIsxa9SveoCTi2HgJylCGABd8BBE45xVeARhZ fKAwiEB70r4H3KaJaTZlmpojulAMX9GQQ6YrDiXeEjaiEvSHECjBJ66w0MPLVQ8EqAEt5HJsQUte EXrjqOUxr/kywMPjjxDGB3CgBEfEwAbHoMT/CMCxik/0gaWgjoooXOGKy70CG8bVlW5UjTVb2HF0 eISEJeSkuqKO4uc/JARlcAUuskzHcACkYAzDYFvkQAvmhV6ZtAGNUgIbQAaVZ0nLowiKEANlQAql 0AMj8AKnoAcHcAQBEgndpQAHYAG81VIOJmpOcBU0lSsUsguxdFi05Fyno2ZDxUvU9UOCYARXEAIp sAzV4gWkwHk1kAEY0AsPuGMRyB6FAGRWhIEVpIExsAp7hgMrcAcvsB0xwACY8Al+sALsUAZ9UAGQ oy+uwSBv12W2EX+3YIOypFNnoXMR0Ba6RCJF1TquwwIlYAShoAyxQAkvUAOkEAMxMCXv4IA6/8Zj CEAHNWGBp2VxWHSFilAGw0AKtNADKYABpbBEJggUI+AHAfIEBGIgp7Qg/PJ6WfFCmZAJsSQWv7JP /VQclRZddbIsgeccWyADGxNshRQv1eAEQ1MFTviIEUgEWDVaF+g3GZiJnUcLH6ANpBAL1RAD2AEU MIZgo9QqTLFXUhFT7bcKLWRct5EbjuALmlB/8WNDpoM6e7RLytGLerEFQpAFnxBgpIAB3ccMq2AK NUAIpdB8GyADSYApVCh9yHMDB3ltivgQI/ABpZALVyAAqzAOoGIGZlAGzPADqrF6S9NXb0hqbqQ5 mUBYqSBLtYgWHSIJPxUBAWU/3PB7v1QBIf8gCntWChmgADfyCZkQDlNACwYpA2pABymRA4cWX4pG Xw+JKWVgDKVACuM3BbHwCdESAiBkBvIwDSTEUlyyV331L3BoG17xFfg0FhfACnbECj0FJ8axQ3fS Q0B3MVTGDnBwH6VwBxmgSGXgCFNFC04XaCmRBBG3BjngbNAmbdRGeRlHKTFTBiUwlR+AAQ5xBAeQ BkyAPdUyDiunGh6ARq0RCvEUgxDyRpFwTzhoRxrSUz9lHH1HJyfCLD9UbthQTlqnDI7wCdNQDRsT C7EwmBsBdWOgBeiglH0gBmrQAjUheVpQTY/ZATETEqZQCtVYCoRQDUdwBFlAGpRgFB+pegf/0mBR sUai8DTzdAnxFkvF4AsXkACseUOSwHe48BZi8wjThT8F5SxMEASLJxeUcApRYgMM4CQqYAaq0AOL 0QEtQQwTEDNkEAUWEAQf8Sgo0zyJGRPr9SjPsyQukAmkgDjChoCf4IGlAAXxkHYGkiDlGVPrFjXv Jn+7oQmrVke1lHshEmK05odnAwVGoDjk8AGUUAS34xdL6AcIqqAawaAG4KAQKqEU2gEWakEZagEb GgSF0y4EkHyk4E0ZAKL/YQ+loAF1sGBOUTkq9HasZJaXsAupKUuVgDWxwE+9UCwgMo9howqQtZ96 AgFGIFEr0AOUgAHktJ0ukAF+oAIJuqAN//qgARChE1qhQXChG1ClVzo4WnpMhVEDxxSiCvANpmAE YNlgDhYKsOEgtBE1rjQfvKIm8FlDavFTcAIXf4ef9pgXfKIHLiKoiIEJNvAK+yEPiqqkzNioTxqp UjqpVEpBl/oZkHAAGwQJBBAJh4RgPfkNkvkDBcIa+9I0sjELJ/lCubGSa3IKCnOLseYWceGDSKU/ 0HIF0/IIOOAZAgALpeACwrqoS2qsjwqlkkqplpqshVMU4oQTXuQZpcAfqzAMT6CtqnimChJPcJcV 7uYCt3AOb7ombdlPzzWfsiAxdeIMR3WrBrEFSAILkBAxftB9R1AU+JqkjNqkjgqpUTqlGP/KrAIr NE4yFM/qAsmnE0YxZWDZFO60IBAmG1kQMBMSCV1gITlFS4r1IW0haY+lCqhAl/2WYlsgCK8AC98Z AeRAbK4VCe4As/sqs8das8p6sxqarIRAbNeYC98lt6WgDN/lcQdQDdzTcmcKFfzydldBYeJKA+vD jr+yIcTyYcjyCFXLHA/wuJAbuZL7ANyTAa/AC6fAa4QgbIXhBfJgtsWKtv2KrDZbqTj7KDWQAMGW C0Vgt3hWCt9FC7mAjexQAayyeuT5YPI0T4KVG7HUDHaIFoulh9HlDKpAl7WZEAvREA8RERNBVZDH ER4BEj8SGaJFGS6RTTRhEzihEzzhE0D/IRREYRRIoRSheUpeIg1O8C+rEK7o8xW70Aw0egF5Z0Ns 0RZ8RGt7yqcpwheDFBiDMYaGgRjN1xjUy2iSoRIskb3LkxmgwhkIW1KjURqnkRqusqLg0wpN83bY 0G5sSlg00D6+0WooMBw4igtyIhckMF3typ/RMR2AYR3YoR04AmjfQh7mURJBwh6ZUiSBMx+lISX6 wR/+ASACQkqRcwYsSpIvygDudgnqcAu/uyZakxYeRj+SRiL7y7/OsSIt8iIxMiM1ciPdYcOM4iOM tsPn4sNHkiRL0iRP8hlSQiVWgi+qSJ7h84a0oYDGlRvJpU+nYItsMZ94ujo/6Dp84ieA/yIohFKC h5IoZswjLEM8k1IpOXApRLIpnZISnxIqo4If+OECp5Iqq7J6SoxlC8J+M+XENdcFneM+v9Em/uQ1 yCFigFeXzuKn0TIt1eIC15It29ItOsIoeeNA5XLJa6zJ6sIuN/EuYygvokwv9oIl5wYrfqtCojBc 7paO49obq6Y1HVIsbdF3j5UcNnk2GbMxHVNIICMy62JAzYRAKjPJ0SdkN5MzR8IznPQzQYMJXVQ0 R/Np3yMrW7ZKtSGuXzF/v0FLJlwcQWU/IwaA1qU2KUsJbfM2cVMKc9NI81zMldhRfxM4g7MZ4XQ4 ibM4m2EKjuNpagexwOUvq+DE55PQnf+zavWXuLAWAQBFtXYysrisJ7AjO7RjO7gDmLvD0cAjPJCy lIk2X1U6E83TodEzPdVzPdmzPbeLQuXJflZxOeYTozZY07VoR6TzXMeSLCTCDRTz0/3LP/5jiAE0 QPhRQLzzRESwQAGgmPDBmE5NQVB9QbuJHwsQrR30QSE0QiVkZe7kt7MiG+2Gjpngx7ngnmzCCooV j8YxIsryc1ysF0E0REV0REm0RDXQRPH8RFE0RYaWnMvZnBMweZeoRRdUFF0kFOAURg+BCWRkRiIJ Ky9dFW2UFTVgYevTDJQdP4p1i3EiC+Rcj4d8NoE0SMRkSIikSIx02o4EAJCUBG3QBzn/QB6SMhNr sAaxHYHQs8+f4Enm5M8pXQbfGJp4LBVb9le1gZpM2yu/Ep85XT97pDqjwMJs7RzAJEzEZEzINCXL FFrQRAdp+6/Lujzb5KzeBE5NMk7ldE7ptE7VfGVqBGF6XD5PTCEGwytlFiwdAmvLPY9FlQ0SfTYH lVAL1VAPFVETVVGiddcNnqwA69cTsFbOOlI5ERonlQEptVJLgSBiic1w99Vd4abryI7xYwsoYEMe wlj5GzajcM4Xo1RMtQJOBVUCIFXQ60yidVU5XrpVylpsxRlvFVdzVVd3Rc29lSAPxmVWoaoTclMW 0o4JEBwv8JLaMM7J4t90QbIFMVmV/3VZRKRZnOVZoBXPViWdo6u2O55WYxASrrWz5TRbbGVbuKVb qfgq4CMHsCFz7XvQXqGSmuArfd5qHYKjM/lYPHox15Vd29Vd3xVe41Veyqhekk6zDs62FmBf+KVf /OVfACZgBEYJBuaN4okgXtIKKiQbm1Df8eemqdAMh2UWzfUmkKCufCRiBJW1KLZiLfZiMTZjNXZj OQaBvn7ma2u6RIZfjnBkPZBkSyYUTgZlUkZlJqTVGry7LoQ+l0AD80GjvxELpGNL+IssfjcX1EXu JyZndGZneKZnfOZnRXkS8L7jJXFtkCZplGZpTPIXlKBpnOZpLQU+pioK60tTsYc+9//0tApz4jhK zg8/7hJfYrm2a732a8E2bMX2eA53kCiTwyZxvQv8Eh+PKUCpbdzmbd4bbuOmAOW2YCiku+3XZS/k FalwT+2oCZ0g5S9pLMnCZhG/8yoGcAJHcAaHcMqgcE3XcIRpARCH9AmMvS+RcRvBcR4HciJnTiV3 cim3cubLhqFA6v7iRpmTjrMIy1CLrpKwh35XF899MUJHFERndEindEwnnJgSdUivxkTC95qXOFvX dY/wdWE3dqNQdmeXNAfyTqcKrjM4ISKeJhoWC2aWFrHaWHJ5IpfPn4QHC4aHeIrHeI638T1evRqn HjzM9GiQeSHBeZ6HA6AneqR3LKf/dwCpd+TQnkKLHzVPHNl/jGdtsiHaEOhWPjHLQpuILHzEdwrG 5wjIp3zMF70HSWiUDBB4OuTIEUeCBQsUsARAI05CiRJl4MWi9UjYBxxKHMWwcYzSCHCrPvX5UQuC hwED7Ky0A82VqE3YsP1iMGzYpUyOdGrKVelUp06cOPWSNGkSJUugLFl61NTZP6j+pE6lWtWfkDJX FKyY8uLYAVLGhn3yQo7WqB4HMhGRsGGDDglBguSAscGCQIIGESqUYeHLBEWKYpQhVarHiBen9Bw4 EuNTJHArFBywsOXkmZRpVLZqJYraJk+esNW8hHNXKl+aNF2oBHQoMklFJ8kCBQrV/+1HUKNa5S1V kJErIVIsg3TMC6kyZWpkwNALrVq2btXEnVvXAtsAAZJMMGKEQpu+fwPHWFWKFo4Vd14cMBWDAaZP flawK9OngkkPZzDbkcPZ1SbQRCPtklu6oMGR1RJ4xpZOkOmFk6IoOcoSEkBxahTdeuuNhRKMCEWZ WCh5oQZSYojBEQLeOSuttdraAAE65KLLLuy048478PwCTJEyhiGFlh5SwKAUARiLoRRIRvDDsSe2 wA8zzfoTxQmYVhntphouiaSLVBzJZbVKKnmBE2R0iU3CpJp6BBVVdPtHQ962kOGTT2ghhZJjPiml GidK+aQK51iMbgMiOphjLiuM6P/DnHJKsCCHMdbQIocbwtsxOVpo+UAbUmKpJoYDjoRkFFBMOUAI J4GBYID9+HPFif9Co2kYF0rbxZFUNAkTKBSEik22pZh6xJk2M4Szqi2EyKJOOzHQiJlVTKmBkFLM aOAIAaKTIQkJ5pgjgBtKWHQMDQYBI9JJb9hABrgQMrGUUkb4oJRcrhBglXEigcQMM8pg5ocKLhtA s5U4EwUmT36Z9aZbTitGtQRaY0UoomRDiilQVBklG2OPnQrgEEQxr5QMFHDElE8yCWcKWqzFVls1 6DAiISv6EEONFmSQ4Q3AtPhu3XYtKMOYUkgBaYpYPjlimhC82FceprcoCQIIWrX/IxRmPANN4Zpu yiSSVHL5krVOWEEGQkkimG0pVCx0JreOPfaHhS3YgQMTTEq5IwOUy3BECWVoseaalw+yIIkxLKgn iTb6yEGHFuz6a401vkMDDYGyK6OEoj/AoIhSjjggDSYWgKS4cdjZIuD8UrJDpVBa+W+TVRh4hdbS IqGhS113NbvM2IwK9hFQMCz2Tbml2oIFbD6B5ABalHHkk2mqoTOWWAYvHCFixtigDwo60IENQ0DQ QQ0EWuDCiCSwuDzzACAypZRNSyGkmiOOyMIRSCiBxJR/OWlV+mFJK7IGIFnhLhOZoMEucoEg1jwD GQ4iitrQZAlUNEUVT9lN8pgQ/wRSkKIplDhFKTBhAwY8RgVmUEUPXtYBAxiAGBPIDhmiYIEgUKED cmHDBNxCqb4gYIdBOIAjMAEJTLggE6QggCNI4QiwfKIwpYBCPFSVHykU0BX/mUXCfoE7nKSiCzxh zU/M9qDYqA0XS3kEU46HvORBwQgHcAE5PkCJImTAEbDAxHL8wEIXZguGMqRhAGyIQx3y0IcbAKIF hCiXAxwASTUgAAFIdAAlZGCJB/CCPUqhgToAAyVnIJgcQiGKl2xiFti4nU1uEYlInCY1CbAFg4aC NqPgQikW0pibkicVCBhBD99YQQ8ogQEvKO0ILsiAH1TQwhfGcIY1vGEOh9jDH/9WypFDrIEjJkkA JRzgEweoQTiZqIBvmMIIPzhJ1VQygNgdjHareAUDGFArLR3IF764wAU6YYteoS1Ck1CKmv4BNzjK DQJl0MNWjFkEJNrgFY5YgDyeGchCSbOQh7SmIrMZRG5683kL0BcBIkEKU5iqZN/YHDurRsCCHVCV nrCnTbQEtofpikET04aZBioLNT3ijb/0xw+McIQrYOAFj8CBFxwhAFiUwgUWhaYgNUpNRF5zkY18 JBEPcMRPuKAGkXREJJxaigV4YRXDeMLU9JOSAcjhaq9axSqMMSsCxXJ3xUiAgmwxMV2gTW21oZAG OdZBuW3BAp+ARf+E4QeNHOH/iFMFZDQJidWOBgGbjNRmVyOZt8dE4gDPc4Elkfg/Y7DArXDlTyhO SbsEuqBWuwAbBP35E4rJZhJrtM2wEPqPIQRXuMMl7hC2IIhXwMJ/ESBHAkox1lJEwh2VteplDVnN RGp2q50dIiGc26lcJIAU4S2FMsRLkQNU4wdTq1oW+dOKUyJMYS64iZZSkYpmpMZ3QYFQBCiBi0mk yUK/fUCBDXxgBD9gvRl4BS9OIYwIEOKJ4/SCPKibUetyNLub5So3E2CnXBTBvH0thXhpkQtPsaMC Ll3VwFbi2k3It2u529LDwsSKUyADBQ7ShhrZZlAMIdZjW2CCADDBCySDrhS2/1OLMijhsmxJwAc+ 0CFE6MIQniFEDBOIIV90pDNIjBWJLogEJryApLJ+9X/TkBrV3qoSOxjQCQhMGH1dcItX3lcTETtF N15wRm0YhbDC6mXcPPYDO/CREov2xje+Ok49QBTKbJlylUtwZTRk2QJb7jIWLKUzMp/OrCL9hBLC wT9IfMIUw2BBwE7CKte1Ihqzw0bCGFCaW1ziVpqw8Y19lTajEDRNjxjF8YjKBCPAIhlOpsQyCBCq ZLDnFPu6lgCm4wMuQM7KMGAIWwgynb142gLmSJwFIoHqT+DNES6gqBeOyEnH4GMLHni16/oTDYR5 whgM+GJpGBiJYnypEs9ozf8LzqbbAFuoeI84bEI9BoUDMGAry3jBMlJ6hWmcbNpQvna2W7Dtbkvg 24bzMrkR8gkjIlGckTi1CTGBom+w4wAbqICqoOS6+Kqyi/0extccphqfsKJBAi2KMIRBvKb8g4MO P9ZCX6EABSjDKy4Y5xEyQYA7UBtbHYeLjKyDl4KQHAsWKMG5EFIDfUFiARlwtxHXjTclQL0MMmCv 664G3y2u8hVfrC8sHeELvobpFKwYk5mCLeCmbMzQTT/qNJRaHBeYAhawcEQGUvDkanOdOjO6y0DC Hm6ym90C5JxkONytp7eHmQDM+ATNT9I6nHcGtnu3KYHEOMswMSigaZwNJWz/k0E3MR1OTNgGnV6w 6GOUwhSveAU5i4B5tfSQC2HoenVoJIHsbKc73yG7yS0ACdEiUSeRIICevuon9pQBEa5+awE7A5NZ cM2msOySwFsz9OAJD4MaZNPihw/xI1o0ZciJK7gCPTmGF7CW6JuA6as+zqsR7cOR7iu3bjqdSBqn JqIjkfqfVWg1k8AMF3MtfJuzWdi7e8qrWEqFYigjBikTwzMK2mCjNjG2X6oDJsiAZFg0XkgBPToA ylOCZYC+TJC+wwGAQ8mBRFmURnkUdGmkv3CLIjoiM1uA5zqABSAA00m1amCH9RIlD5CCWMMahFmF +RqGGnil00AQnbIlXYAN/0iYkGBBhbfxpV/6gTpQABtYtBe4AwWoAXULh+dTwCFkwOswwm8Jl3Ep l3ORFCdcJJ1IN4oiqVQLBwVwGkhwhGoIAamphfxov6t5LdqZCfq6iS3BFYhpjQkaivyrjdrQIDpM HhuchgOgBF54gSJwgQNIhiKpgeMTRCJUAwCYGQqomZvJmZ3pme/oC7hwi5RDv7LyggMwqxqAF0ww hmqogC2wufbjjFkDkBK8p/pSBxrYHdXQhLJ5gV7xKbWxBFlgigz6LaLagm1QNF7AE5SaBhtAGSTz RUJMAgBQHMZxHMiRnAmgnGS0gGXcgJQTv+nJgNEyIST5nzJAlSsCQf6QA/9UEoUumolbozHe2TNb GLzc8i9ZWKOkkMOhqsMywIQDOIZ69IZwcgwU6QpB3A6EIAI6wKwN2y5LgQidQBJMgkZxcoFkgoTo KgNTKARXeyk4wzuN9IRXwAb6yp0u4BKI+YmhqyAJSTg1UQUaTJ4zKINkYIcUOAVKuINnY6xhwgAh tMlC1Emt+igdgYgiQhKWe7ZUUwK8XLsZKIMNcCmUcLG5gr+ds4ks2QUu8YWeGDigmKBfecNdUpMg E7JjGYASqIatcLIpECddzATAacsJQIg46AC49CjO6otzoUvnAT8lWABMWIDxQzkCUIAQ8EtXa50o wUj4WwWo7LdX0p2/ixj/VKSgX5EFYXNHVHhFuYGCEniFGViB5+MFnbiCIyCFTFiGU6jJ0LSA0SxN 7ZLL1CwB6Aot51EC0XIesgiHGTCFDchGqmEt15IGz+DNevoFfNISU2SNSoiFThgT2Ag2pLAQSyg0 yhy+bcAEWPiAUdCGyBCvT1AGb+gBEniOFnELIfJODtMmuAACIHCETIiAR/iDEeiBPMgUL8iA5/uH ETAVVHEzq2kFaXAFatA7qcSnW9gdL+kdoTsbM1Eb4bEQ4HOT4hpS4aoDCIgBWCgeUMiDWMiFbhqv HtAYQXGRC72urDLNRtrQDnWEphjRD5CFWCiFsjqFU2iHfziA1BKgFsO5/5cQhdCIStlimFjaiUr4 q9+pGEEDhQoxKN0gUiKtgx+wgU9IPG3oK0mihQQYgUeYtLY4RgzdLoYImiIyOktYhwgQBrz5qkV7 ilWYgQpgHdZ6MWlwgs/won7LnZ3QhAMAigZxTElACmFgI2ILPj8dUjushgOAMG34gCKwE0dwLhBl 1HXpIZDLtO3kNANQiEg1nJRBAWGAiggYAf5JouP7h3XAzOWhGtxsrZzrTfukyo+sU1aYGDSKgFfF BVnY08mEilotrjqogyuAhUfQhhHAgViwTsAhBQjTnihDCDYYg2LVNGRViMthC7rMBIr4g3WgV6cp BS+YglNwhlEwBtVhp/9OtDfZmR19syd88rtc6aeCOxvYsJiCClL/05A6AMCmiAAcUAZCyAQ98QYc iAB+ZQvuAdhL4zY08LYcALeEcJ+dfYgSgKJMyQM/UNRIqgEXOIUXkFhTcIIfUFNP9A8n4E2amjHg dIScwkqh0IYz8b2k4KXgOzYNQFCzfIQRIACqCyE9wIFFrTZt4Zli5VmfVdaGEFpMoYV6HYEIiK4r eIVFk4UPGCdEmDfY24zO4KJaWxgt2YVdaIYEsYVuMBsyORP9I4E1WVeigoAS+IQrKEu0hU09sKSK eNvCWRee8Tq7ADu9+FmGcAiIkAiKsAiM0AiO8AiQEAmSuKKBgTPXqhL/mfiiju0CsPGFvpKYX5sE SFgKIOXTAtUQrNAKrvAKsBALsjALCh0UB/w6z2tdLxMPwSAMw0AMxTCSx4iMyaiM14OruDIlWvOi qdyFBvq7nniGVgWeCEkKYUlOhCKq3wiO4SiO40iO5WiO7HWR6VDd68A+G9m+HAFf8jAP9FAP9nAP +JAP+rAPUQLBpkylWdgE+auVhsnPXUEGgxvZCLAEXDBJoRrbX+IQDwERESERE0ERFTlgC40R61vg 7LuRgwTfHvmRIBmSImkMJFESJhGgzNAM+IpRb1SY2qMtFVSNCxi8oBhZYDPJ3krJ5JETOrETPNET PvETQMFhQjEURFEU/0ZxFEhhRG0C4jLIlE3plE8JFSQhFRZ1Eg8Ypde5GmiAia2BYlI8NxWMmG74 K6HApf9iowxSvOftjWRZlkwhBWdxBGiRFmoR1m3plkMUF3JTxCZUF3YxnHeJl3mpl3vJl33pl3+5 TbhqBVM6GFFYhW8kjVtgINSwsW7ArcqNjRUO2zWBxzqsgJAZmZI5mZRZmZaB20aNGWEkRpzRGZ5R BJ9pA6AxnKEpmqNJmqVpmqeJmqkJzKaUKTIEx2FoGLARG9b4q6wMnpIcsOLR3Beum7vJm73pm78J nJo1HMQByMZ5nMjREYNsg/chzQDYnM75nNAZndI5nWNIndXBj1CVtf//sFq8+pr7uq8wsd8G0QY8 pYQYdCNUaLh4ZB7ngR7poR7r+QTs2eeb/Z7wGZ/yOZ/0WZ/2KejskB/60Qb7wR/94R//AaCorYUN DsP3q6t9q4kzzDPAixih2zFOMDySlNXk/Eq5+aAQGqESOqEUioQVqioMmyYrzawMBSlISrkkWqIm eqIomqIq4l2CiTP5BBAr4TuvqS2eCDrXqCD9Q84WfmTekCM6siM80iM+8qMLGySx1rC4PM1tgiRJ Uj1LIgVM0iTK7qRPMtI9tsiVcGJVoj3ZuoRzIGSgY2eDqxhIkAXVdsdREObkCaZhKqZjSqb8YSZn AmvF3ijsauwOk4v/bvqmcBqncgKL2UyndXo1MEyDOJM9aqBPmphKv8vRoCPXCiqKsLWNjbFqj1mo hpJtiDqhiaqoi7Ksxd5tLOUu3xYpKyypk0qpA1iplrI5KWiV/pDRUARHnADOcryxK8YlXPC9ASO2 ySQqo0IqpWIqp4IqqaIqjMrtR5VLz1KzsBqrIho1tFIrtgpnWGutVogxT1gl4e27XSgG/eoG13CQ 4AlQPc0grzxZSF6sxqKEx4qsybIw3L6qsd5JCB+iz/ITWBotOjKtIzKF1FqtNFBuU8o53rTPqcyE VDgNMGGQBtEFrwUW/b2N5OzTdh2u40qu5WquKoyu6brxDDPv73Ts/67yrqJpUvEiL/PqFFpIr/V6 EpxrCY1VmF8ojdKoP4HjWiyG1QG7jeBLMEI3sAVrsAeLsAnjJBtvcBxn7PM26yCogQ8bLxHrK+cy MRTbwhUDBmDg4BdziXkqQ1I8jUKu07IxG23w2kkQhnZEuqp28TgpsiNLMnhhskxwMkattA4I2GPl smQVt78AMzFLojI7s0sUrSFnsx/YYIs0JVHfOeGlsRztnRbE4t2KzDVxBpKuw0TDhEWjhEZ7tAOI NK2LMl73dS0D9u+dAFBLOwvPy1M7HVVjNVeDtZRohZY4mC6iqX77GuDstcZURaO4GOJBBUcGbKtA NmVjNmeDNmk7d/+u+7icDbmRC7e+8L5zo3d1Y7e0ejcviDfLWNMCGlUEoglb9jug2y9OYHVJsIQA TQoMGfBfgjiJWwGKszhTwDiNk3gp87i5FbmeFbuMLzeUk8KVazl1I4CYm7maax0w3Az5fMqEsSmA p1/9ZGdV9FE2+j0C3dwyeLqom7qqu7qs47if397V7V6xCz0KTLu1a7uXcwG4kzu6o5r2KhjX4iLR gGLTiKXU2LNTsCVcOop2BFJV4Abl3O7Ge7xjiLzJq7zLQ3tsU/vOy4u2L7tyI70wMz34EFO6Vz3W c733hLOrYYYtiglbmz+Vd2qhIxMqlw2lwFyG+wftPhbiMz7kUz7/5nM+IZQ+6ts864BAH26DCUQI 8Butlyur8iuF8xsnU1A/1hkglXBfQDZVm8gE/MyV1fgrE8bfPKUQVFD8xcd9AOwfShhARyjAA0zA BljABhT+6+thBz5+C6jA5xGnA8hAdgOIUpAgmVrFokItCBAGMLQTqpUoUZs2efL0apiLS5l2RXJU LFeCSrY6IUPGSZukCBFkUbJk6REqVar+0fzn7ybOnDr91WGSIRklSrxSZHB0AJYjJcsomWlwIBOb CVwsJAEwJ0gOK0b6mCtXwkKOMWu05Lghw8KXCRs2HHCECRImLwtK1TiwgMCCgZ+qsfvxo5aHM1Ia OmQmytWsWZ5+//0adulSpF27HGlKoKlTJ06cdKGUNKmlJRKgHpGuaXMn6ps/6iiwEfTFHQU1MGFy FK4IU6dQpVogYnVOgBsluI7RMAiMWLJm0ard4MjRp9oLFkSC9CmcAi8DHVULseWvBwhnCD+cmBgb g2HqIXf0pen9SMy6kKWkNAmXpdGoRo0ynTp1T9McINQLRbhwQDICHFDDC7k9FdVUagAQQABkRGFB EFR0EEQQUa1V1lk6SLCWW5CU8klbkXhxgIo1lFIKJsZUU8EWEIRHmBytRCMRRYxhpJE6HTmSiyaV YEaSSZJ4Nkl+L4GCimmn/afTFtvAgolQlBxDiinT2GDKJ7zw0v/Ug7xVRaGFGGrIoYcbgGiBiCS+ Bddzn2RwgImYCERQGUJsAcxCDKUxgEPQTLSKJ9g05tgltziSSipFVjJpZpwoKUlQsggDypOkZVPT lDv9UAYmBxzDCyXeKHFADJ84QsAUL5CZSRITWNAbHWhemOGGHTb3ZlollPCcQAcoseIBn7jgxScm RlKGKYVUYKN447VihxyGTVQRA+k9douQxUiKWZIpTXLfSy/x1x9Noep0RhnJsJPCKZTcQUCysOjx DQYO0mprbxNWuOuavn64XLAltCVQJOHga50SDy+QwQxlbPADoB4wRKhDEW37yyveahRJKuIWeUos 8lk6SQQuWYL/SqfcsCulu/4MUEI1CqygDCVTJJtgJkrwPGutt8bRga5q9trmm8gJm+xAkSixACYL PBeJqwQoEILFFQDjgcYbyxEKNB5X9AsDLjgGLg3N+GLZKeRaau65+ZEGpX813wRFCa/MsAJuvDx3 xRGkZLLMKUQDfHTSvLL563JOl1DXiZFgDYkSkUD9iRfhzGDKBjUqNMBghD7kyibJWKQoo5Z30Ywm F1TCStydSLLyZ/iRRtooj4Cqtz9MbIMJLB+Mog04KyRAyifKeNMDCaP08BQRI26AANIDK/34wSFK AAQQjmQSwSN/jNBDHrTQ4kUGuP0zgikH+AnoeByP7Yoo1Cj2/8qij0VCg0c0kYtKdIMVrECGNjgT Ac9wilOlMc0QIijBCVJwCHWAQAxgAYpRgCIPschFDRxBilz0QBXSo571sCesHMAgAGh4A8DEMAED GIACWPAe+J5DmvN9QBaxKIUjInGKU7TjHwcwBgv+JJ6N2cEh+JOIRRjQmG+lggaRComRWKGZuZ2L Eg6MyUxqUsExSrAOP7DBJ3injQQk4ACloEUCRvCIphxBANXbgAxguMIWvjCGM6whFlwoolu1RRjC sMQ6IiAM2hwAS5Rwxj9WMYMKICQ89SNUK/C3CWpkgTH9i8xz3DMpWxywXJ/ZFAnu9o8w/oOMZFxN NQ4gjAho4/8DRaAFKRyRgFKQj452HJEMorJHF1YvBzlQgwRuZUNBJtMCn8gECoRBkwiMwBFwcUGD /rGOnG2BBaOrnx1aEYpQOGFbixHZRnZhsguQkiS60MWSKIELWYAiNI+YWStdWcE61OEKsHiENkaA g1gYTmikmKU1rlHH6t2KDWMYJhqKecxm2hANEZXA0zIRC1r8YR0B1U4pvDCFUzhjFMZgx3cAs0SO ZRJ1PfqF2kbWhS6kQpciYQVJNKOkCEzikC55BDf+MTPg8QQKjSRNBHCgDEJk4hOl8AYOIpDQhTaT GGPgEAs3YAE8dMCYcaAoFixaPWEZRX158IMcD7AgF5ziBSX/NYUTfqDES5qubOXEBv9+tBGSNQMk IXlGpXqxJCb99BEmzJvemKAB4tXrESMggAs+QQpS6AEHc2wAVfEIQ6zCQKtc9SpYXSgOjJagDGVQ n0BHEIFSROIKr8jUB1CECNGNZzBN7NgmFOPJ1kGKSCE5hZEyQx9z4ceBvPud3iBQgk9cgV6OtZoe CFADWpDGl3fM4wQ4q9XqUahWRjACBdogWtKWAR4bfYQwPoADJTgiBjY4BiVGAI5VfKIPP1CIxtJw Wx25lFuffJQvHHEB2eGUE8P1DEvstjvE1kwIZbiCzmJ1jAOQwhjD4Bw5aHHCTNxxAyLSbm8k0N0J fDe8Z0mL/yIUEYMykKIUPRjBC06hhwMcoVWRSJ4CDmAB0YknDWm4ViuY4dJZ+Cgjj3lULnwx4OC6 0zOSwE+T9oNPogrCCFcIQQqWAYljeIEUpq1BBjDQiw13GJlXycpWuvKVsCxCOSeeQIpjsIo34mAF d3jBAUwRAwZg4hN+WAE7ytAHr1WLUJgUskQU0y3HZAKUqSCS7EipU7rlRz+qMCxya8aCEhghFMqI BSVeUANSxCAGr3qHhqfH4RTSYQ7AEQ5xNCAERvDhBG5mTorLMAxS0KIHKcBAKRRUY4GMwA+tesIW EgIBKQwKW6HY0UQosuhhBAlSjz5GJU7xDE6g4MCT0JQwYP/ywEy7awsy+MQncKklp1bDCSeqwphV 3WEidMAIFqCAFfogBjW4oR98EAEHbG1iXCvCtOr7gDZIEYtqxIBVAuFg/PykkJU28dn9zSujQeme yjzjFKxAgS4E6xlK0HN3jygpuUO1BSFkId24xAB7mbEKU9SAEKWwLjCTkMx6JKENDmAEDzjAh3/z oAJrCC8eB2mBUr9oBB8oRS6uIIBVjKM6ZjBDGZjxg2kFRjCYbIU0+usJKa4HMo5wW+yCq8VLRUCe lTasKiDZLuBtPQSieGMpMqAAR4ApE+GYAi1wjkc10GEDT2jBv0Vwj3vw4BCGaAEXjJAELCS9mWUw RilIId//KcTiE0eYRgi0YwZ5gD6lYBPMfsP+sWmzJxW+UDKBX3ASLn4mXai4JyuJmkR2wIE2pbhD BsBUhqQogxZT/eWtkjAGdJyAD0LnQz+wkAMKYA8d6GChRblKoTKUIPMfwEARSnGEA6SBCXnZ8jhQ WgGwDaB+1wqFNMwWsilCZjKRqszsCkyfLrpM3NkYKvB0EzY0ywHQgjJAxzRUA7rFQiwcH0NZgFVp QSA4Hx8sQQFEAQVQXwdowfXBQPZlj7CYQikgXCkQQjUcwRFkgTVRAkFoXbKNDkuFwmFsC/9MUaN1 gSO8Xux0wjOYRMgpCSSQXD29xLjRjLswQRBMFmlQwinA/4gNMMAnRIIKmIEq9MBCdQANEcMEUAg9 NAEPBIMIiMAJIALTLAf2cEhbvAUmuEAmkAIBiJBRME+LlQIUxINCnAE4OUQ0aNI5pUcNXMI5kEwu iEtIdMIBGdhOWQKTiNvt5R7wQIERHIALkMMHUEIRFMWVgJkfUKEV2hEWGoAWJk0BLAEHBEMw9AMg dI8FnGEQqJVA1AABSBcpGEsGtOEBeIE9lIIG1AFg0JUcjM1hnAfZMRpNUUYuPEMlxAIydJvIBQUo yMLucMNhzV1yGcG+rEAPUAIGMAsKukAG+IEKVOEVZuEWak+GNMI+gGHAuYkZ9koIvSIBrAqK1MCq uKECfP+DKRjBD4RHYIgN2fAINixG2UWG6+XCgJ2CLcgeIqoELuBCPd0ePhlhqEBAGeiBzmRjEcCF DbyCIyyAPIRjJ9IbOTbOHszDFwLcCbDjWbDiO0KCXVQHAUQCl8SP3n0D9/2FjYDTOMkgFKEN/XFE Dr7HBXjcIdLHAsnC25WGI+rNDxjBEVwBBrzAI+CAFziCAMBCKbjAR4qjJ45khWDBKAKcKUafKrKi Wr2FstRFilRlKSyAF6zCMDzBfQWKoYVT/OXWKjBGegxDJgSi66VdtqFAt8HTkhzSaPDOUtbMFjgT LAShMPgBex3BW2glJ44jKG5hIuxAKYKhCARCPZThSvb/yllWjua4pAtIF1wQBBKBhy9mUkTMAl7B VEx1BKTg3+w0mZJ8RskdJn+IkT5R0BYIwivAAgtGADnsEuVEgjtUZldeZgA0XynugCEsDeSEJocQ wi4pHEiM0C4pw/Js1AFUg1+o1Hjc1kNIBKJ4kpFxRG3GTty8QCf0gqUEIZMMIUzsR008gH7uJ3/2 5wP4RQa8Ai+cwiwRQi6hiBfIA3OKpHP6wzxs5hK4Afeo5Cq6YwLgUi4UgXeyUSksDy3kwsKxQwX8 gCDAYBOJE0Q4gW6hDaPsAgARyXvcVCfA0wJJgjBMAiiIxu35TspNyRYwgQBggpjwQviVAgO8wlMM DWb9/5IP+ICGrBAg+BvA8QAj7MEf2dCbyYAMQEJdXFMkxIVABFEjEcQ0pJSNMFHHaFJ6qgcbRkbb iAuluNPK8NSmVJoJBRU11swP2MGVBEWqfEMjoYgeZCTONemTlgALBUA+HAIfmKII8MEQAFKWyoAL VAckqIgjCMQnKEE4WJN1mMIwHEQtfM0lpSnq6JbaOIabDkkCIGM3dMILDNdn1Kc98WiP/gcTGAEs JAPPUMIy4EsMJEOenQIk+BIy+QAX6EALQFT1OMAOBN0J3NsNWYA5jMGtdIRe0IYjuEBHesFb3GKr 4ENwagyzmadrUsTYpc0wRMI5SAZlsFHHVcqlyBOOcv/KjjKYuxgVA+jMMrzAMpiCKVzBNPAdsRqr BCCrsjKrBBiTDgDCEEjrWVTrrbiKGiZLw2SqthLAN7DDAWwAQuRks4WTkG1CeloYo2xEpBAJpZhE LxDmtyFlaEBkYroLRb6CAiiAMrzAMUQWjWUCAdxBsS7psSarBIDYZ+XAVykTFlhACSDHrdSApU6M t7rFttKGEtxsGcjAXIaNHZiOK2iSopXdLqRCR6hsFvlgbjYkp6gLK0nklECAU05DVG6ZC5gCLCBF BqRAbtTR0H4YVnTWVnUV0oIV0zqtBSzIK4aDtzpV1XIpATDDJ3jsxAlKxSFaj7DOY9xgpEzKELkT PJ3/C2H91DTm6RFuA7o1iJaUgim8ApLWAG7MCoSEgd9mVYiNWIm1AdNKrAVcKp7URhARgFM10onk WRkgwrTkZEOMTShE2yagjQvEFLjsgiZs7jNoEchdSn02kO+MLlExgVG9RVAoQyY4whVcgVMdg6zo RuzOLuByVwB4F3jhbgnobggNhFqhyBtKYqYOREEcBP2Mh36NjeUmio9oRCYA0JAMEMqgQCdog2Dx FC7UJ2lww//dKoD4BFAIBVEYBVIohb9ACFVYBVZoBVd4BVgkB7A0RxrChVzQhV3ghV7whV/gl07K IOqkp7qujeU8muwQEApsRm7ylCzoTkzckwWjxmq0/8ZrxMZs1MZtfDBv+IarBcdwVKtxIEebpTCJ QId0UId1YId2QAJ3eMc+nilhiBN6ng0DXMIw3MIlWNH9VQJgxercYAqTUMKO3p7cue1/BMiA8EKB HEiCLEiDwC5vSIi94Zu+qUELyAAiMKrAtYH3yImJoEgQrUiLvEiMzMifgE3pYAvYJRq3lF2jPUra ARcysIIkiFxP0VOOQiQA6k2V9CmqbEmXfEmYjIn6monApEmGuMEOqGNKvkmcOMec+K6d4AmM7Ikp 9EmyWdIA6FdhpDHaqCt7AFhIpAySPDCC5ceOjhtRjUqpnEqqrEqrvEqsKM6tEEGuDIwQ7EPQOSoP PP8AhSYMsbjksdzvsjQLa0GLtEwcOImTDJLsKK/H/0QKnMbNIbLdKRXWKh3xTsCLvNCLveDLJ+gL v/hL0QSMok6go3LAPJyAA1QnczzN/jbMw2yqxFCMxeAkHpanQ0AEFLGuyEgGDjaD7ACWcHXGtx3S 7jiDrfJxatxMzuxMz/yMAASNkj7FRjMOdI6lhBoMhUoO1Fzq1FTN1WTN1nTNHTLROO2IKKyCYhhD /4xvTeF0thkiJwgWShDWFwGVrRIV3/gN4AjF4BTO4SSObjQ10kxgKS5BC1CnKkoO5UTh5WTO5nTO 54SOGROGHUDDDQdkY2QE27SNpDxDyrxAL+zffSD/5d3EBL6GivAQj/Egj/Iwj/NAD5mlUPZ04UmK IRmStIjk0PiUz/mkz/q0DyW8T8S94HjoJLRRBHqIjOUE0AAZSawi0E7dRz3dZ9v+JgVdUAZtUAd9 UAiNUAmt9lpgjyiS4limIoXOdvg4wg71QA/9UBANUREdURIlRNgwRCu4JhSl68nSwNjGaDuVBO01 CUz8w7hB9wSZERqpERu5ERzJkeBhF0SJAQCkI0oCEjMRkiMYEiIpEiM5EiRJEiUhb0OME2STrGRb 8w4/mqTglEkcGC7UaacYMU0AuATBkizRki3hki7x0mVlVjBNAESV5EkGHISjgdI9UzRNUzVdUzZt /5MCdBN+nfE/5tbYFXCjkIxHtCoBweekeYZLfJFM+KaL85M/AZRAEZRSH5RUKRTyWYBDrdANhOXz RZ/SihVpPcVGddRHmYhIkZRJoRTGrBRL7Qg1oCvrRUIX0ECSJYDsvCoCCda5yAJSkgARRglR1cH3 IpVSMZVTQVWZU9WtWFUJIIJmDl0YBsITINObXxRZFSAtnFVarVVbvVVcKdHG6Fco2MFdouui8KWj WJEoIaR+d4Z9wOwjgAJQh/aUKBZjUYJjQZZkUZZlJfhmQSf0TSdoKe14CYvB0UJqrVZrvRbJxdYB zNYd5iH8ge1i0N8OD+IojQQyyGduqjgRBjVRKf8XcznXCECXdFHXjf+SZmXXEDzo0EXotEtrtZeW eVFXeq1Xe71XfM1Xfe15YPhYxQ20rffPLgz6/Q2lIZaEovNUSxymM3wKROuEg0HYCkgYhVkYhqUa Cq3F7Ebpv3EAlVrp7b5ZnLGYi8GYjNGYjeGYjtFWNHNMk78Um16CZOxCXw2YLXicZrjst3nzPWEa 6YZKlV1Zlm1Zl31ZmMXbym8AMmkXPpjA0P0bpMYvzavYnNFCnd1Znu1Zn/1ZoA1aQvx2DPJIudPf G1MGnGYRyFkKBBfWPU0Z8Gxap31aqI1aqZ2ayq/adrfaCKdZOcwatN4aihXcrvXarwWbzhObsX3/ ArLRj6AMgPKaDXqoh6qWLeyktRat9U7J00Pea8jnhLmhm7odA7u52yfAm3ZvAL1NMaxZ8SA4ACBs geTDWcGdFi0gnMIxnMNBAsTJzxaEx7KRB0SY015G+di6HtJn/HAtEK0G+yhwbwCynMuRAsw5gszR nM0luM4lcr7tWyPLgAwpghYgnQwoHdOVgtNBndRRndUBhJkyzH5UAObhzJkBA+yECsVM1KZVnl79 cjHs0qVMu7qk0qSpUiVbnVAg06VNUgRLsiyBevRS1ah/M/3VtHkTp7+CIUSVolUqgwJHpj5lCjeF lpkGRwQQkbBBhho6FuoladMnh44WGyx8mbBm/w2FNlB1SLBgoYyxUqRGgJsS69ORaSG8QDIjb+6W H7UgeBgghWFDUa4kYvNk0UXGW7tSOXKkKUEnyciQoZQ0iWVLl6qcyaSZE3RNFlvYwcGEqdSdDETL OFKijJa1a0ydnk0yZkMfCh10sDEEQocaBC24GEmCBQ0aPB0CBChTYu0HDEVKHTmQhskCSJCOjWO3 pQJfCAsZOowWcdNhixgvRYrU0VeuCyI7mZR0mRJmUJZePlL1aKZ/QgttCxaw+QSSA2hRxpFPpqnm k09iiUU22syygJgxtEAnByu4ECOJKCigAIEONswBhuSWa66EEkwp5QNtSiGkmiOOyMIRSCiBxP8U grY4CAKFAmslFFEiUo+BYTCKhDFHmgGpklg64QSZ+yKYhBJQtAQFlUdG8UzAAXNiIghSSHmJklNK wcQGBj6JRAUzVOmBtg4MMICYCZojIwoLgqCigyCCYGOCDTbI4QYZLChR0AMcwQQSTFzIhBQCHCHF kQNI+YSUUkqBIh5gBEmIPDlCgcYVaiRiYL0laejCEflCOoUyTnRJaZJJQMGFBJceySbAMMW8CQoj DnCBnA8oKSIDR2DBpIYM/JCTzqbsxFPPAPj0E1BBCcXn0EQXDTSIAw4oBZIaCCCgBlIOUCIDSg/w wp5SNKjjIFIXsqOVViKaCBtWE7vlFhoc8QX/svkk48TWy3KdhL/+VFElwGFxgsAIPb5ZoQdKMPAi riNckFaFOeu8M889+/wzUEQO4eOEcBVlNIgaHEFXXSUO+OSAGnSuVIFvTDHiBwiMJo+hfo2cRT3E 2tvFsVxAeoaVKTnpBVdZcNESFVS+BPAzi2uCoAw9FOB42UhteMWRBeQpuVoirk1Z25WpcGOHYETg IGZEZybXZnQPWCASSAiIhBRTTDkgqG+e+wEYo88AzI6GoPnXk4AZuAQjjhzzJYEEniEJGU7uu0wW SlrqEuyKxa7pByOOuAKDFx7BwQtHBIClFBfeNtlalLPlU4h9eOAgGL15eEDmcRs9ANJPXKjB/1xH Ism9lAW8WGWYJ4r2AKF9+Y2GsE02+YVVJdujobGPQrLlBYZvdZil/l4K9vWatrDgE1h0FMYPSnDE ESDlO2qdDFsByEcg+JC8vc3jBA4oVPNoZi7UvCkSB0iQC9gVKR4ZgwVF64uQ7CAHpR2pIurLyC52 UQz3PcMWrKDS6ShBia1ZgnXB+scQeNhDH/5wCFsQxCtgsaMIkCMBpaBeKSLhjgMGL4En4APygtEP N3hrgn5zXhAIkURSxCIXCSBFGEuhDDHGghYHqMYPIDce8lQuFOcxX+YYcBH2QM0jYexEDCuDNUlQ QhYscUmXKBagBxwSkYlU5APYmIFX8OIUwv+IACEwxTMvyOOJchNeABiIvCW0gFyEMpQWaVaDBNBi jEUwY+hKIUZa5CIW1WBHBfYyHhI2pEgSoUiSMHILJqUCYQmoxDO6wYrSWemPuNDMZvCXvy0wQQCY 4MU0qVMKBrziAJlQBiWUYiEf+ABQLTJHE3jABxHADBFimMCdKIAFRXlFBjJIlwYlFQlMeAFd1oMe j6ahF/GQ0IT+UhU2KmLH9kQiVprIxfs4YUxJWGYSW9OSlybmutf9wA7PqiElvPEN6PFMD0Wwy1Ka IoFvhrMEKApAAZZAxX4Agp3u7MoE4umCwkHiejeDxCeUEI4c7dQUw2BBBSQ3ACH1q0j/+gX/+obh AnVcgjHFkNp8WCHDKjkMF7IARa+8BCZhiY0JRoBFMrZJiWUQ4AAxSMYBTHGKkTJFDSblglZapFI0 EKERjDAn3yzQTkWZYwxnQeh2PnEaR7igbV6A1Lxi8Al8bMFofhFfUueIjV80VTFMOthCRUIZXZgu AjVcHSpAwQ0vWVRsUDgAA862jBcsQ3FXmMZQ3NpNAcTVB3NtQV1hEAA07IGcez1BX2UK2LN84lGR 2lkkfLomTDiCAN9gxwE2QNSj7cuEctyEZXm5JBamwoUhqUR9emE6SEQUYhMdReu+ajGyvUIBClDG C47hAp4dIRMEuMNbbyvXsggKUSzdGx/4/9APLJylnRYoARgCa4Ea3HQBGVDsow57GiXEtwwygBz4 3mgqaRhpFYa5LGahGjVNXGB0Uzpmrmy4H4kVsr3DwphcascdF5gCFrBwRAZSwE2S4nauEggCInbA AQKLQAQtyEccLpTgBTe4ZzgLh2I/UYoKp4sAzPhEdUf4xoYwwxVHMsZ6FOOIVHgkJFSL39Wyprr9 oKKiqLUYE7YRoRfU8BilMMUrsFmDIvg4m4TiQhj+K0Uj92MPEmhOEiZgBCOIRcHGtQBO6emYSBCg ytArBc9MUQZEhKcvk3VIqqjRtIxcomBOcl8x68MJbaDkYTjsz3rlPCwmqBZSNVRGJhxxhf8rVPkY L1BKoCcw6P8OYR5GLrAbFt3oR7ch0g222XbMxTNLHUunPFrFUD0Qasp5GD3cNah7GOO+U1SioZLw 4x8t0e5HdMkZzXxdHZiQgWTUkBcpaNYBdKyEZQA6E4K2QBIAMIcg5AAJO9grDxjhjzGsQQta9Iqh HAWpey5AiYMjgHZ2Kks28sWok72cKwC2VPa4x2AficxIUDBD/ChTvacNm9h+UAcF2KCGL7iDAmpg 2HD8edgBL7YFiFDwOQTgBiV4wsuOzIctRFxcE9+AYwrbNsLtNBwKqAskHFGNEOglcgkh4UPQkzn0 JUYdi4HVkypxiqoyDNahbXfEviRvsdH/exoHoAQvXlAEFxwgGQLo2Z2DLnA1AMAIfbVCH8Sghhaw gBHHO4EWxKKoshgquZt21PUOcL0aeAoTxqhGBX7U5SFJI8yemEXAVJiOSNBAE+F1e61u9bAbvsRr drfYFrahUV5Q4hiJm4YNiDLNwg+d4FSxCla0whUHAGILYWmD5Z8ydUhFiuoZ0OCa0MWjMghhC7VA iEIqZ0IjmW8il70IqruQcshEqRMvMIll8rOfiLE3fzopAyYOcIzfe0NnGgu6pkDYGiCbGO0siIAO VIZbQimLom4CWsQxBEcJvKDaXABkIIGJysAUCgHU9CVpIMJ8LMsT6gjVLoEGdiEXHOEC/xJg9krn JO4D5nxlFOKt1sTkDMogGdghBU6BEu4ArfpHYzAA4BCQ6ACAAVkGi0YJAlvEUdCFudBqp5RACiNs BspgA2pJXxqCSNBjFZZq/diPfdxnj+qDMu4jV1qiJfwD//JnAEqgGs5mm6ZgZwIvE16jCCfgLOKA OeqmAZeweRjMCREEp5RgATBhASwNuQhAAUIAC63LjRYiFFoBzCKCadQvI84BasKr7U5BfuYnV7QK 90YBxmJMTKCgBF5hBlbgz3jBMa7gCEghE5bhFILOCPkwCbtlUB5QUQSxBJYIgxBECTIIQT7BC8Jh BkxhAyArSEiISHIp/RigjmoA1aCmGf/C6AJGAhlaDmuuBBeyZKu6xKvyj84wARY+YBS0ARxWQIw+ QRm8oQdIYBR6IJucwlBKJBcdkAmpDwiAwBEyIQIe4Q9GoAfygBZowQsy4M/+YQQWB/yOhvxKiOyO BAwTIxNKzIVaMBa00T7oZz9IgA2DBYhGsofqAAJiABZAYRRAIQ/AyGbGqAdigh4zwR43AB/9YQlg Rgl3cR8toCz60TFegiA/QBZiwcoi4RROoR3+4QBA6Ee6bQDSoHIaQho2QRRmYRbAsJd2gUlywRfE q2rg7nQwgz8ihhtEkiRHsg5+wAY+4SXSMXTOhRYSYAQewbbsUQbeQE8MbQl2UpTCxbf/yuIsHEUY hMES1iEChOE0oKeG4m0VZqACrEuyhuT8dGnMTi4S2ufEkhIFOqEXQFEWIEZi6m4m0nIka64aDkCS tOEDigCVHCGJAvIun0IGCKUE+BIN9PIs1CmmAvNCigIFhGEmImAEckRS7uwf1iEOC4QvbsmEpMEJ RMETpjN9MsL1aCAXsNEWTmEyrARLIAYk4Q3GTBOI6qAOrgAWHkEbRgAHYkEWX4MUJKlCSuos2GAM SkAIWgAJ/CE39dACeNMA2ik5nMIJMwGN/mAd1rMuSsELpuAUOsMYvuMHBOG6ptJfzk89VMg9zOzE 3if+2OzluOQlTEv3hqUOcO0lIgAH/5SBEDKhyrwBByJgPmsDQ+4zpXrrriQgB3IgrhAMOXJUAhWE FvLAD+rSXGrABU7hBTrDFJzgB8Iv1MSHX8KNoJoKI9QBVhBmobiTdNAwDWXhETaD1mZuzjTAHH3w EUaAAOzLTPQAB+ySpPBSL3nLt5xiR3uUuHxLHCSgRcqgDA6SPUcgApjoCl6hhmThA3gGEZjRjdIg aShrFcasjnoJoR4DSsyQYbw0vd5tvcAk/yCgBD7hCnowTRNRD9iFFl5iNqFCLwEMBrhiOXaUyXxU T/m0BMoAHtDoEYThA3BAgGLABo6BEtpiFT6hD2opfPjFcgjjEk1uhZpEoUKi1ZChG/8jau7uD8by TwjK4ArOhgCPQVOMYRiMkRxoYR7rsfr+6+Be1QJiNQdmlbjeaQIUQRFioAw6pQdG4AVOQQ8O4Aga KxLWUQEOwAKgNBIrp18Io9SYahio8RIcoxmKIQHmQxtjcBIi4Bs/8hGcQeZMcUAEwQiuIARSYBm4 wwtIwU+jBQN64VxpsvriylW5wimazdEqb6boNQZWwSdwYAXu4AXYKgYYABM+wQ9WgB3KoA8qgEIV IiIvFP1+4TCU5BY2ogtc6P0m4zNxpf5WRxVQoUTFhAVKwAhCQRligRJeoF1iIAag6x3MdSZrEgHo IGaJTtECgNFqdvpuVhHKYBhIgRb/eiAFMKAUBO9f0WUE/KCxnoAZE0Iq4agVwiw91GP91IEjpAZK aKXlUCK0RMtXHoEbstWZZCBCUAn4qqwanGDTqoBl37b65MbgOsQI+sAcyqEELCAHHg7q5JVe/fQg Y+SLqiEG0gpdVtIht6DbFMJR+cUh0OMSk+QS1GEjzOwx5qMb6kMb5kcScAHm7OcsyXRYtkAIsuAT DpIUMECAmGEVTKEGCKEUVlUGkkAC5uDokk52x0ADBoHBIA5RyOJC1NZTRuADSiEXrkAAVmEcCscM BIIgiOp4k5dfPmyOCoo9NuLMwmi8qqYTUEJzZ7Br/ONrB2QneuIngmIoiuIokiJO/2lTKoyAHw6h CfbhEA5hCU7gBGSYHyhvLGRAMNFCLdjCLeBCLujCLvDi64rmIBaicU/FSFRvzEbsoFKhGRyhEqhq MiCKLEX0fm5wQEajNE4jNVbjE1rjNWJjNuhz4AJrHwZsr46Mb6RPRfrwOaJjOqrjOrJjO7rjO0At fPYljsruMMLw9c5M5cYrc0/iSnRla3CvDV+nQA4kQRakQR4kQiZkRi8kQzYgjTkAye7hHpBMBO7h BIzjR1ckAFrkRWJkRmrkRnJkR3rkSSPnYBtCuwjK5JakUptBdPaoqjpSP9othz44NMjETNBETdjE TeAkk+ZmePqEH0SABwTlEPiGgv/IpeIiZVIq5VIyZVM65VNCxfQkEiIG6uxqACMyoQt2QRMQZpgm w1a0gcV0ZaJgQotDo1iOJVmWpVmeJVqmBXg0KYH8sJmfOQiiuW/EpYLOBcvYxV3gRV7oxV7wBSr5 2FS8kGGHYWordZBJ4mqqlSUEqUtyz3vFBGM0Bm0+JmRGxg/gBoHoZlsCGpqlmZQAR6dyZmd65mcY UWiIxmhiuRUu50hK0AUuwj0wOnRE4gVaznTQcA37wwZDekDIxmzQRqTYhG3cRqWhiKWZ2ZlfuqD/ RlACJ0Gu7nASZ3Ea53H4QrIa12mZxrLGDVZyIRUodrxMAnvJkgRYZ5FpTnZox3b/cEd3eMd3rtqf s9oChGAJ5oGrp/l5omd6qiensmd7ukeEbunLLDHEahnVMvNgLkATTsEWkEH+QBEXwJNLYgKYQWN/ +ud/AmiACgiT+lmZ8zGxY3qxN809NOhYOghSTAGE2ohUpjIUXKF8Vs+JD6oj2G68rMZ0sCSQsNWD S5M8fUiIiMiIkCjjmMiJYHuT/HAnCVqxuciLwEiMyMiMviiN1kiExoNyHIIZzCdyTS4x3KMLpkok MDipIyC04Lk//qF7/2GR/huRGumRImmSKmleXjtuYpu7ddG7abtmTimVVimJXAmWZImW/gm7QuHD CMMTJDUxMkJ6gymGZGjdWMzd/557nlEbmqSJmjzlmrJpm2bzpDqATvvzLPZgCfghQGUKnuSJeqzZ nvCJ6zJot/tpss8geYkEIijy7Cz6l7zycq3Gj/LDElQHJNnLY0MDozSqhjrqow4gpPjLKWa8xnXz P9dpx+W1pm7qsafQpwgrqIZK/CTLQslnE5rXeZ8G9k4MhuwbmbTX/rykv7McNMJqrMrqrNJqrdqK v4CMrm60TnWUR5usuBpssHbKsBBLexbLCxrrseZ87EaN5OiIxDQRvCSWPjxrLNOQawad0HNCtVhr BVwLtkxBtmir0f1rtyA9R++U0v+qwZDL4paruQwruqaLy6IUYVuhKiNYGu9o7f/eL8Xkrxdg7fZ8 5R88NX/eK77mq77uK7/2y7YcXcjWFVY7QFYpXcEY7CwebDsibMKeywUsDMM0TPyCpFRa4Tw4fKny fEOLoRg4u8/rY9XVcKuy2KlDY8amocbqC8d0jMd8DK78q9xR5NzT3UfXHco+L12mbGitbN6xTMu4 jMMmy0hUZbuc16LVwWAeo6hZ4agfioZ0xX5A+tVxgs7sDM/0jM96BugMUOiMreLZdWbt1tkgrQQk jdKwz3owrRQ0jdM8zSCKSq3DTFXoCBPJzXKFqXqnBBRz5c3uR9tf59b2Sdd4zdeArQCJTejntujv 9tmird1/qtoO4NoQq/tMYdv/pt6NLPT82Lq4NTGqTmw7Zeh6xzLsX6IzUjwn6M3e8E3fMqXf/u34 uGDgCq4eWioY9mrz+aAJFiF3Z4rikuviMm4BNo6wPO57/MJRW6EhhFuXgLqpCKZSOasbuPOYHIYS DLNzvZbxcaLmbi7ndq7nnuvnAE7gim4O/GGKNl+N96YAQl/qqO65FuDqPiHrtq7rivje38ghHpcw LpvEeO1gUkFa62NKurGGYO6uXwJYEh408E7v+M7vAE/waoDwgN7wEE+KAILPvkOHlpw4sYTDCS0U 2siwoEPChg2OMEEq9emAo0heDnCsUaoUJmPVKmypBWHAACkD7LQKJcrVpk2z/34xGDbMxaVMkVLl 0qSpki1WL5BxkoR00iRZllCRQPVI1b+p//xZvYo1q78t22BhosSL0jFSpqbZMPWJFy8zDQ5kYjOB i4UkACzsE9GkTw4dLTZYYKRwTcOHESdWhAQJkyNHnzIcuIipFGJTZYRsgYBZZRo7clq5ciVqlids 2FzgvBQpUpdmQCt164QCmVFJkygttWQJFKpRUqlq/X31RxlMB46F9abkQIxPjghMecHWbZIJFiwQ oRPgBJ8mFoJQ6RAkyCGFG3LcePhlQokSiyUfUNLxwCcXXj5djFTGVKEKmD2otAMgTDHN9MpNpl2S jmrF/ORaJ6ygwIkuSVFCif8ljzyy2z+9VQXcb2eUkQw7KZxCyR0EyAeLHt9gQEl0mUxXHREAZLdd d9+FN94J5Z1nQXrraSRZJOGcCMknShC5QAYzlLHBD8BAcMYZabT0EjOibLKKJ8b8cmAm5+yyiyOa JFBJLKx0UpQk2tBGCShughLVKFRx2GFWA5RQjQIrKEPJFPIlI0AmSvDpIowWxNEBjdx5B5545Jn3 EBhj/GgfJJEosQAmCywWCXMEKBACk/xhJuVmoZzqxEye2PTLaec4QgNrQb3WSSfIrEmbUnBa+Iic vtWZFRQlvDLDCkWAtdgVR5CSyTKnFErdoYlqt+iNjuoIqQWSrlfDARilZp//EpHIV6QX4cxgygaX QeDff6F4JsqVnnjCQKs73RLJYmNecEo3rBglYQQRTAKKLHBClY2vdAJrFRPbYALLB6NoA84KCZDy iTLe9EDCKD24RYREGyAwbY2M4vgojxEBAYQjmUTwyB8j9JAHLbR4kcGx/4xgygGWPanSGQC+FM2V m6zK5Wmp5VuMJhdUQpRsASvFVG4Y/vMIVUNszXXXXg9RBwQxwALKKKDkEUsuNThCSi49qOIxyCKT rKiNjea4I2ESsLzYhTN/IEsspWx0yint/HOAMSycBKVKVHYmE03YFKgTamH64ssFCXRiS1G6SFhb 1U31uuE/X5/OdR0/2PDJ/4UTJ5CAt7QkMMIjbB0hQMgbyPDGBHWffO2OAaARUXUaCSOMJetEIAwm xH1FiTP/rDJDBRXU4t8ZLQ3wUuSrYLPqaZankgpQmgxlqy69TJIrKLhB1eucqKP+Qx3VHCBMBNp8 UAQtpDiSgFLA7Ha5k4gM4FIC7XCAD3wQAQeCEQwHnsAAFMDC8IpngU9kAgXCmEoERuCIxLjgBZT4 xzrytAUWsMtxLbEDTEBztFfYRHy76IIjcvG0SpyiKBFCiiQogQteXah08ztdHepwBVg8QhsjwEEs mDUoUuTPGtfAXciqw4ZJCYEPC2zgAyPIASFQEAtoQEPIfpSJWNDiD+tgov8XLuKFKZzCGaMwBju2 8AN2ac9dLpGJJ2pSGpzwZBc0+MmYdAgwCf1wErhwH5yckbVfMcwqdYDCATBxoQjgQBmEyMQnSuEN HESAilaUQHWIMakSOAAJBynIPgbSiOpUsIxnZM8BbJYHP9TuAAeogQt2SEdTOOEHl/FASv4jh1DA kCYybNUwUBOJQuYCh1CzVS8UqRTcWOIprpPkJJmgAYiR6BEjIIALPkEKUugBB7ZrQCl317v15AAG wwtZDnKgBlNaoILDE4cE1lOGMtisiSOIQCkicYVXUEgWH8gIIooZJce5cECbyAI2bvJMfOXLfJWo hINewIleIIVCbrKQhUr/N8mrQKAEn7jCiMi5KT0QoAa0uBABdce7CYRnnn7BQwfuGQd98hMN/gQo PNT4CGF8AAdKcEQMbHAMSowAHKv4RB9+IIjMtLAznqGG5LZUOZ6kwhG+CIotbAVSRS4UFyTY5hC9 yTAhlOEKenrOMQ5ACmMM4xNeIAct4pYJ3W0gIjuFQU9/moOgyhIL6JmAIhQRgzKQohQ9GMELTqGH AxxhOZGomAIOYIF17bElyWSGTFYxi4vSUDU+yWGtOsEJZEgiArSYxPvgpIoLwRVYgjDCFUKQgmVA 4hheIEVAa5ABDPQCsILNZ2H9ErIABGA6RjDCYHrkWMiuohS0wMEK7vCC/wOYIgYMwMQn/LACdpSh D9fTqkpKe6XU2uRAO9lFKorhiGNU4hmnqJVstREBSTTSahiK5FRSahUWlMAIoVBGLCjxghqQIgYx aM47/vqxwM6NDs+1jgSkS13rOgS7jy3DMEhBix6kAAOlEIBmYyCZEfhhOU84Sbv+4xKYeHVeM7zE JW5hw/IF5RRn6gSuctUm90FFFRtC8FZk8IlP+E8sn6yGEzBSheVmWLBE6MAcgpADKxihD+YoRwks kIMxrEEL2UpPiQVKiw9ogxSxqEYMlCMZs/XMMuzyAEsAlGOjYeMXXNLJLXgSK2qe9UwhHSkj3adb 6e22TlsQQhak7D8MNP+VGaswRQ0IUYqbGjAJEpjDHAJwgxKQeQwaGISk1mye3WGQwiEZwQdKkYsr CGAV44gEJMxghjIw4wfXu/FmkhkvVf1iSxmNJg0c0TQdogkZIk3KJIThPhJExcALYxixQyAK7pYi AwpwBFoyEY4p0ELUu1MDHYxQAGJYoQ9iUEMLZMA7RgSCIW2QtT7LYIxSkGKqU4jFJ44wjRC80Qzy SDgen3RjQEMDNNTIggxxUoMfk29BlUjAWdNn7drkBk5yUpiTF8cOODivFHfIAFrK4IhB0YKUBaxO EsZgl3kAQi988cseAtOQMvpUumUogcA/gIEilOIIB0gDExaAmGOM447/xT4mld4FGtTSS3yZoIFP WuPRWuGqNhTCjZv+MQqTIziF2LDPLZXBmGlUI8qxiAXNr2gBVG7gLvfYAxsMAQId7IEP9ziBEZJA RjQMPQDrMUUp5FwKQlTjCEfIQggpAQlTDJtxET12KIq240EbCDXP9kUuyITI2PrQNgNe8py6DSwm BCGdF6LEKURiAwZ8IhIqMIMqemDFDhjAAMTwHQvmwQEeCOE7QuCBA/2RNwuQLDwasQgmXJAJUhCA bY7AKzpDAoV4YG8AewyQlUIzGtU+MzXlY9ApzgqhNVHt2rviNuzrBAUjHMAF5PgAJYqQAY7gFcjl B74HfLkjfMTnO9PF/wcQ1AKNwAMRBAgTkS3TFwS8JBk1QAAzRQrvkQHZdwBeYA+loAF1AHHlByDQ YDSr8AuDFlbRJCZBwV9FIRtIMTAVYiGosBtNhmAQYAQqsgI9QAkYUB+U5wIZ4Acq8HvBN3zFJ11k gAWMEEH3EAw8sAcTQIE8YoFrk4EEkBwZUQPJoX0K8A2mYAQ/gBLkNwCbEWheVRPzBU09AW1B4VFG 0WhsYluQpluT1iEQUAZ6oCdCWASJYQOv4AgLIA9KeIBd1oQLSAZR8BcOpHxwkYUPsYWO4B4L4GsE EAlk0TPk9g1Fh4Ye4AEo6EKukCpZkjTN5gjlk0OMJlsTIguUoG17yP+HwPEDRnAEV4ABL/AIOOAF jiAAsFAKLpCIS4iAjfiEUYAIS+BAwRAIlBh9FshLFjEf3aIRHIGJC+AFqzAMT5BHjbNVrVA0qhI+ 6xcJYSImmqNDjFZtA2MwOtgrvHGLv7EFGQQLkEAJwuAHTXUEFmGMBsiECviEgBCBIjAPENQPWDiN jVKN3zIukLB/M5UYmac4TiKOLXQqV0INniBDN4EaqLEYTfM0RMYJR2FtjgQ/aac1ReQ1WyAIrwAL mBcB5BBA3XJQ7iCQyUiQAeAAX9QCHVAAEdQE+NCQ4UEIAURnp9c2AaQMF6NGB1ANP4CRaqiR8XIl q/AK2HAamXALYcL/GrkgFLVykrGYTW8SFXBDFQ/Alm3plm/5AFSZAa/AC6eQP4TwPxnhBfKwk4xI kCzAAw9UADdSABJ0lEFQAwngP7lQBE8JO6VwMbSQC3XGDhWQR6W4Eu5iWliCNFziY5lgX4YkFP8S f2sSAbhgMCSgG6RTj1qxBUwgAJigFrygdKXAAK/gFoTiTgXkAz7wHQnERQWABr1jAQawByIwQRXU WPgGCd0iQpGACV4gGRtxSZk3DXiUVREFaHKwTKtSL890CYTUigtyAA5iK9SmDUrxaNtEAtzAZK2Z FT9gB15BIZTgDd9wSRmhB4Moar35m9qBBMNDnBYgBm0QCGO0nDLg/wK+ZinBKBlGEg4hVCSmMAws UAHGFHGc0QpZOQsfCZ7pYEMxKG1kaZqMpE1DhFIIxgRGAAvJwCeUsAwnEgPJIF6n8Gu7mU8+wAV8 kUAFQE9mJAH3lE+L9RDmgHMWkC+I8QnO4wgucIheYBEhuBz4sAXAgJkSFQrMMBNHM0PgKZLQ5lpi Z5br+QgWojD31yGWxAB6sgwvsAymYApXMA3mZqMElKM72gIlsA3zVE9Bik9CxVgWYKTVwRzWJx9C golMSgDfwA4HsAH8QYraYwctoUwcSmggCU2L0QyVcD6V8AKxEYsRYBu4cSH252R++AoKoADK8ALH cE6alQkEcAc3iv87d0pYYGZYFuBTQAWoFlACklIdNcCgSQKlFdGkzqMEqloGMoCGpPIfRJNs84JR PoYvIymWoykbvVCibTI6WYMK8IkVPohwvThcLmAKsAALjpABKdAiOCoBOnqrPKWriKVY+4QFvgqs FtBLGRgOUPpJx9qcBMAMn/ComHFMAJJMoOEKorEqLmAakfAlqwF2sAEwsqhkuqV2KeUwUUZCYlEK pvAKuFkDx+IicMEFYRCvuRpd0zUB1dUQvjqoFmApj6EYG0EAn3RJGCFeZYAI7RVRlNoK0uAK1CAa l6o06lhWZEKW6mNtllAhcII1PKixlmQRFKIMmeAIV3AFn3QM0NH/Fm8RFygrAR22siH2siUQs2uD GLyUEdu3f5g4GatgoQaLggmbKqMxreFpX2XVUR/3Ato6W0rxtBcCSVI7SXXABBmQDBTCCykQgAeQ rkqwDO3qFiY7FwDwZWE2ZmV2ZmkGazySHhNRfYnhBQtQCt2yAAQAdUVSDexAlUCzEoC2oZ9BE4Tm mT6WL81QDMeQAO/HCv8yNXnYFLsRPweGYPWjADZAIS9wBwpQA0waDiT7tZYrI8toN+EhjW3GkIux pIeoiUUSDgrwRpDgCNUQAnikVZK6kaiIWur3Y+moL7x7CnWoC0chuIP7CNxwpk6GuNNwAGDxAkXg AgcAKL1EQiUb/xcWoAYzUgBLwAdLAME8AMFLwAMFEH2FQREWobMb0REfERIjURKipYYu9C5G84YO 62PheV8iSpb/JapL4SaPQHKGyzBcQZ9hMRZlcRZpsRbTm8B0QSNf9IxghC0qIzKHkRjc6xiQIRmZ VxlVSiqS6kLQsAmusApc+gu+FJ7RhDliORR2aIO3QapQIWnGm1LCQRzGYZ/JsRzN8RzQEiPYkQh7 AAj8wA+G4AYnEEEiwALR5yPsAbfvER/zUR/3kR/7gRIRdyrndzQXZRoZpxo2BBQXwF+1Um1J4T68 8g/cMCdO9iEhMiIlciKfkCIrQrkvEi3VGwCPaCNLAEHzQAeViP9dPwK3QkIkRoIkSsIkWOVeQwMT ytalP/ZsTQMUrwUh1UZ2pFqqGTtJd5Ine9InfxIog3LKhoIo1lsPCREMjBC60bctJUAuloIpmsIp ngIqokK3LRRo8lIg08p+Mfg0DmIUgCuq3Mor+4tgwkIsxoIsWbsszfIsX2vNibLKUdB8DhQIQZC9 PPLNOLl7nQIJ4kIufHUu6cI4VqehEzcTqcUADNAlY5W0HXUKstFoAvNoZTqPzMwwDgMxEkMxFoMx GsMxzDU3HSBPSMBAPNAG1SEGEzB8ygkRe9MyLxMzM1MzN5MzJcQzPgNRI3wq5TgLgJQTz3QOXfBs Y7I5/XWSKMn/SARDqmmXDS3pkqkjNmRjNmijNmzjNnCzZTW9Hj/JB1YYLT3904G6Mi3jCH7TA4Aj OIRjOIijOFCM0S5RjjTxneAJmmESbf31qSgJCYzEFLUI1mI91mCzOq3TK9oAO7JDO+30TjklTwbJ B/PQCEIKqBekT8eTPMvTPM9DIdJDPdbzJFDyZ6cycVeCDcZgIM+UCTaUCwDUt6wQW7ogf0DUSI9A AoVL2WNdP/eTP/vTP/8TQAO0mziFQCUwT/ngjPdQAH+6WKhNqBvUQf/wQSF0fSRkQiikQnqUBmwY tMnGgtM6SLvgC47QUR4Fqkfx2F59MKoQ1svtkkeUREvURE8k/yjKIEWjVEU1ZwFZ1GFusECMUK+z BKRopEZs5EZwJEd0ZEfoCyVSopG/fDQN+6H5kgrNkENDcZI+NDAj1xRlbMaHS7WZtEmd9EmhpOCl dEpj0GF44AY8MNp0sFi09E+2hEu69Ai85EvANArCREx0q752oILyYrQ/hrXkwxojep65IgtMAT9o p9KxF06wME7ldE7ptE6eXUDwpFP8sA+sdAImsASM0EAiwA8i1k9FHlADhQMFdVAJtVANdQAPlcgs lEy3PRNVfglV/XWoVysQ4kNL8bTy+HqnylIudQow5QgyRVM2Vd0G1DtBoEAM5ECkrhB4TlR6flQ1 pVRM5VRQJf9VVGVVzSqOnGEHybYJpNHRiP1sYuLosPVfSGEJQSRE3FDGTiZXdLUCdoVXesVXfkXT ExERc9DAfNAPETzBPLBv2vtYkTVZlXVZmbVZu+dZoAWTK4SlU86lHp0TqBFkrbFoRqENALYU2PY+ +dvJCNZbvxVcw1Vcx5VcWiY3E5FPpoZqcLBqrfZqbAa62RUD29Vd3xVe41Ve55Ve61UBVoqZCNsZ WSmtznQLX2lf0WbMPbRIjaRk+pvvKaVgDOZgECZhFGZhGDbwI/Nu+zRv9XZvOaUI/NZYJXZiKbZi LfZiMTZjn1BjVpoSLDEAnSG05njYIW/ih/RaJj8h9TcK3Ob/ZFsAZVJGClRWClaGZQKvYRPRZRZQ D0nQBjzXF9i1BoIxYm6mCHseZ3NWZ3cGY5CgZ0zdH1gKLwv7htMKJo7QDD+htMAuUrUhclaTWwa2 9ZaGaaSgaY7AaZ4GauwmA6S2AX1AAR2gA38XeGqAAC3ABYeHBf5WHbRWCraGa7rGa74GbMJGbCiR EkKjoYwsGnnbda14SM9wVicJOkpB7Pfs+MdbAeAmbuRmbhqUbuv26e0m5GjWAgjwBoCHAAgAeEFQ BrEmAxgEcAJHcAaHcAr3aw13vhh5TGxYqdTwPfWCUYcGv8VwAfHMaGM37LpBcqjw32gKHADBYgs7 OJgwlbqT/8HUpzKOlCijZe3aEQFEJFiwkGQMujU5bvjwIWZCDgoIOqBDlwMGGjR4OgQIUKZEKVIf MBQpdeRAGiYLIEE6No7dlgq1IAyQMsDO0lbSNlHbtMqYp2HDLl26FSmSplyaElTq1IkTMkllJ00C ZQkUqkePRqn6F9ffXLp17frbwgLbJ0gHaClz9GlatU+fYsWSSNEiRmJjtKS0wkVMkigUSnZ4rJKl S5glSpgq9UFbKULVjhzJ4ggSJUimmP3YYtTDgAFp7LQKFUrUplnYsBmrelWro2bNclU61Y0VK06c ykaYJEtt27Zx5d7FPpdJEFKk2lI6VQqTDQafIqkwo6qH4v8OBgwQmxDAn4MoFoJQ6RAkCJsJGzZ4 lMECk/Q7wBFMIMHEhUxIIcARUhw5gJRPSCmlFCjiAQYCD5KiLTdoXNkNm19GrCqSTCJxxBFNNLkA OeZ6eS4CSnCx5BFQHlHFLeuyyw4KIw5wgZwPKCkiA0dgwaSGDPxIb72K2nsvvhNEaKKe+/Lbr7// bghwwCAOOKAUSGoggIAaSDlAiQwWPMALe0rRoI4MZ6ttqdxc2WQTTxgg8apbdtklF1+OQy4sTmCU ZJIZQSGBuke42ZHHuyAwQo9vVuiBEgy8+OQ0F5ZUQT323IMvgED44ICHE7zkzz8ABcSyBkfEJFOJ Az45oAb/WxlU4BtTjPgBGA+Ooo2pUFyBChtPfhnGBasi2SXFXL6y5ZSwdCkrUUooSavGHOG6TtK6 IChDDwUwJRJBG15xZAF5QnWSCChLNVWEYILhwQ39Wt2yy1hn7WuBSCAhIBJSTDHlgAx6lekHDY+y 7bbcRAlRxODSuSRaR4rxypawWEGmF20kkTEtUE5WJeVIxaXrByOOuAKDFx7BwQtHBIClFBfeFfVJ UuMLgAxA7hWBgyX44fdVL8E88BMXagDTkUhsLmUBL1YZ5okfBNGQtjSUCgUaJ3ibZdlfnL0kk2h9 WTEBa1kRy7mzJsHl5BurW5llvCz4BJbVhPFDCUeOOHDn/yZHjRImoYNZoh8O7u2HDle5hJXAAw4y L5ID+nLBTARbM4aFYDU8Qyk7QczTE7ODg9aRVHK5wG24kWkuUehk4bZGt0axbgjffwc++CG2EOQV WFiLgJwESoG6lEjcOdznxIMeegkqGmEkmKL96bfyIAhZnpRYpiVl2lKUSUB8Wg6o5ocfavGATqZa YWa3TbB5hVm0oe0iFV++eoa1aJets3CrLahQxSh4F5cHNNCBD4TgA9yXgVfw4hTCiAAhHoQrL8gj evL6meKqh58g8IMHHDhB97xUgwTQonxFQF8Clpc+WuQiFtVgRwXe17Vi2SEU0bCf6hjAgOBcogtd cATbkP9zCmS8ABkjIxkupLgWtiAwbyzbAhMEgAledBEnpWDAKw6QCWVQwgwNUIwEQIIfz+Sgem+Y QCB4ULQTGIACWAjQFyYgAxmMaXMJigQmvCAmqV2uNdPYwuhK10M7SANEq1Cd/qxyC0fQQEXH6YS1 4laWGdHobv9Q4BXF9QM7IGlblPDGNy6HKz0UARJnTOMaO9BGQPBhCae6Fw+WUA874tECeuSjCwYG iakB7BNKCIdqIPEJUwyDBUUhVrHkgBs8RWVZRLzKOaD1umNUohK2WI7ISBYBWQhjOo9AoDNEKSkm GAEWySgjJZZBgAPEIBkHMMUpXolGAahBjVzQQQtoyQf/PhSND/1wwEUscMcAmWMMGEHRTz5hEEe4 oF1eOFCbYvAJfMRmWLWhjRxC0Qo8qe6aRYxEKlSkCRfBjRO6GNlZ0vII3S0wXHqDwgEYcK5lvGAZ CLvCNByRz31SxJ8+AKhAS+CAYBBUBHx4QA78iRGGWsChGPmEgRB0q0gkUzyYcAQBvsGOA2wAmhA4 Q1JOV82y8akqWdkFio7Tok6w4gWciOlZpEPTR6nspiwj1ysUoABlvOAYLsDVETJBgDsUtZ//1IEE glAAVPGBBy3oQA5yEAeF3tECJQDDQy1Qg2EuIAMYNVBFDaKEwZZBBg6DQDTtBI3dqA4bRLRK2rqw i2Z4/8WbsUAGMmCaqLOYc6ajeEQ21skjSh1hGjIDigtMAQtYOCIDKTAjP48KUMmeAFUnwIdLNMtZ qmLhs6HFSK5oFQ6MfqIUqh0TAZjxCbNmiFgRC4U0antN3N4iK0n0hTfBssmRyYgS0wFFKJebHSZs ozAv2NYxSmGKV4ixBkXI7hj5w4UwRDYIJ+iHFTZgAYvAJAkTMIIRKNCGz17VAsT8Y4oiQQD3Xq4U uDJFGRABTdqUjikfikpv3FqDS2jFf1ypRDfqShaz6PVkbMHbX8XFhJweaFvKyIQjrnAF9x7jBWfU 8AQ47OF6qGTEJQ7AiVO84haLVlY/AROuGgQkgLVmFf/PNMoZfOzDO+VpFSJy1rN2kQqOHecUwG0O FBNVtxuBwhnceMSCsVMHJmQgGdviRQqMdIDqKmEZGc7EhjMCgDkEIQdWMEIfzFGOElggB2NYgxZe pUf/FOhAglwA8w6wAAL4ZJk4dF+eaaOUaeqGNyJyqwvUsU1CfyUsnUCBLsgCHWGY0xJsUbCUJfWD OijABtt6wR0UUAOKhgPDYA61mElM6jkE4AYlUPUYNDCI0MZ61lpK0UTbJbBlhkMBXviJI6oRgkRm aJHFGqn98NenIkeif759BshCNm1F0YgEqGDLP8D1D73RhdLTOAAlePGCIrjgAMkQQK4gjG5RqwEA Rlj/qBX6IAY1tICPcFSEFlYcoMj6R6s3LtDUDjC1GlQIE8aoRgVig9Zh+5B+ooCKEK0yyZS+LnZg AVntJEEJ6ViCBJ+0Dsc7jpdtmJIXlDjGwaZhg4V0keXqTgIALFCPJLShDzkI6Ij1uIY17NwCPd+A VhGU7wxsTjxiak0ZhLD0RdphACKlGG+EyAAXXEVtuyiGEk9hixeIBRkRIC6C0alxSd/lB2XAxAGO cXZv2GqjYZ3ClxswxhNjhAiS68hHfMAfkpgEJZpBgx49kyIxpckLcXYBpyDhvDKYohAVsG/Tb0Pb PM3iF0NsVpEtmYuueNNjzNFGBMSPi0l4HZ0K3PjY//1xhjIkgx0pOAUl7kDPvlkKA6Cu/botABnJ UMYyJsmMlQi+CfCMAhGTrqKnZVKCBDStGSiDDYCt0tmzYwER2yKR3EIRjmkRF7krbOGk8rubUbAi beORASiBajiXMpqCW0G5THgI/JsAjIiDDpCBoKmPK9kXLXmV0CpAviAmJVgATFgAGcsqAlCAEHjA CtAQDziDr7EDkYqGR/KE28KmTMgKlfofbzKUl/pAYZgpdFIF5SLBHimBV5iBFcAwXkiRKzgCUsiE ZTgFdMu/GdwA73oc7blDOuoeHiyB5skcvlACzeGLT/CCcJgBU9iApUMrtcIN6tMTZMutTDgitiGU sP94AUQhLk9qC0ixKfVrMEyAhQ8YBW0AhxVIn09QBm/oARIYhR4YI4vwD5OQATskmjxEoe6JLCAA AkfIhAh4hD8YgR7IA1qgBS/IAAz7hxFImMWDnwHQs5D6oWrSkyHDChRxhO7zGLHoBefQFum4GxwJ O+ERx9+pAwiIAVhIMFDIg/GRlfLpgQRyxUyAxQ2QRQcwgSY4gRM4hCXIx318AFyUAF1MkbYIxg+Q hVh4r0g4hVNoh384gNDZgthyRilwvFZoBVHAk7K5PiIisqzogq5gKax7AW2AkdvZqwNSp94ZR3Gs gx+wgU9oi1GUoTChhQQYgUeApYqQgA2QATgKAhv/tA8SypLJ4TmFKpBqs4R1iABhMIjL2RZ1WoUZ qAAllMhhEylXyMj7OZvgyAQaQCKQBCe42cbnkAVPupuN+4eVFEduq4YDwCBt+IAicCFHWB5fzElY lAH+MACgxMGhBEisygQUEIa4iIARUI0EgbB/WAcUzIs5cUbH4zMnwBNlYZZmyQS1wcINDIsn8kBI KD+1uDZnsKm0VMvgqYM6uAJYeARtGAEciAU3fAhSwKDE0EmMYION4EuhTBrKsYgCzIRYoIU/WAfW BLhS8IIpOAXRNIahiMDSsQ2LBJGoyx9suoVlS4VmKIarOwXmCJkmq5saQYXRFLuOq4Mqa4sIwAFl /yCETHAvb8CBCKDNxbCAxkCH3MSS3QyQ3iwBCCHGPPCDmwSTGnCBU3gB0TQFJ4AN+JEtkdIvqLM+ jnwWGsDCrwCLu8KrbNkW86uR0fREDQDF+HuEESAAxOoOPcABnOQnvMS5ElCJAEADOMIIkXCPqhIH CfCMMigDYmzNEYgA57mCV9gWWfgAXEEEj5ItPou81cmt/0qFtvGm5Xip8OM6WTAZdIq00rMLCCiB T7gC+AvRIdQDM6GFtrjLnezJCVAEFoUBF4VRC5DRXgqQGr1ReADORxCGD8ABwYkBGzgGShgBcFiF T+gDh4kf5xwAi3QkUZiFVbg+lEqp3gpJjxmgvP86sGvLuCsdT70RgjK4gnOJvWOIEOAgRHKghVZ8 xZ3cgMhqozVFA4vQrKlaKF/SI0VQhBgoAwrpgRF4gVPQgwM4go2KhFJUgAOwgIiMrYMbqQ/ZjSzI H0ftAk1QIrBAhk7QBW48C9DUnbDLVJYRBCO4ghBIgWUACi8gBRxVEgzoBVOVR1SdKjV1UVeVqs6S VTSt1VUoBVrAgRW4gxfApxhgAEz4BD9YAXYogz44q2EbAA8JIt+oimHIChqIluyshGeAtk5AFEXp urZoFG1VPxYoASMIBWWIBUp4gTOJgRgIq3co1XicRwSgAxkwNRgYMfHaLHn9rFlVhDIYBlKghR7/ SAEMKIWU+1UxGQE/2KgnMNZnVAqL/BA8WYVXoLxn+S+u0Ewn4kbooBtLqClM3VZx2QIZKAwXQjv3 qgYnuLEqSFeWRVV5kQF+OAEkyEcTWIIWaAG55YdYvVl6xVFiFA3xqYYYqCcxGQVQWEaPohNiu8jU 2RPcuooiI47uo1jPw5ZJICcqNb+2SL+x2wIhyIJPIEZSwADBYYZVMIUaIIRSKFOeTIKLsEOn4gDX PQEVY7ESiCyMONkKGYEPKIVcuAIBWIVxGBgzMIMyeI2DrRMfqp88wR/Kq7xb6MqNycJKiIVOoB2Y Ki5LODAoewssrYsfqIAQEIV7LYWFGapPyIRw/5gCWkhdGVADOrCA1i2o143f2GUz2lWoMjAGmvjT KYiFTpmGEAA4M5CH/00kCBCWpsuNaKi+VeCTsxEOh3ud47AFzrsrKKKE6KAEEqipsOvYgSiIg0iI hWiIh4iIiajNjNgI72qCVFu1Vns1e6MczoiJmaiJm8iJneiJnwiKoaBKJrTK/LKfWcgftLmFc+gC GuAYb9o8aIvSigPNb+RgzdULvvALwBAMwjAMxDBh+WwMLVBheHOoeas3WYvhlwgAzwAN0SAN00AN 1WAN14ANA0bY22iKILo+tLFCGkBiFkkyJgoubkyUrru25IrijtuO7viO8BiP8jiPD5oXKeGDJv8I yvvUQcpZGq1KkAVpkAeJkAmpkAuRDa95wmPBSD2B2spsuEAphm4KoBdAAUTBWrupqcztOB8BEiEh EiNBEiVhkp4BocRR4UnOQaL0HjChlTI5kzRZEzRxEzgpx6pcituIQkX1BGOwmAfOQD6OBZDpBXFS FLX4QtIbQ+ygFEtBl03plCP4FD+AF8QplWDuS/z0Hlk5ZlvBFV2JECP0FWBZwsaT5k2g5j1hFuFI BZVaEeSoUEDG2HPi2q6VFHIxF3RxpfFgF3dpZ+l550gWZr9Umn8pPn4rmINJmIX5hoYhHWeExosM EYHGYwkdlAS4gLqCUrIooAPjq/DsxLFzGZj/kRmasRmc0RmeiZdHDgB41s1K9hfLaZqniZpiqpqr yRpCPbiljbxVYFS3uopd8EqOYaltpt5DKbAL1tpGaWj12wK+8RtKABzBIRxIMBxfJmqjpmRiXhob y5zNARLPORBTCJ0d0jP8GikQWdSNDI5bQKLegmlpRYELnYRF01pGEcGNK83gIR7jQR7l0TXngR64 DqFE2APzimek9h7woYnxSR/zQR/1YZ9gix8pcEI5sIPIkzyqqDyskNBrpFBDYTKSyVpHGc0IAm4H mqAKuqAM2qA28SDOnh4yuMGjputYaaEXiqEZ4lkbwiEdMoojJSk75hMXUJA/iVgWObROcCJM//xM 3Yk0WtabLNqiLuKFLwqjMSqjMpWlVWXTGHTTCZjReeUjP0IQYRIkQtKcvUYk2PLhQ01givEESDIG xs0YFUniCWYFFNhtJwtBrlU/UjKlbUmlVTqAVnIsi6hvd31R/H7TqgImGRCmn3BqBUwmiWqmZ7Kv xsMNYzs2bHAWIjMiCW0bip1wXYARRaEbRjm/BOJeumind4qneaqneyKqnNyugLLvVpWAV5XXhhKt iFomirIoq8koL9iojlLQJjQd3UCdah6i5jWyJt1AW0AB5oAprDUuzOXYscupnVqBnvopUwiqodIn KIcspWpRKrfy8sJyrMJkrvIqihIrsjKr7P+WPt3YjVW4H+x7loImDhn6Ju601knwwicTTfUGrDIQ LMIyLMTy1cVqLEBHKg+L2ZnNrJotr/Nys9I6LbACKxdYrdZ6rWPlELCZ5qi4rSKCq2ZYqWr56sm9 3kcgawwfu+Z6rheIrumqruvKLqOCLMkagiUIhhOwAJolL7wFLdFSrzFhL4B9L12Pr/l6dKbroR+i mLK5Le8WtIJWok7IRi6kXK5Ti4uj83G+iwZ7sAibsArLlXObvXQbs+5ClSUgMQkwMRST3TbDCBgb PKmhsVKwa3zSMSU88EP1IYysLUCbJCP+yGKQISUjb2wRv+jwxipCriPXjipbDUrAMi3jslL/8LK3 W/gPa/iHj/g1m10Xe7O+uJUDmDOLQjxTuDPoq0rTsUjZrjDcssKUemnv+2OF9sJBRkuH5hFKszRM 0zQI6bRP4/lRmwMh2IcmGAJVYzVXgzUyziMtsTUE8YJcgxpe87VPALb3EZY9C3nUsb7KrIGsgOAk rgSJ607ismkoc/aO4zZvAzdxIzewMjdQEzUiYDd3A2N5o7e4vzefCwywWgB++wR/AzhIEDiCI1S0 ckKnC+JXwHHvdl6IXakEmGBX1oZOlw5/jzKvz46PC7mRK7mTS7kaWLmEb7mXyz2Q4L3L+D0BBLyf wxWpOT6iMzqkU7rY8uFovpPd0Ehid4Tw/76At2kOkQG983aUQl7vssMEkUM7tWO7T3A75Yc7ueO/ yaiMywhAgECDRoeEDRscYYIECZMjR58yHIBUClMphabKCNlSC8KZMwM+2gnFzJWoWZ5e/WLg4hLL hr585arUiRUrZMh6SZo0CZcwSyQsPQr66B9Rf0aPIk3q70cZTAeO8aLkTcmBGJ8cEZjywkyDA5mS TLBggQidDQHIRLEQhEqHIEHYTDCY44YMC18mlCjRsOIBJV4OHPjkwssniZHKmCpUAQIEDyDt2Gkl StSmTateMfg1jGUmRzRSaaok81QnFJwkodZpCSgqVKpGES2qdLbRM2WSsUtxitIdAoFh6f/5hoES V69gxRIBYOFs2rVt38bdMLfu3bwHHFWMFM43pE9KuC/IMKPMhh/AGnuELKdVK5ImPTEYtvlSpEip imkKXckWqxenUVMyiSWgDIgKN/+oEhtttA1QQjUKrKAMJVMElowAmSghYXFfhWVBHB3IwJxabLkF l1x0WQDGGNYVBkkkSiyAyQINRXIVAQqEQF4FwHjggUdpDBBSNKJQs8lJmg2z0jk07NJMfpU800kn /ukiSQSqgZLlI84gqOCCSkFRwiszrFAEJbw0dMURpGSyzCkbHudhB2ahNeJzJkqHoop51XBAKZ/U V5gSkQTWnRfhzGDKBlswxhFIrYRCUkn/nhiDZA2X3OKZL5rEBGUnN6GWEy4CkhBUgtl4+SVSTGyD CSwfjKINOCskQMonynjTAwmj9OAVEQVtgACIIjpXYnTTWUAQEEA4kkkEj/wxQg950EKLFxmY+c8I phyQUaMfBRmKuKK4YiQ2v7gwX327FAOTaKWhgMxpV05CyWqPuPZIgkQN0a+//wI8RB0QxAALKKOA kkcsudTgCCm59PBar5n8apCwIe7RxAknHLLExoe0cWJdyjLrSFDSfiBLLKU4Eskpp7TzzwHGsLDF eRCAC5lIlBmJkmY1RLLLLqmApkkCscwkryTa5EQJLgMK9Q9s/AZcdb91/GDDJ0HFmkAC/37SksAI j3B1hAAVy/DGBEGwwAcHwQQjwttxc8BCniNLINZ1wvS0TgTCYOIUJpRQwuUqM1SwmKNAQtYKNJtQ ZtIvv9SwWSY0OJLLk5X0xwkyqam2GiiPcINKbP9YbfUPdVRzgDARaPNBEbSQ4kgCpTxb9tkFyQCX ASe4DbfcwnNwwt3J5m3BJ5mgIAxREYzgyEIuvEDJP+s8uAULjA3gUZCRtVfZKvDJt9ktmBddySk0 KY1aBLg8je9QUseWetV11HEFLI9oMwIOsbApQ6R4nTWuYbZfiYUNY0AH8JAQADSoTSyHKJ4BKICF uvzKOpmIBS3+sI7+eUEiXpjCKZwxCv9jsGMLP6iFjwYghY+EAlLkooYnUuKCldziFvZxhLtsYQtk dAInqZGFgKD2iFFM7R+qSkodoHAATAQlAjhQBiEy8YlSeAMHESjgAZNHjAU28IERtMAET1DBC45F AnlxxAGqlQc/jA0wNXDBKV5gQlM44Qca4UhH7DAASA2JZ/BJl/mC5ghNXEB9z3jBp6o0iaaNTn6j mJ8Sl3gUJmjAVbt5xAgI4IJPkIIUesAB2RrQxQ2kbQKKCCMafpWDHJTRAhasizjUWIIylKFa/htB BEoRiSu8gnCy+MAnDoAIRjGmj+AL3ypmgZL4XCITkejCfXxxgUSyojT/sdLTWJMvSlr/8igQKMEn rqAbTs5IDwSoAS2Coju0qW2VfHBgKyXwyljO0gK1zEsZ4MHBRwjjAzhQgiNiYINjUGIE4FjFJ/rw A0E0JmeA5NllMDOMGkizC13YVCJlUpqbRCAnsrBXUFCBxNOF0yhCKMMVIKSVYxyAFMYYxie8QA5a 8MpXwCJICRq4AQvgoQOvNEHxZIkFC5TgLopQRAzKQIpS9GAELziFHg5wBKtEYlYKOIAFkOmoR0XD FUWqIQNUsplIfCY/oSFNf0B1JfgRiASo4FqqLCkII1whBClYBiSO4QVS4LIGGcBAL3JKMWCpIW8+ BapQc0DUExgVqUpl6ipKQQscrOAO/y84gCliwABMfMIPK2BHGfpQgR51DyRyiCGRNiE5QtKnC7s4 ZGh8+CkhhlRAstCSa/ZVyXCyoARGCIUyYkGJF9SAFDGIAVbegdOJVSxYdJDBYn8VgACU0QgUaINk VamIMgyDFLToQQowUAoBWDUGFRmBH6zyBGR2BFyQkpSRJpckzjSkGfgRjUzihVssleqIKE3pFmTw iU/QjhLHuGI1nPCnKhQWusAiAoiAxwE+zONXgeCD3E6gXe4m1bu4rNYHtEGKWFQjBlWpCMK4lZGN QEAK6bGDHCbjilWs4lzQpE8quqC5jnbjU5w4jU4msVugCNi3KfXHFoSQBQTTDgMEZf/GKkxRA0KU 4p28S0LehBC8fpijHPzgg9uYoAVkEUQsyy1FKUbwgVLk4goCWMU4IgEJM5ihDMz4wY58dAbGhUQy rj2SZqJZn4ZozlNCdl+ASCqUbCg5pXwOgSgsW4oMKMARplheOKZACy2jUg10sMAcHKCxB5hjDILY ByNusIYzoyjNFiiDMUpBCoVOIRafOMI0QhBCM8ij1ypkjGMGACTWOoEyNUzJfOjDQ06JphttDZWR B4TkLQ0YuFtgBxwCV4o7ZGDTZXBEhmjBxd2JJQkLXMNcfOADuOSAAsJCBzpyAAOBBPW6ZSiBrT+A gSKU4ggHSAMTFqCQY4wjhTviHkj/xAUNns3ChvPRYUOeFItsDplpV3LavYJyut9aUnvYKEwbleGQ aVTjwLGIxbkRaIEvaqHeVuCCGJIQBQrIuwMxtze+O3DdvJiiFCUuBSGqcYQjZEF6lICEKfa8BUH0 yHuBnkxlPFHDdLGkPqnIhSMqkUjSvEBpOgmQEV2TxCUzIQihDAolTjERGzAAUCowgyp6cMAOGMAA xJjAdetULOiIzALCcst1EoIJF2SCFARwGBtt9dRSQCEejWlhw5khyBqWD1NdSKt+pNQ+eq0Gya/J tiWhYIQDuIAcH6BEETLgCFhgQrB+oLvdz4Z3vfOdWCQC/PEGHwTAVKQGBFgnKfqS/4HEH8AL9iiF BgYW0Uc5bjKSi898zpEKRzgpATJpq1vrJYsC6cu3IF8iBIwQnBX0gBIYIMzRXZABP6ig7nfP+977 3pzd4wlZvm9Y8AlAlWLWAFUongJ8gykYwQ9MXnzpzEgYScTFB9ZdgmzlAn5on+eBSpGFHijM1cct GQSUgR5ASPoVwULYwCs4wgLIQ/zVHoXRX+75Hf4dC4rsH3ZAwgEsgJ0RQCSQgilwC6Z9w74hYLF9 D3tQnWthBrpsxi6gVX58nS10wpClhqgQiFDoS10t0Q8YwRFcAQa8wCPggBc4ggDAQim4QArKn+21 oP3ZibEEnu8BRkIIRp9cRySAYf8pLIAXrMIwPMEKfdX3iES5TJ98ZJ1npII1JQBpxAsn9II20MvT EMhcUdL4qcoWKA8sQAIlCIMfENQRJEQZ0t784Z4a/l3+yeBzvOGf1EdEoN46LQTT0QwCMlyQQEqk VN2R3BB9GJImHIP2ZZN/MI0kUML3ZcnoiB/q2A/APN0rwMLSRQA53E6f+JI7fCIahmIAJAEg8AM/ GIIbZOMexGBd+B4h3M6J5UKtlGMpKEOtcNABVMMPwKIQhgtJNCBKCCJ9YM4hfV03JOLnQIJO7NYU jgKqxMYDEGRBGuRBPoA7ZsAr8MIpvA4h1E4xeYE8TCMLhmIi8MDcDE/ciEAi9N7/c9RAAtBOLhRB OnpNKdQKLeQCirFDBZgHaqnWzljGsmWeEhJNoj2DR3mOleyE6JiKQMpGOG0BEwgAJvDCUQJcKTDA K3iFhpjS7rgbW5TAhl0Yh2kkBwTCGVHHBMiADEBCn0xPJGCCF1REyzwR003DsDnKjM2XKIwPZqTL pShhxV2TEz5hL1TJlRBRXMkP6V2hHcAe4UjFNzxRMenBCGpZVHZAT/FBEziAA+xBG2RjP1BQPt1F V7qAnblIHXaHEoSD9HSHKQwDC1QAC30VjclQLTKb+czWfTzJlMhLleSEMOCClgQFUErilzCBEcBC MkgIJSyDb8RAMnDWKdzZUyaW/w9wgQ60AGPSE0HcU1HlU6qJRSSA5icEjiO4wAl6QUIkn1Xgg0Z4 AM48RigMSdVNDjTpEFrxkGiw1U66zz/ei9lZoao4EQNAyDK8wDLw4BVMg6YZp+4k53I2Jyu5EixJ JxpRp/IgxEIEhnZgR3YSwDewwwFsgOJQXuOEFWWsQnrikCHR1gXwB/u4TwTIwvcNCAmoArYFpSV5 4CsogAIowwscwydZVSYQwB0cp9kMKEEEwWIF1VAlKFKpiFgAjUKER3cihHYGjhLEaBnIAB+CSxqg ZijwzLkgSRLa5H7tRzZ9DtNMAoEM41wlUW4uSPnxGhf2lQuYAizAgiNkQAoQB/9ySoBy+iiQNtZj RVYJFKkFHEANBF84dOcVMelXEgAzfMKFEpvUrYdkKFtK/Aym7JAvHMMz2AJp2IQQBYgwTCEx+qWq sMqBVY+ClYIpvAJT1oCZbAhccEEY3Ok8/ZR1YVfxfBhSLaiLRARDtAwBXNET/QlnlQEiKA64PAa5 oKcNSeo0wURHOWGmpgbHlZSA1aduOlFCEI4ydMYVXMEVHcNWdEUmsKqrSsCPzpMPpNF1Zdd22eoY GCloAkYxLR7q0SDTrQJp8oj3BMlqhdWNzQI2lJUgZop1JlolBJlNyKYkWEJtIplJRVo41QETZEAy EA4vpIDrHcCbKsEyzKlXsKr/BSQBAMwB8DSBEfRBmJWABexD8cDaVhpE4S2EFyxAKfTJAhCAwXVH NbCDO36LsTWOlUaORc3HXFLgu3ROXtaL6BDjSbXoFdaBAtgA4bzAHShADWRnOKjqt3ZscoQsH/AA PzxAAWDBAwwBZZ7AytpFdDQEdp7gDXZHOChACEGCI1RDCKjQePZhK9iB5TlBZfhM9XWBS2jf+gjZ LwLj9/3EBn7qlzzsNBzAmbxAEbjAAVjIn1bPqk4AF1iAGgCAEVAlmcmN52Jlvd3bQABLg/5qy/wF HQLqRBhDNVTAHsUXlbJH+LyHfXGGdeKjaPBHIuZEBITearSG+C3ZFmxDYEbF/zHs4DTYwKYdpeVi 7sdawCJkJIe5jefewxqIrkAQhEE06EKkLURIBEVYBEYgU878ERE+KrJKasV1njYJkZE5YiRxoKQ1 xVNExVRUhY1oBZx0CFmYxTVm4zZ24zee7RrRYF/8RWAMRmH4EmIoBoxJXWQUoUlkhiBqXUNcwCHK BCccbE74pIF0ydKqim3ghm7whm98AnAIx8ZyCHIoh+7dCQFXRwlcR3ZsR0R4B3iIB3nAInnKYnvI I6Ug4VmxpzVdQCdc3KeESgSQ3cLObzg1yINEyIRUyIVkCAvHyYeEyAvGcODtCQ23yIvEyIy0jI3g iI6cR2rJokzOgjMhYTSdA/97hkYC2ALSNBK1hSkolAr9TOuChMmYlMmZpMmatMmbfGsWzwkMs+Hx fDE0AkqNQMKgFEpNIYqiiCflDeFkjA9ZrUQm6BDR7NfLaBOY2kttPkIkRSLatcqrxMqs1Mqt5Mqu SJjFDAsXLzKaScCyNMuzRMu0VMu1ZMu2dAvs4qscyMHDUYNJ9O0w5NDQZE77+keo0MJOjE4klekx AszAFMzBJMzCNMzDRIxhRdfFKDLv4bIumwwn9UDKrEzLvEzMzEzNwBixRsZIuML07dihFYPmVKDn aQPT9KMlOFoV1g82+wvWaA3XaIPXgI3YlNIppVIQlDMp4o3eOALfWILfAI7/4BCO4SBOaSaT1IXC w1XGLJQV9eHiIfmC9tlCwXLwxgmIHiMZlxS0QQ/B6rTO68TO7NTO7eTOU6KN70w0Acva8jTP80TP 9FTP9WQPC2xEfH2PHEhDubhWSsRHDehQa5aj+sCLLhDu0YregdS0QeOP/vCP/wAQhijDAG2RAaGb BSgQOpSAvYlRh4jBBORdPmUQDW9QB33QCIRQKYxQCZ1QCq0QJmsoRU1OocXW9W2KaHjp5+REtelx SY1Cw1pSEz1RFE1RFV1RFrV1F4nFF8k1XUOQXeO1VqbRGrURLbxRHP0pHdnRKOCRHiXgYzjqoGGe +WT1S2jCMwiuvIDpTsR0/1A4QyqnFCZpEiVwkieBkiiREqilkjxV5edaJWTl0z7dUi7Rwi710i8F UzASkzHZDPcAms+WSxZIHEvsAg3QAEfth+dxcE5IIRU+AlB2IDmZ0ymgkyOoEzu5E1DzTjxZGOiC LnajkXb30z8F1EAV1EEl1EI11A+Mp0ekx2pZHjXQUHpe1C1kwi78bTF83afUxPvG7wZedh/Txkq1 1Aq8VEzNVE3dlDjvlBoFgb39VFC1APXWw55OVlM9VVRNVVVdFaBoFVd5VWpFxh9uAg3tdidjzj7X 1kxwgjZ8TgQwcR4HxYFg9hLdVV7tVV/9VWANVoTplEEkllrguODxAJn1Q//yWFB3LVUMVNZlZdZm ddZnhdZoldbC4avOWKmTVwpstbcjgEbgdoPntI8kgIIwym/iLkhwDVdxHVdyLVdzPdeZS5cM3DgM bAA/TG8BgIUR1GqILRV4iRd5mRd6XdV6tdcnvBcLwWNIhIITlEuHmhVrOsI+97O82AToWEJPCIXw EpiBIRgpKBiDOdgnQBiNGwSFcbq9bZgI3AMLWOMEkLq6mvp3cXeJnViKrRgktNgwy/qfDSE0BDGk JoknzxY/X8Ap2EK8XGCYfp/8OAOxC6WTQRkpSJkjUJmVYZl0c5laPAHcYBheWEAOjMGr4bKaqVeb vVmczVmd3Vme7dlijGf/91DpejBgG5PVRWWCNBGN0byLNl25kVFClsyV6UA6bUxapdHCpWXapmVC p32agIfaqM1BIrwND+zBGGjAIKgIw8da8tCareGarvGar91ZsNHtQ8WiLNKX1fmrBbcmfkQJIm5T kdkm6bT8bNQMt3kbuIkbuSmDubm1y6kbOrDbDSwB1wJCvM1b9qJBvgXAvvXbvwXcwBXcwSXcFlQA 1DmKH4WENHDokWSedboms9rETZByTLdGJJopbYgcydGCyX0Cyqkcy6W9F43Bzs3cDrjNDuTczo2u 3QOd0GkD0Rkd0ikd0zkdRPkwZNiBNDT5WzKbpGrUM7/LC0TzEBEI1ECi/4rPRtqt3SO03dvFXSTM 3RlaZP0RSwvcQzAsgQMQsBs26OEl3uLVTkyBEptFnmmaO2q2R/om/t/yfpTYxHwX2T8+Gn6nlOmh nuqxnuvBnuxV5O1B/ws2AkAsCcYD0IYNOW7IsICgQ5AgBw6UglSDAIEapA4oyZAJoxd7pTTUgTBy QJoBA+yEciVK1CpPv7AxGDbsUiYaqZppqpSg0qlOnDjpkhRhUlFLjx6h+jdK1T+n/qBGlTrVHwQj er6t6EEJg5dPR464yOBHhaoeRwQQ6WDAALEJAQos4bOELg+BIjgUOJhwYcMgNRxJpKjkwKcDNQiT IqDgmykjPwRBOHMSZf+oUKJcbaK2ypixXzMv3YrUpVguTRcq2fqpTaikorIsWQKF1GltqrejQiij R4FWSkUgYbLxytECeWXPpl3b9u0JPhyCBcMbHe+JvQoZOgQs8cCCSJAIRCJlytSBDIzLlPgBDMLJ M3bstArVStSmTS9/uQCdaVeXZr5O8+knTpBxbRJZcIkNqUf+ccY23G77wYgjrsDghUdw8MIRAWAp xYXjzEJLLbbcCsABE5o44YRDllCRxQeu68shiDCB5BMXaoDIkUg0LGUBL1YZ5on1IPCAMvhCiaY+ lzyRyYVLLkknlZscQc2Wbjp5gZNeJJGEElwSRAoVVEap7R8Ib9vCgk//YIGEEmH8UMKRI2r80IwQ lSPxrQDIiMKCIKjwi40JDEIIO79oLOWTSCI5AJIDXLAoOEhMMYaFH0iS4qSU5qvPviZlquGSSHZx xJFceKqElReQ6aXACIiK7agFzRzC1ltxzXWILQR5BRZKIImAnARKybGUSNy5M7kRmQuATz8BFZTQ GLMLghBiSYkFVVJQLUWZBLKl5YBqfsC0SMoGkKOVleybBVTQdunPl2JQq6QTVpBBprUIZAHF39ke UaUppx4o2OCDEX6g3Axe4eUUYSIghBRHDPNCHmVFXK7EZ/8M1KFBC+Wr2hoSoIXbIr5NgFhwackl lmrYqcBcytJAkt37/17SD8rRUnFEE506ybITZDhxLQJcKJltNqYGPhPNqbZgQgBMeKm6iFJKYeCV AzJRhhIzGhBRAh98CLSEEnKAIQA03pjAAgvEmIAtCrBQ6IsJZJBhIkcxcSESTLyQaMcDajRlmi2I nGzTlFhqaZZfIAftli4c+c/KoAnUpkt+ZV26aaefjuoHO2DBhJLTvfmGcMP0AA5ssck2G2212XYb brkNoNtuvGXwGxJIeAzMRiXCceT3T0wZhoUKavHAyE3VhcbTLH5h4LOd400F1dTu1bLLoiiRlQSk RmHwqdCjYsIIWJLxmpJlCDgghmQOMOUUSF4XQI2xudChhbPTtjYiSP8gBznY39t0ZwFzjOFtkTCe jTCBCUe4oDheqNEBvBCDT+BjC+w5w2TskK51seslDNBZTbpAA0ekQhMJCBorCLQ5o1hifOQzH+jQ B4UDMKA3y3jBMshzhWk4wn74C5v++Oc/ANJugAU8oAUSuMC3fcIRNcJEYSJRvFJE0BEE+AY7DrCB CjiPZpWJBruw8ZKZ0CQSN/EFgOz1jKHpQnMGEoZsQDGmbJgJfbkpwysUoABlvOAYLjDMETJBgDsY ES3780H/JOCQtG3AAnjoQAHjIAEEYsECJQADAy1Qg+9AYgEZsGAVJxhBJQSyDDJInOLsoC5meMoT ntEPGynnC59xb2j/rRpKUUBBQ389Yo8P6qNVjjANC0GikKaABSwckYEUfO2IjoRkEALxnH5U8pI5 yOQmO/nJtx1GMOGw4CdKkcqJEIAZnxDjSCSzuJS4IjOe8ERMhiGqTDiiC2/MxQVOwYoBFQ0Sk8CF vyyBikc4I2DGRB8TtvGJT7zgdMcohSlesbUaFIGaXBsUF8Kgg0g6hwNLsMAAnZWECRjBCBRoQyel aAHg8c1UkSAAOgmnqPqVAREV8OCmKiO9TbgLcjIZRiZI5Yhi0OsCWJpjayAhq4SiQhXlc2jomKDD Gp1OGfu8whXQeYwXgM2jEwCpSINAUpOiNAAqZalLYQpKwPwOIoYh/4AjICU8Sq1ieSNRXM3kIAdo ZAZn+dGZOiKBE19c4AKqyVfRvnfQYSalqld9Wh2YkIFknI4XKcgAXqGphGV0NBMftUASADCHejwA CQPogznKUQIL5GAMa9CCoSxwN4McoIrB8cICitUdAizgeDArFzA8EE/4xGcl1NhEGmUCpZokthg/ a+wLg/K9SchGNgotk2XR9IM6KMAGp3vBHRRQAy6Gg6NkLa1ZT5raOQTgBiV47Rg0MIhP2ha3ut2A qT4hwQV4x0bhUIAXfueIaoQAcUVqz+LkcJn6zAIbxngSlGyywtOgphMoaBVkJQEbPCpUKeCFEGan cQBK8OIFRXDBAf+SIYDDUNS9plUDAIywBoSQbVA5oABD0IGOtKEBDSI1SG91uiMvHIBHNcAaJoxR jQpsoRaZqoyEh2rP6tFkVJQ7FWpOoZqg7AtpwRwT+UyMmy1so3QrpsQxxjMNG5jiE1WrMXxRawEh W4ELYkhCFCjw4w5oQcgwILKR/1uj4AA4A47aokQoVQYhUDm5sIwwZrJcYaOOylSnqkRjVTO0osHq QP9a6D9u2Eeo/KAMVzwGLyjhDcJosItTGGsDuKbStxGBDhvgWLQ+Nq3+TuBspuKOEpZcGBd4BRLH KoMpClEBeB7p0iy5Dzbyw2VGrfCfPIEhUEY9CUrABhXjq2yab3P/hjIkgx0pOAUl7hA/NmEFA6TV dXwt8GuPBQFkMbrb2XgrkSzGb3gEL+UMyrABTCX3SPNRkhOy/Jl8IrYLkciFaZ6hqg7rgksGio2Z kdI0VftjACWoRm+8NoXCxDgTSvCae+8dhw7IQN/SCplCPgnwT/wuEkpYACYWUFMqLiYECWdeeyw9 n8y4S40XRmoXLs4Tn7CqQEPxUjBBQQLvilzVUCjBK2awAo7ywlRXOAIpMrGMU8DcdjL3dZ86ZvMY 5bwExlpUJHauhEbt/BNeCMcMTLGBLcDzgyFsxeFZMovHVc/pu6DBxXVyiko8VihE+ZK/vPvd8/UR opiAxQdGoQ1w/6wAXJ9Qhjd6QIJR9IBrAzQIQ2gOd2DzW9h8ESkQgOCITETgEX8YQQ/yQAtaeCED HP3HCMoz6eY9eFP0oWWThnHhS9BgFwBCTSzuNebvUWK7s1HoIzSvK/HfSiQxgAUoRgGKPGgLMNzq QVVZnwnXbwD2+VgCdKSDfxHwAB8xun3uHQEpfu8DZCEW0ikSTuEU2uEfDsBStsADgGEyNAUl5EBJ 2uUVjCG6kGoXEksTcqEnTgEFOkEbOs6ggkk2AuaG/mH8xq8OfsAGPoF8tEFlIoIWEmAEHiF/XE8G 2iYICuA5qEP/8sL/NMkCeEsY7mgdIkAYIohwTsdBVmEGKmCMnP/nDKSgZlLCAjfBJRjAqERDhU5F J2zBFoiGaAwkfGLj+zRvBVlQV8SrGg4AYrThA4rAZByBWHhPByVgA2RgUAzAOfjARVrkBO7POnBL pKYoE1BAGJwiAkbAePqGov5hHU5uC1gAuZ7nytalXaBvJm7hFmiABqpLJ+xF1GQI676PQZqmDXWl DurgCmDhEbRhBHAgFtDO5UgBYqzhGsTmbdhgDNDBOZBgbdrmbQ6BA04gd+rmpCQA4DIhFmjhD9Zh FhGsFLxgCk7BGUbBGNihwR7MJFCiFZSkPrRM4kbF8XapEnqil7rENWThjmalodCNKupAq5AiAnBA GQghE9DJG3D/IAJ2sRctgBiAURiJ0XaOMRkTaICK7QCELw/8AAchogZc4BReQBtNwQl+gFc84IOa LxRmiRxLCDRIZReawTR6whYEaku+Bwllo4ZGQfNGjgk0wPPe7RFGgAAMiRRIQQ9wIAePaAfbRhEM Eg2aKAcSEoqWURyasQTKoAyEjxZHIAKO5Qpe4XRk4QMMAxEeUDIUpzJmaQs94RW2bLpW6CRJ0SdY oTVc43SCKeTODYdCBwJK4BOuwN1wMuj0wCJoASn0kA+HsiiPMikTiCnPpgzgARofQRg+AAfkJAZs 4BgoYQTAYRU+oQ+IBOmWKxSkwRU2Az/MkVFU6GfsBYbMULve/5IEjmIUikkun0YIyuAKesPWjuEA SMEYhqHvyIEWVq/19nADRKoEhJGSLKmATAAZlbKT7kYRFCEGyoAUSqEHRuAFTkEPDuAINCgSRk8B DsACBu9cTAJJLuM+KOwzniQTLiEVKIcUKyEWWAEFQOx0LGESzAzV+EjVBMEIriAEUmAZmMkLSOEp ayADMKAXelP+fvOAhpObjBM56UY5J4A5Y2AVSoEWcGAF7uAF6icGGAATPsEPVoAdyqAPfKojPTKW EA/i7MlJjmrbWChVsKQMJaGgwOTjMm8ep4IFSsAIQkEZYoESXuAiYiAGuugdeDP+5g8B6EAGnCMY VGSAHIAQkf+xpV6qBJZTEcpgGEiBFnogBTCgFGQMOyViBPxAg56Ays6FMuZDwpgON7mMP7SHNO9F 1OroQFAwHu+zj7ZABiTKZN4MnarBCRSlCgwUSX9TLWTgBzlgLgbIH/gALwqASiGUOZ9S+D5AG7Kl GmJAfiQi/ZKvg4rkK+dDGkTBCdwlJvJjZ1SouhJAE54hoFjBVX6p+8yMTLhOT4UgCz5B+EgBA+SE GVbBFGqAEErhL2UgCTSpHvoBOhgBtviBD/igCRbhtmyvCIcUa0bgA0ohF65AAFZhHL7DDMygDJjh B3yKJEoilpJEFJxrLM2xJnZBe3xBHQWEaOrUoNIwBWVS1cz/NQREoUJL4TyI6BMyIRymgBaMVQ3o wALmq77uK7/2i1oVAhEtoAyMoRRIgTKnIBa+YhpCAMHMQB48FnGaB12QxNqYrgtpIh1uIV5TwRf+ KTU8TF8iwOMUBPzMxDXRhAW2gB3gIIJK4Q4ygM7KwBFcjhYCMi2KMAmAUcdugMcmwMeArNCIzJKc JT0w9gMw4GqO4ADSgAmIi5nGoRvP1T1OQl1uBj+MKhOQKk4ZKwEfS7sM6o6SgkFSTdUsERt2ziGV gWKmoRokKhZiIWkH6G0IktBygM/8DNAEDXENDQ2sNgDOxhRK4VJLgRCqASyywHiAxRTK9TsnIw0A izNLdRZW/wHbric0uqBntsdePAzEiuKgbvZzZjIIeBIpKOEUtsgGGGBRVABj8qRZai7Ybk5GHqK3 +oYj7mpibPMToLMUoCAeqswjsTAUpMcVVmEVtkxnRsNUom4M8QXE+CVMaCVPc8gIIIUcPuA3Pqt0 BtQPgJdZNkb29q3fcKtaIEIwKuIiMmIjOuIjQoI92gML5WOWMgPbrIcmMqFluS3yToETBuSX/KVf jkKhWnPkrAIrfKMrviIsxgI5MkZPnIV+5e5+/WI71okwDAMxbHMxGuMxqgwCpACE5iMkhwqfLoxR WOifOGyg2hEX7ugt41JnIUQ3eMM3gEM4iMM4QDh45xda6v+39g5FO4SnO74jPMajPM7jG9LjB6rM RClQPjBjFSjMhLTNgXCCJzBHS7iEKGq0ggPmVtFHQijEQjBEQzjEQ0BkWTRmT0iYeKkFUQjHRnBE R4LHR4BESBaOeiuDPj4TP7hsctbzGHhJS0aNX4Ypj2gDR6VCTdjETeBETugEEuwET+TXj6G4hEVG kDFBURjFUSBFUgrHUry4I48kPrDsnqxHP9JhNNZzJ0oThtpREhKEbm21VlgRV3jFV4BFWIjFWJAl fvs4ABJhDwCBH/jBENwAm/cACxIhkB3iWjBWW8ClW74lXMbluNJ0MxvnPhKYJm6hbXOhGVJFJb/t e6RKoVT/QQUTpp8NZmEa5mEiZmIq5mJMeZpJKgiD0BBXWTtK5mRSZmW21GVgRmaAAbnSFUlINeLM c1QyzGcSIOMwBxk0B3zCZ7LicuSiZmqqhheuJmu2pmuoCXbKpgOE8zmgFS9ymgMCgWrR4G7yZm+C w28AR3AapXAOZ+FsmQIljBxfoQsvjANTgYUuIAHGEHNa4zVwgQQAJqX5lXRMB3VUx0MPoHUYSWlj x6b3rM/+LJtEYB4cl8iAundG6ZCHp3iOJ3mWZ3pPomZGFeJMF3JSt201YbF4KV9KcBLgEWCyQY6x an3a53TgR37op4jyx5qUSN/cIDrmAQCKN6Yc6Hi4iIJ+/+SCMmiDvnMAQheXo2ETJqzpoEQ0TOVn QnqkX8U10rCGBIaTo0KHeGgFfAiITEGIiOh+LjuJ/ufX9uAeBsIBpFiBQImKrAiLtIiLvAiMxOiL G04lnIAcUdcTeeaNWqhe9WVGxU3E6jZnMfiPAmmQCumQEmmRjvuR0Ipj6mEeoEMI7JcvxCmURqmU TkmCXECVWMmVBFie6IOwUFdnRKNUAIQnngFf4LMdxQ2hSIwb9vWYJkSZXoCZXMCZoEmaZhqJ6DuS OGYJIJX2ire/yWkizMlD02nA16md3ilNm49UnYBJoDq2SyUnPvAZHEtWiaL7FsSqeBsqIEqiKOrN LiqjDv+jvXDtvc7KxPuEEaRjHgAZt2JqphZtR26qFHLKMEyBp6QtnkQ3HJ2PGrABgd+UVCAv4yoB KDhObvPoKJbCfLFKq9yEErrKEb4qrG6trKY8CPgECaJjCVRZIWJqrh6lMA7grvIK0kyBr47uK5Ek LN2FLNfWRUlTZoWZwtHwLVuTiHEDszSLszwLtIx2tO6MC04rtQJgD6BjCaplv3dnt5D3t4JrAYar uNihXKrsSAbAMrBsFsgydXVYvNUxFrTEl9z4BFFQHkk9QsarvIAUvdRLgtiLtEyLCFKLBXgAOvaB RQQRRobtyChGwAjsEwwMwSBBwRhMqdHF4WhpzV3A6Rz/yPpKEV+qjtROejY+Z9rpkQlSbMVa7MVi bMa4Hb5uzAhIaqcXWhkn9jeRzDCUjMm8wMm2KMqmLFRXu4Y9ZRU0/Ty7Nwyva2h6QXOIQha2q7v0 +cj9Yc3aDNbgzHDmrM54odVf3QLiIhjoYgnsoi4KQOItANF6q8s/odGarZV/Z8wnjfBOohUYZyVc oqi0rVR2uBK6QaA8jC0Vm7sChqpgntVcDdZkTX6GztbYbtd6bXYEiIAMqAgT6N9KwNgeBdnqatl2 ztmgTdqWOhxB0tpK6IQYBepMQ41N814TRJhYM8PRR93Yzd3gTd5ggd7szXa8vZMCyCjh/onmnthK IOCA/yccCO4TlMDgMgDhFK4WPAiE4ENJnGsVrCdUQqM/lKqF5IhoiqZOJWtBaFfVSu7kViDlVk4A Wu7lojzmZi4IJolBvUnuOcmTxkDneM7ngE7oukgBik6Mfgp6OqUldHmNLoEDO5AUuyFfTlPckiaP vAvPn8brwE7sVqzszi7t1i75264DNoD5YQAgNljA0yFHjjgSLFiggMVCCTBjSpSocaDUp0iRPkFS EumAxk9ews0wtWELBAgezgxIY8dOKGauRG3C5unXr2HDLmWKlKqZJk2VKrFCxomTpAhHKckCZQnU o0ej/kn956+q1atY/THZhgnWh1HawK1IQOqTMm89SP+M6nEgExEJGzYg6CAjSA4YAt8GCJBkghEj FNo41CEBCBBHmSI8+jOiRx5atLxkKELp3whTB4RsAZZyJUs7raBtGr3KZs6cGFM50nSh0qlTnYgi kyQJ0iRLTUGheqRK1dQhwIMLHz6kDoQYsECNApUnVq4ajkjl6qFqbdu3cefWvZtXwt6+fwMPLnzY 0dPGH2TFKuUo0ut2/w4YY7Gl1skB+Ae0asVs9KbSDLiA0yUYOZLLTwk8U0lss0kyiW2gOLXbKLz9 RtyFwNXxgw2fPAVWAglUREsCIzxiRgNHCICdDG9MEIRdVhjRhznllGBBDmOsoUUON8hgAWEKHeCI MMKtWLJOBMJggskBmFBCiTP/rDJDBRXcl19LoUgj0yyevMJAgJfccgtPvvjS2im2IPMCJ9rQNskk lDD1iCWo/OObVBhi+EMd1RwgTATafFAELaQ4kkApip2Y4opsTGDAHAHcUMKMY2gwCEQ68ugjkBZ8 kgkKwkgVwQiOQIKJCy9Utk41CmzBwn0qDQDafqK4soknxhgDpk48NbPaBbbEwkonRtEmiSWUNPUU VFFJFRAAOw== --=====002_Dragon167653843133_=====-- --===============2042956037== 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 -------------------------------------------------------------------- --===============2042956037==-- From ipv6-bounces@ietf.org Tue Jan 11 19:25:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20009 for ; Tue, 11 Jan 2005 19:25:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWYO-0005WS-8U for ipv6-web-archive@ietf.org; Tue, 11 Jan 2005 19:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoW3K-0007JY-NI; Tue, 11 Jan 2005 19:07:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVxR-0005tO-Ou for ipv6@megatron.ietf.org; Tue, 11 Jan 2005 19:01: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 TAA18009 for ; Tue, 11 Jan 2005 19:01:50 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWBL-0004wB-BA for ipv6@ietf.org; Tue, 11 Jan 2005 19:16:16 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j0C02SCR010297 for ; Tue, 11 Jan 2005 18:02:29 -0600 (CST) Received: by eamrcnt751 with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Jan 2005 18:01:21 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CQCDMBDL; Tue, 11 Jan 2005 19:00:50 -0500 Date: Tue, 11 Jan 2005 18:58:58 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: ipv6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: ICMPv6 Source Address Determination - Paranoid catch all? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 Hi Folks, In my implementation of the source address determination algorithm, I have noticed that branch (d) is never traversed (section 2.2(d) of RFC1885,RFC2463 and draft-ietf-ipngwg-icmp-v3-06). This condition has been around since RFC1885. Does someone know under what condition this branch will be traversed? Is this just a paranoid catch-all? Cheers Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 12 03:42:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22771 for ; Wed, 12 Jan 2005 03:42:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoeIy-0007FM-5s for ipv6-web-archive@ietf.org; Wed, 12 Jan 2005 03:56:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Codxg-0004Ju-5d; Wed, 12 Jan 2005 03:34:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Codut-0003xp-Rk for ipv6@megatron.ietf.org; Wed, 12 Jan 2005 03:31: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 DAA22133 for ; Wed, 12 Jan 2005 03:31:46 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coe8p-00072l-Mk for ipv6@ietf.org; Wed, 12 Jan 2005 03:46:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0C8V5u20462; Wed, 12 Jan 2005 10:31:05 +0200 Date: Wed, 12 Jan 2005 10:31:05 +0200 (EET) From: Pekka Savola To: Suresh Krishnan 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: ICMPv6 Source Address Determination - Paranoid catch all? 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 Hi, On Tue, 11 Jan 2005, Suresh Krishnan wrote: > In my implementation of the source address determination algorithm, I > have noticed that branch (d) is never traversed (section 2.2(d) of > RFC1885,RFC2463 and draft-ietf-ipngwg-icmp-v3-06). This > condition has been around since RFC1885. Does someone know under what > condition this branch will be traversed? Is this just a paranoid > catch-all? If you don't implement (c) [I have heard of only one implementation doing so, and I argued it should be removed], (d) should be needed for ICMP error message generation, because neither (a) nor (b) applies. -- 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 Jan 12 04:22:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25170 for ; Wed, 12 Jan 2005 04:22:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coew5-0008CN-Oy for ipv6-web-archive@ietf.org; Wed, 12 Jan 2005 04:37:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoegH-0004GC-GH; Wed, 12 Jan 2005 04:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoecY-0003eD-VS for ipv6@megatron.ietf.org; Wed, 12 Jan 2005 04:16: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 EAA24940 for ; Wed, 12 Jan 2005 04:16:52 -0500 (EST) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoeqR-00085o-7y for ipv6@ietf.org; Wed, 12 Jan 2005 04:31:21 -0500 Received: from [81.187.254.249] (helo=study.dial.pipex.com) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1CoecE-0002TN-Vp; Wed, 12 Jan 2005 09:16:35 +0000 Message-Id: <6.2.0.14.0.20050112090031.01e8c270@imap.dial.pipex.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 12 Jan 2005 09:19:00 +0000 To: Pekka Savola , Suresh Krishnan From: Elwyn Davies In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipv6@ietf.org Subject: Re: ICMPv6 Source Address Determination - Paranoid catch all? 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: f66b12316365a3fe519e75911daf28a8 Hi. At 08:31 12/01/2005, Pekka Savola wrote: >Hi, > >On Tue, 11 Jan 2005, Suresh Krishnan wrote: >> In my implementation of the source address determination algorithm, I >>have noticed that branch (d) is never traversed (section 2.2(d) of >>RFC1885,RFC2463 and draft-ietf-ipngwg-icmp-v3-06). This >>condition has been around since RFC1885. Does someone know under what >>condition this branch will be traversed? Is this just a paranoid >>catch-all? > >If you don't implement (c) [I have heard of only one implementation doing >so, and I argued it should be removed], (d) should be needed for ICMP >error message generation, because neither (a) nor (b) applies. On the other hand, not implementing (c) could lead to situations where using (d) could result in the ICMPv6 message having a link local address as source if the interface itself only has a link local address. This is OK for neighbor discovery where everything is link local but less so for an ICMPv6 message that came from outside the local link. I reviewed this document for the general area review team on the IETF last call a while back. In my review, I made some comments related to source address selection... Section 2.2: I have noted previously (in connection with Neighbor Discovery) that the source address selection rules can lead to situations in which the scopes of the source and destination addresses are (legitimately) mismatched. It should be noted here that such packets MUST not be dropped by the packet transmission mechanisms in the node. Suggest adding the following to the end of the section: Under some circumstances the scope of the chosen source address may not match the scope of the destination address. ICMPv6 messages MUST NOT be dropped in the node that generates the ICMPv6 packet on account of such a mismatch. However, there are also circumstances under which this mismatch can occur and is unhelpful. For example, if an interface on a router only has a link local address, rule 2.2(b) may result in an ICMPv6 response to a problem with a site or global scope multicast destination address being sent with a link-local scope source address. In the Neighbor Discovery cases, this is not a problem because all messages are link local anyway, but in other cases the ICMPv6 message may have to traverse some routers on its way back to the originator of the offending message: it is inconvenient to have to make special cases for scope checking here, and the message is much less helpful when it arrives back at the originator. The problem could be considered to be a misalignment between rules 2.2(b) and 2.2(c): some thought needs to be put into what is the best solution, but the scope of the ICMPv6 destination address and the nature of the sub-protocol need to be taken into account - 2.2(c) could be allowed to override 2.2(b) if the result was unhelpful in the way described, and a global unicast address belonging to the node could be used in place of the link local if the packet is expected to traverse other routers. ------------- In the light of this discussion, it is possible that a more useful set of rules needs to be created. I have also had discussions with implementers related to these rules, so there is clearly a problem for implementers. Regards, Elwyn --------------------- Elwyn Davies Consultant >-- >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 Wed Jan 12 05:17:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28589 for ; Wed, 12 Jan 2005 05:17:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cofmr-0000r8-4W for ipv6-web-archive@ietf.org; Wed, 12 Jan 2005 05:31:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CofUA-0005sg-6z; Wed, 12 Jan 2005 05:12:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CofPP-00059q-7R for ipv6@megatron.ietf.org; Wed, 12 Jan 2005 05:07:24 -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 FAA28115 for ; Wed, 12 Jan 2005 05:07:21 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CofdL-0000gc-Kw for ipv6@ietf.org; Wed, 12 Jan 2005 05:21:51 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0CA6iC22556; Wed, 12 Jan 2005 12:06:44 +0200 Date: Wed, 12 Jan 2005 12:06:44 +0200 (EET) From: Pekka Savola To: Elwyn Davies In-Reply-To: <6.2.0.14.0.20050112090031.01e8c270@imap.dial.pipex.com> Message-ID: References: <6.2.0.14.0.20050112090031.01e8c270@imap.dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: ICMPv6 Source Address Determination - Paranoid catch all? 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 On Wed, 12 Jan 2005, Elwyn Davies wrote: >> If you don't implement (c) [I have heard of only one implementation doing >> so, and I argued it should be removed], (d) should be needed for ICMP error >> message generation, because neither (a) nor (b) applies. > > On the other hand, not implementing (c) could lead to situations where using > (d) could result in the ICMPv6 message having a link local address as source > if the interface itself only has a link local address. This is OK for > neighbor discovery where everything is link local but less so for an ICMPv6 > message that came from outside the local link. In that case, I guess (d) would have to be reworded to better match reality, for example, from: (d) Otherwise, the node's routing table must be examined to determine which interface will be used to transmit the message to its destination, and a unicast address belonging to that interface MUST be used as the Source Address of the message. to: (d) Otherwise, the source address is determined by the same way as for any other packet the node originates. ... This prevents the problem with no global address on the interface, because the code will should pick a source address of the same or larger scope for the reply.. -- 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 Jan 12 05:58:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00990 for ; Wed, 12 Jan 2005 05:58:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CogQY-0001lM-Cx for ipv6-web-archive@ietf.org; Wed, 12 Jan 2005 06:12:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cog7d-0006Ei-HE; Wed, 12 Jan 2005 05:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cofzd-0004wJ-Rz for ipv6@megatron.ietf.org; Wed, 12 Jan 2005 05:44: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 FAA00231 for ; Wed, 12 Jan 2005 05:44:47 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CogDd-0001Ug-1e for ipv6@ietf.org; Wed, 12 Jan 2005 05:59:18 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0CAieo19845; Wed, 12 Jan 2005 12:44:41 +0200 (EET) X-Scanned: Wed, 12 Jan 2005 12:44:29 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0CAiTeO008264; Wed, 12 Jan 2005 12:44:29 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00xQ40Ew; Wed, 12 Jan 2005 12:44:27 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0CAiRx10172; Wed, 12 Jan 2005 12:44:27 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 Jan 2005 12:44:16 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 Jan 2005 12:44:17 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 Jan 2005 12:43:27 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2005 12:43:27 +0200 Message-ID: Thread-Topic: ICMPv6 Source Address Determination - Paranoid catch all? Thread-Index: AcT4kMFt4XDrRWWDSw2CPillHNZOAAAAp1qA To: , X-OriginalArrivalTime: 12 Jan 2005 10:43:27.0866 (UTC) FILETIME=[8CC295A0:01C4F893] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: suresh.krishnan@ericsson.ca, ipv6@ietf.org Subject: RE: ICMPv6 Source Address Determination - Paranoid catch all? 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Elwyn & Pekka, > In that case, I guess (d) would have to be reworded to better match=20 > reality, for example, from: >=20 > (d) Otherwise, the node's routing table must be examined to > determine which interface will be used to transmit the = message > to its destination, and a unicast address belonging to that > interface MUST be used as the Source Address of the message. >=20 > to: >=20 > (d) Otherwise, the source address is determined by the same > way as for any other packet the node originates. >=20 > ... >=20 > This prevents the problem with no global address on the interface,=20 > because the code will should pick a source address of the same or=20 > larger scope for the reply.. I think that Pekka's suggestion looks reasonable.=20 John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 12 06:06:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01567 for ; Wed, 12 Jan 2005 06:06:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CogYP-0001wv-EN for ipv6-web-archive@ietf.org; Wed, 12 Jan 2005 06:20:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cog9w-0006bo-3l; Wed, 12 Jan 2005 05:55:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cog3e-0005TT-8N for ipv6@megatron.ietf.org; Wed, 12 Jan 2005 05:48: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 FAA00547 for ; Wed, 12 Jan 2005 05:48:56 -0500 (EST) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CogHZ-0001bB-Ix for ipv6@ietf.org; Wed, 12 Jan 2005 06:03:26 -0500 Received: from [81.187.254.249] (helo=study.dial.pipex.com) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1Cog3P-00014H-FF; Wed, 12 Jan 2005 10:48:43 +0000 Message-Id: <6.2.0.14.0.20050112104850.01e1fbd0@imap.dial.pipex.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 12 Jan 2005 10:51:14 +0000 To: , From: Elwyn Davies In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: suresh.krishnan@ericsson.ca, ipv6@ietf.org Subject: RE: ICMPv6 Source Address Determination - Paranoid catch all? 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: 69a74e02bbee44ab4f8eafdbcedd94a1 The revised wording for (d) (with s/by the same/with the same/) looks OK but doesn't cover the other corner case for 2.2(b). Elwyn At 10:43 12/01/2005, john.loughney@nokia.com wrote: >Elwyn & Pekka, > > > In that case, I guess (d) would have to be reworded to better match > > reality, for example, from: > > > > (d) Otherwise, the node's routing table must be examined to > > determine which interface will be used to transmit the message > > to its destination, and a unicast address belonging to that > > interface MUST be used as the Source Address of the message. > > > > to: > > > > (d) Otherwise, the source address is determined by the same > > way as for any other packet the node originates. > > > > ... > > > > This prevents the problem with no global address on the interface, > > because the code will should pick a source address of the same or > > larger scope for the reply.. > >I think that Pekka's suggestion looks reasonable. > >John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 13 10:13:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17308 for ; Thu, 13 Jan 2005 10:13:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp6to-0006Tm-0F for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 10:28:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp6QL-0003su-5s; Thu, 13 Jan 2005 09:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp6Gk-0000as-DQ for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 09:48: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 JAA15326 for ; Thu, 13 Jan 2005 09:48:12 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp6Uy-0005wD-Jl for ipv6@ietf.org; Thu, 13 Jan 2005 10:02:58 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j0DEmmCR028856; Thu, 13 Jan 2005 08:48:48 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Jan 2005 08:46:07 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CQCDMM0H; Thu, 13 Jan 2005 09:45:19 -0500 Date: Thu, 13 Jan 2005 09:43:23 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Pekka Savola In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: ICMPv6 Source Address Determination - Paranoid catch all? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 Hi Pekka, That sounds good to me. Why do you want (c) to be removed? Is it because there is no support for it (or) is there some other reason why reason (c) should not be implemented. Cheers Suresh On Wed, 12 Jan 2005, Pekka Savola wrote: >On Wed, 12 Jan 2005, Elwyn Davies wrote: >>> If you don't implement (c) [I have heard of only one implementation doing >>> so, and I argued it should be removed], (d) should be needed for ICMP error >>> message generation, because neither (a) nor (b) applies. >> >> On the other hand, not implementing (c) could lead to situations where using >> (d) could result in the ICMPv6 message having a link local address as source >> if the interface itself only has a link local address. This is OK for >> neighbor discovery where everything is link local but less so for an ICMPv6 >> message that came from outside the local link. > >In that case, I guess (d) would have to be reworded to better match >reality, for example, from: > > (d) Otherwise, the node's routing table must be examined to > determine which interface will be used to transmit the message > to its destination, and a unicast address belonging to that > interface MUST be used as the Source Address of the message. > >to: > > (d) Otherwise, the source address is determined by the same > way as for any other packet the node originates. > >... > >This prevents the problem with no global address on the interface, >because the code will should pick a source address of the same or >larger scope for the reply.. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 13 10:52:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20862 for ; Thu, 13 Jan 2005 10:52:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp7VT-0007Kb-La for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 11:07:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp77k-00068a-NP; Thu, 13 Jan 2005 10:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp6yq-0003pA-8V for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 10:33: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 KAA19633 for ; Thu, 13 Jan 2005 10:33:45 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp7D3-0006vF-DR for ipv6@ietf.org; Thu, 13 Jan 2005 10:48:32 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0DFX7C31379; Thu, 13 Jan 2005 17:33:07 +0200 Date: Thu, 13 Jan 2005 17:33:07 +0200 (EET) From: Pekka Savola To: Suresh Krishnan 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: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: ICMPv6 Source Address Determination - Paranoid catch all? 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: 2409bba43e9c8d580670fda8b695204a Hi, On Thu, 13 Jan 2005, Suresh Krishnan wrote: > That sounds good to me. Why do you want (c) to be removed? Is it because > there is no support for it (or) is there some other reason why reason (c) > should not be implemented. There is not much support for it, it is too ambiguously defined to be useful, and because it's not sufficiently well supported, the hosts cannot know whether the address was chosen to make the diagnostics easier, or just chosen somehow. In short, it's not proven to be useful and much implemented, and because of that, it can't be used in any reasonable way by the hosts. On the other hand, it incurs code complexity and makes the selection of the source address less deterministic. -- 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 Jan 13 13:55:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03651 for ; Thu, 13 Jan 2005 13:55:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAMX-00036s-KM for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 14:10:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9xd-0004NC-SV; Thu, 13 Jan 2005 13:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9sW-0002a3-9g for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 13:39: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 NAA02502 for ; Thu, 13 Jan 2005 13:39:24 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpA6k-0002iy-Dx for ipv6@ietf.org; Thu, 13 Jan 2005 13:54:14 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0DIdKdt017700; Thu, 13 Jan 2005 11:39:20 -0700 (MST) Received: from localhost (d-mpk17-89-136.SFBay.Sun.COM [129.146.89.136]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id j0DIdH53003173; Thu, 13 Jan 2005 19:39:18 +0100 (MET) Date: Thu, 13 Jan 2005 10:39:15 -0800 (PST) From: Erik Nordmark To: Pekka Savola Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: H.Soliman@flarion.com, 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 Reply-To: Erik Nordmark 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 [This got stuck in my outbox] > - 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.) FWIW This is implemented in Solaris 8 and later. I don't know if there is an second independent implementation though. > 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. As you say this is an implementation note. But it also attempts to re-emphasize the fact that the "on-link" and "addrconf" aspects of a prefix information option are completely independent. > 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. It is an odd "SHOULD" in that it doesn't add a requirement on implemetors of ND, but instead states a requirement on some potential other protocol which uses proxy NAs. But I do think that MIPv6 is an example of this. Even with multiple Home Agents on the same home link, MIPv6 ensures that only one home agent performs proxy ND for a given home address. > 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.. Leaving the first paragraph as is, since it is basically explaining the term, and adding something before the second paragraph that "Neighbor Discovery allows a router to load balance traffic towards itself if the router has multiple MAC addresses by ..." > 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. I'm not sure removing aids in clarity for folks that come from the IPv4 word. In ICMP router discovery, part of the reason for the preference field was to handle routers with different stability, and that reason isn't present here due to NUD. The fact that we've seen a need to introduce preferences for other purposes is separate from that explanation. So perhaps adding a note that preferences can be useful for other purposes with a non-normative reference to the new spec would make sense. > 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. Or at least clearly state the assumption that 1) this is only performed as part of a suspected movement 2) suspected movements are assumed to be uncorrelated between different hosts i.e. we assume that a trainload of wireless laptops wouldn't all detect movement and send a RS at the same time 3) the 2) assumption might not be true in all cases > ==> AFAICS, you can remove 'both the Override flag is clear and' here, > because the same result happens if the Override flag is set. No. The "but do not update the entry in any other way" does not apply when the O flag is set, since in that case the recorded link layer address is updated. > 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? Can't SeND nodes choose to ignore redirects that aren't protected by SeND? > 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. What's the bug? If there are no on-link prefixes advertised, then the host will send all packets to a default router. So if an attacker sends RAs with a zero valid lifetime for all the prefixes and a zero default router lifetime for all the routers, and advertises itself as a default router, then all packets will be sent to that spoofed router. So I think the text is correct. 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 Jan 13 14:06:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04235 for ; Thu, 13 Jan 2005 14:06:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAWg-0003Jk-0a for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 14:20:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpA9Q-0008HN-5Q; Thu, 13 Jan 2005 13:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpA4m-0006VT-I6 for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 13:52: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 NAA03375 for ; Thu, 13 Jan 2005 13:52:06 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAJ3-00031W-9r for ipv6@ietf.org; Thu, 13 Jan 2005 14:06:54 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0DIpUR04896; Thu, 13 Jan 2005 20:51:30 +0200 Date: Thu, 13 Jan 2005 20:51:29 +0200 (EET) From: Pekka Savola To: Erik Nordmark 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: 8fbbaa16f9fd29df280814cb95ae2290 Cc: H.Soliman@flarion.com, 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: 6640e3bbe8a4d70c4469bcdcbbf0921d On Thu, 13 Jan 2005, Erik Nordmark wrote: >> 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. > > It is an odd "SHOULD" in that it doesn't add a requirement on implemetors of > ND, but instead states a requirement on some potential other protocol which > uses proxy NAs. > But I do think that MIPv6 is an example of this. Even with multiple Home Agents > on the same home link, MIPv6 ensures that only one home agent performs proxy ND > for a given home address. Even more reason to remove it from here, unless it has been implemented (I haven't seen it for sure -- doing it robustly is pretty difficult). >> 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.. > > Leaving the first paragraph as is, since it is basically explaining the term, > and adding something before the second paragraph that "Neighbor Discovery > allows a router to load balance traffic towards itself if the router has > multiple MAC addresses by ..." This does not address the point because Neighbor Discovery allows a _host_ to load balance incoming traffic as well ? >> 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. > > I'm not sure removing aids in clarity for folks that come from the IPv4 word. > In ICMP router discovery, part of the reason for the preference field was > to handle routers with different stability, and that reason isn't present here > due to NUD. The fact that we've seen a need to introduce preferences for other > purposes is separate from that explanation. > So perhaps adding a note that preferences can be useful for other purposes > with a non-normative reference to the new spec would make sense. Fine with me. >> 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. > > Or at least clearly state the assumption that > 1) this is only performed as part of a suspected movement > 2) suspected movements are assumed to be uncorrelated between different hosts > i.e. we assume that a trainload of wireless laptops wouldn't all detect > movement and send a RS at the same time > 3) the 2) assumption might not be true in all cases Works for me. >> 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? > > Can't SeND nodes choose to ignore redirects that aren't protected by SeND? Sure. I was just referring this editorially, that "unauthenticated" is often an overloaded term, referring to IPsec AH.. >> 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. > > What's the bug? If there are no on-link prefixes advertised, then the host will > send all packets to a default router. So if an attacker sends RAs with a zero > valid lifetime for all the prefixes and a zero default router lifetime for all > the routers, and advertises itself as a default router, then all packets will > be sent to that spoofed router. So I think the text is correct. That approach is correct, but beacause the "two hour rule" applies to the on-link prefixes, it's not "immediately". -- 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 Jan 13 14:12:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04901 for ; Thu, 13 Jan 2005 14:12:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAd1-0003Vg-Et for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 14:27:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpA9f-0008Ol-SF; Thu, 13 Jan 2005 13: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 1CpA8G-0007hD-8t for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 13:55: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 NAA03650 for ; Thu, 13 Jan 2005 13:55:42 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAMX-00036r-JB for ipv6@ietf.org; Thu, 13 Jan 2005 14:10:30 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0DItddt028375; Thu, 13 Jan 2005 11:55:40 -0700 (MST) Received: from localhost (d-mpk17-89-136.SFBay.Sun.COM [129.146.89.136]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id j0DItb53003945; Thu, 13 Jan 2005 19:55:38 +0100 (MET) Date: Thu, 13 Jan 2005 10:55:36 -0800 (PST) From: Erik Nordmark To: Pekka Savola Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: H.Soliman@flarion.com, 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 Reply-To: Erik Nordmark 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 > On Tue, 14 Dec 2004, Pekka Savola wrote: > 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? The Solaris in.ndpd implements 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? Solaris in.ndpd implements this. > 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. FWIW I think the intent was to say "zero is consistent with a nonp-zero value" but "two different non-zero values are inconsistent". > 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 ? FWIW I don't see this implemented in in.ndpd. If we really want this detailed level of implementation reports, IMHO we need an implementation report form that asks these level of questions so that it can be passed to the different implementors we know of (and advertised to the list.) 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 Jan 13 14:16:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05183 for ; Thu, 13 Jan 2005 14:16:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAgY-0003cB-CB for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 14:31:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpAQk-0005kE-EJ; Thu, 13 Jan 2005 14:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpA9t-0008V4-OM for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 13:57: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 NAA03835 for ; Thu, 13 Jan 2005 13:57:24 -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 1CpAOB-00039M-Be for ipv6@ietf.org; Thu, 13 Jan 2005 14:12:11 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 Jan 2005 13:56:48 -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: Thu, 13 Jan 2005 13:56:46 -0500 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcT5oOWvCFIseEMlQmytnCcgo6wlnQAAEUQQ From: "Soliman, Hesham" To: "Pekka Savola" , "Erik Nordmark" X-OriginalArrivalTime: 13 Jan 2005 18:56:48.0259 (UTC) FILETIME=[A261DD30:01C4F9A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable > >> =3D=3D> 'or the source chooses to ignore unauthenticated Redirect > >> messages' smells quite a bit from a leftover of IPsec=20 > AH times. Reword? > > > > Can't SeND nodes choose to ignore redirects that aren't=20 > protected by SeND? >=20 > Sure. I was just referring this editorially, that "unauthenticated"=20 > is often an overloaded term, referring to IPsec AH.. =3D> FWIW, I don't see any overload here. If you have a synonym for it I'm fine with putting it in, but otherwise I don't see a problem. There are so many misconceptions that it's hard to write something that will be correctly understood by people not very familiar with the Internet. Hesham =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 Jan 13 14:20:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05470 for ; Thu, 13 Jan 2005 14:20:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAkP-0003i6-87 for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 14:35:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpARh-0006CX-JH; Thu, 13 Jan 2005 14:15:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpAJv-0002c4-75 for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 14:07: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 OAA04340 for ; Thu, 13 Jan 2005 14:07:45 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAYB-0003M1-ME for ipv6@ietf.org; Thu, 13 Jan 2005 14:22:33 -0500 Received: from jurassic.eng.sun.com ([129.146.86.38]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0DJ7hdt006468; Thu, 13 Jan 2005 12:07:43 -0700 (MST) Received: from [129.146.89.136] (d-mpk17-89-136.SFBay.Sun.COM [129.146.89.136]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0DJ7hiv618464; Thu, 13 Jan 2005 11:07:43 -0800 (PST) Message-ID: <41E6C6FF.6010405@sun.com> Date: Thu, 13 Jan 2005 11:07:43 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola 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: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, 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: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Pekka Savola wrote: >> It is an odd "SHOULD" in that it doesn't add a requirement on >> implemetors of >> ND, but instead states a requirement on some potential other protocol >> which >> uses proxy NAs. >> But I do think that MIPv6 is an example of this. Even with multiple >> Home Agents >> on the same home link, MIPv6 ensures that only one home agent performs >> proxy ND >> for a given home address. > > > Even more reason to remove it from here, unless it has been implemented > (I haven't seen it for sure -- doing it robustly is pretty difficult). As I said above, I think the MIPv6 RFC is the "implementation" in this case. But it does make sense to clarify that the text is about a requirement on other protocols which use proxy ND. >> Leaving the first paragraph as is, since it is basically explaining >> the term, >> and adding something before the second paragraph that "Neighbor Discovery >> allows a router to load balance traffic towards itself if the router has >> multiple MAC addresses by ..." > > > This does not address the point because Neighbor Discovery allows a > _host_ to load balance incoming traffic as well ? Sorry, I can't understand how your comment relates to mine. We can make the text be more clear that the first paragraph explains/defines the term, and the above addition to the second paragraph. Wouldn't that work? >> Can't SeND nodes choose to ignore redirects that aren't protected by >> SeND? > > > Sure. I was just referring this editorially, that "unauthenticated" is > often an overloaded term, referring to IPsec AH.. But here the fact that it doesn't specify how it is authenticated is a feature; if there is a new ND authentication scheme we want this to apply there as well. And I don't think the anti-spam folks mean IPsec AH when they say "authenticated email" :-) >> What's the bug? If there are no on-link prefixes advertised, then the >> host will >> send all packets to a default router. So if an attacker sends RAs with >> a zero >> valid lifetime for all the prefixes and a zero default router lifetime >> for all >> the routers, and advertises itself as a default router, then all >> packets will >> be sent to that spoofed router. So I think the text is correct. > > > That approach is correct, but beacause the "two hour rule" applies to > the on-link prefixes, it's not "immediately". That apparently a commonly held misunderstanding. The 2 hour rule only applies two stateless address autoconfiguration only. (It is only in RFC 2462, not in 2461.) 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 Jan 13 14:42:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07794 for ; Thu, 13 Jan 2005 14:42:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpB5f-0004Is-NJ for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 14:57:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpAk6-0004UN-Dw; Thu, 13 Jan 2005 14:34:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpAgR-0002nk-Cp for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 14:31: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 OAA06245 for ; Thu, 13 Jan 2005 14:31:01 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAuh-0003wO-6A for ipv6@ietf.org; Thu, 13 Jan 2005 14:45:49 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j0DJVbCR020415; Thu, 13 Jan 2005 13:31:37 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Jan 2005 13:28:56 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CQCDMPMR; Thu, 13 Jan 2005 14:30:24 -0500 Date: Thu, 13 Jan 2005 14:28:27 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Pekka Savola In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: H.Soliman@flarion.com, Erik Nordmark , 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 Reply-To: Suresh Krishnan 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 Hi Pekka, On Thu, 13 Jan 2005, Pekka Savola wrote: ...... >That approach is correct, but beacause the "two hour rule" applies to >the on-link prefixes, it's not "immediately". Not really. This two hour minimum applies only to stateless autoconf. Cheers Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 13 14:54:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08767 for ; Thu, 13 Jan 2005 14:54:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpBGy-0004cn-Ht for ipv6-web-archive@ietf.org; Thu, 13 Jan 2005 15:08:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpB0s-0001rB-Ng; Thu, 13 Jan 2005 14:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpAn2-0005aW-FX for ipv6@megatron.ietf.org; Thu, 13 Jan 2005 14:37: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 OAA07136 for ; Thu, 13 Jan 2005 14:37:50 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpB1I-00048U-7K for ipv6@ietf.org; Thu, 13 Jan 2005 14:52:38 -0500 Received: from jurassic.eng.sun.com ([129.146.88.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0DJbmVu024809; Thu, 13 Jan 2005 12:37:48 -0700 (MST) Received: from [129.146.89.136] (d-mpk17-89-136.SFBay.Sun.COM [129.146.89.136]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0DJbmSK629154; Thu, 13 Jan 2005 11:37:48 -0800 (PST) Message-ID: <41E6CE0C.5030102@sun.com> Date: Thu, 13 Jan 2005 11:37:48 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: liqunhui References: <000c01c4d8d2$ba9bf010$32c1060a@noneigu0dyydpe> In-Reply-To: <000c01c4d8d2$ba9bf010$32c1060a@noneigu0dyydpe> Content-Type: text/plain; charset=ISO-8859-1; 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: 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit [Sorry for the delayed reply] liqunhui wrote: > hi Could anybody tell me why we need a 64bit fixed length interface > id? and do we really need a network that contains so many hosts? The primary motivation as I understand it is to allow stateless address autoconfiguration, not only for IEEE 802 links, but also links that use the new 64-bit EUI-64 link-layer addresses. When the 64 bit IID was decided, there was also some hope that the Universal bit in the IID would be useful as part of some multihoming solution that separates the identifier and locator aspects of an IP address. However, I haven't seen any use of this when trying to come up with ideas in the multi6 WG, and I haven't seen any other proposals in the multi6 WG try to use this bit. So I think in practice, the U bit in the IID is useful to reduce the risk of address conflicts when there are different methods for picking interface IDs (stateless address autoconfiguration, DHCPv6, manually assigned, temporary addresses, CGAs, etc), but doesn't have any useful semantics for the peer. So it might very well be possible to make the existence of the U bit a property of the actual IP-over-foo specification. > If router advertise a prefix which is longer than 64bit,then the > possibility of address duplication is increasing.for example ,it will > overwrite 56 bits of the 64bit interface id when router advertise a > 120bit length prefix.so only 8 bits is left for interface id.how can > we deal with this? The current specification (RFC 2462) says that the length of the advertised prefix plus the length of the interface ID (for the particular IP-over-foo) must equal 128. So there will not be any overwriting of bits. If you want to use 120 bit prefixes then you either have to manually assign the addresses (I think folks do this for links between routers) or use DHCPv6 (but I'm not certain DHCPv6 implementations support this). Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 14 00:58:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00020 for ; Fri, 14 Jan 2005 00:58:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKiG-0002vb-O2 for ipv6-web-archive@ietf.org; Fri, 14 Jan 2005 01:13:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpKOD-0000Bw-4B; Fri, 14 Jan 2005 00:52:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpKJj-0007BE-Hk for ipv6@megatron.ietf.org; Fri, 14 Jan 2005 00:48: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 AAA29163 for ; Fri, 14 Jan 2005 00:48: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 1CpKY6-0002il-Iv for ipv6@ietf.org; Fri, 14 Jan 2005 01:03:07 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:d137:ffd8:6023:b01]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9FA6E15210; Fri, 14 Jan 2005 14:48:08 +0900 (JST) Date: Fri, 14 Jan 2005 14:48:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: H.Soliman@flarion.com, IPv6 WG , Pekka Savola 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: 4adaf050708fb13be3316a9eee889caa >>>>> On Thu, 13 Jan 2005 10:39:15 -0800 (PST), >>>>> Erik Nordmark said: >> - 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.) > FWIW This is implemented in Solaris 8 and later. > I don't know if there is an second independent implementation though. KAME/BSD also implements the former type of lifetimes (although the current implementation cannot specify the expiration time for this type of lifetimes. It can only specify whether the lifetime decrements in real time). BTW: do we really need this level of detailed inspection to meet the two-implementation requirement for a DS? When I raised a similar question when we discussed how we should deal with the M/O flags in rfc2462bis wrt this requirement, I was told that we usually only require a rougher level (e.g. whether there are more than two implementations that support NS/NA/RA/RS/Redirect messages without requiring line-by-line conformance to the corresponding RFC). I personally prefer detailed inspection (if we can do that within a reasonable period), but I can live with the rougher version as a real-world compromise. In any case, we should basically be consistent on the requirement level not to make a double-standard. 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 Jan 14 02:02:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05841 for ; Fri, 14 Jan 2005 02:02:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpLhc-00044Z-7B for ipv6-web-archive@ietf.org; Fri, 14 Jan 2005 02:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpLND-0000zx-Sp; Fri, 14 Jan 2005 01: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 1CpLJZ-00009S-8W for ipv6@megatron.ietf.org; Fri, 14 Jan 2005 01:52: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 BAA03370 for ; Fri, 14 Jan 2005 01:52:08 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpLXw-0003vP-Mx for ipv6@ietf.org; Fri, 14 Jan 2005 02:07:01 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0E6pS519914; Fri, 14 Jan 2005 08:51:28 +0200 Date: Fri, 14 Jan 2005 08:51:28 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-402659011-1105685488=:19825" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: H.Soliman@flarion.com, Erik Nordmark , 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: 4adaf050708fb13be3316a9eee889caa This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-402659011-1105685488=:19825 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id j0E6pS519914 Content-Transfer-Encoding: quoted-printable On Fri, 14 Jan 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: > BTW: do we really need this level of detailed inspection to meet the > two-implementation requirement for a DS? That is a matter of interpretation. Traditionally, the ADs have not=20 required them, but personally I think the spirit of the policy=20 requires them. For what it's worth, why I'm asking these is because IMHO it's very=20 important that the spec mirrors what's implemented (or what we believe=20 definitely must be implemented). It seems to me that at places the=20 gap between implementations and the spec has gotten wider. The big=20 point of DS/FS is to evaluate that gap and do something about it. One way to do that would be remove some of the more rarery implemented=20 statements from the spec or change their requirement level from SHOULD=20 to MAY, MUST to SHOULD, etc. --=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 --1589707168-402659011-1105685488=:19825 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 -------------------------------------------------------------------- --1589707168-402659011-1105685488=:19825-- From ipv6-bounces@ietf.org Fri Jan 14 02:17:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19049 for ; Fri, 14 Jan 2005 02:17:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpLw2-0004OL-J7 for ipv6-web-archive@ietf.org; Fri, 14 Jan 2005 02:31:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpLfl-0001IU-3J; Fri, 14 Jan 2005 02:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpLe3-0000ag-9b for ipv6@megatron.ietf.org; Fri, 14 Jan 2005 02:13: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 CAA17099 for ; Fri, 14 Jan 2005 02:13:18 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpLsO-0004JX-93 for ipv6@ietf.org; Fri, 14 Jan 2005 02:28:11 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0E7CrT13313; Fri, 14 Jan 2005 09:12:53 +0200 (EET) X-Scanned: Fri, 14 Jan 2005 09:09:20 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0E79K3j002781; Fri, 14 Jan 2005 09:09:20 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 005go9Nq; Fri, 14 Jan 2005 09:07:34 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 j0E6bpU11137; Fri, 14 Jan 2005 08:37:51 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 Jan 2005 08:37:51 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 Jan 2005 08:37:50 +0200 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="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Fri, 14 Jan 2005 08:37:54 +0200 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcT5/oc7YKBA6hCOTlWvwHqsLYZ0QAABMLFg To: , X-OriginalArrivalTime: 14 Jan 2005 06:37:50.0822 (UTC) FILETIME=[919FA060:01C4FA03] X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, ipv6@ietf.org, pekkas@netcore.fi 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.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi Jinmei, > BTW: do we really need this level of detailed inspection to meet the > two-implementation requirement for a DS? When I raised a similar > question when we discussed how we should deal with the M/O flags in > rfc2462bis wrt this requirement, I was told that we usually only > require a rougher level (e.g. whether there are more than two > implementations that support NS/NA/RA/RS/Redirect messages without > requiring line-by-line conformance to the corresponding RFC). I > personally prefer detailed inspection (if we can do that within a > reasonable period), but I can live with the rougher version as a > real-world compromise. In any case, we should basically be consistent > on the requirement level not to make a double-standard. I agree with you on this. As someone already has mentioned one implementation, removing the text would be dangerous. If we really wanted to remove it, we should make a thorough search, via some other forums, to check, since there are a lot of implementors not on this mailing list. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 14 14:07:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05305 for ; Fri, 14 Jan 2005 14:07:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpX1c-0001IT-VM for ipv6-web-archive@ietf.org; Fri, 14 Jan 2005 14:22:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWdb-0002pH-AZ; Fri, 14 Jan 2005 13:57:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpWWJ-00017m-1f for ipv6@megatron.ietf.org; Fri, 14 Jan 2005 13:50: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 NAA04265 for ; Fri, 14 Jan 2005 13:49:59 -0500 (EST) Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpWkl-0000w0-Gr for ipv6@ietf.org; Fri, 14 Jan 2005 14:05:01 -0500 Received: from alerion.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id j0EInPc14144; Fri, 14 Jan 2005 10:49:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id B7FAE3F0021; Fri, 14 Jan 2005 10:49:25 -0800 (PST) Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29979-07; Fri, 14 Jan 2005 10:49:24 -0800 (PST) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id EFC3E3F0020; Fri, 14 Jan 2005 10:49:24 -0800 (PST) From: Tim Hartrick To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: <120b982c5e5c91c5e61f678d6b2f5855@message.md5> References: <120b982c5e5c91c5e61f678d6b2f5855@message.md5> Content-Type: text/plain; charset=UTF-8 Organization: Mentat Inc. Message-Id: <1105728636.6381.1.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 14 Jan 2005 10:50:36 -0800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roll.mentat.com id j0EInPc14144 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: H.Soliman@flarion.com, Erik Nordmark , IPv6 WG , Pekka Savola 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 Reply-To: tim@mentat.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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Jinmei, On Thu, 2005-01-13 at 21:48, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: >=20 > BTW: do we really need this level of detailed inspection to meet the > two-implementation requirement for a DS? When I raised a similar > question when we discussed how we should deal with the M/O flags in > rfc2462bis wrt this requirement, I was told that we usually only > require a rougher level (e.g. whether there are more than two > implementations that support NS/NA/RA/RS/Redirect messages without > requiring line-by-line conformance to the corresponding RFC). I > personally prefer detailed inspection (if we can do that within a > reasonable period), but I can live with the rougher version as a > real-world compromise. In any case, we should basically be consistent > on the requirement level not to make a double-standard. >=20 In my opinion we do not need this level of detail. I think that the current discussion of removal of unimplemented or not widely implemented implementation options is overkill. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 14 15:17:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11829 for ; Fri, 14 Jan 2005 15:17:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpY7e-0002zD-Jz for ipv6-web-archive@ietf.org; Fri, 14 Jan 2005 15:32:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpXpG-0005ak-Hn; Fri, 14 Jan 2005 15:13:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpXi5-0007DZ-58; Fri, 14 Jan 2005 15:06: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 PAA10532; Fri, 14 Jan 2005 15:06:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpXwa-0002n2-9E; Fri, 14 Jan 2005 15:21:16 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CpXag-0001zI-T3; Fri, 14 Jan 2005 14:58:38 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 14 Jan 2005 14:58:38 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Last Call: 'IPv6 Stateless Address Autoconfiguration' 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: 798b2e660f1819ae38035ac1d8d5e3ab The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'IPv6 Stateless Address Autoconfiguration' 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-01-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-07.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 Fri Jan 14 19:28:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10826 for ; Fri, 14 Jan 2005 19:28:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cpc2Q-00030Q-3G for ipv6-web-archive@ietf.org; Fri, 14 Jan 2005 19:43:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpbZQ-0004P2-If; Fri, 14 Jan 2005 19:13:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpbW0-00038S-1E for ipv6@megatron.ietf.org; Fri, 14 Jan 2005 19:10: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 TAA09620 for ; Fri, 14 Jan 2005 19:10:01 -0500 (EST) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpbkV-0002ba-9t for ipv6@ietf.org; Fri, 14 Jan 2005 19:25:05 -0500 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 49CD4B87F; Fri, 14 Jan 2005 16:09:57 -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 46812-01-8; Fri, 14 Jan 2005 16:09:54 -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 30375B847; Fri, 14 Jan 2005 16:09:54 -0800 (PST) Received: from [172.17.55.5] (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 j0F0Io4J019330 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Jan 2005 16:18:52 -0800 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: From: Brian Haberman Date: Fri, 14 Jan 2005 19:09:46 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Bob Hinden Subject: Proposed update to ULA Draft (-09) 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="===============1225701418==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 --===============1225701418== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-739051391; protocol="application/pkcs7-signature" --Apple-Mail-2-739051391 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit IPv6 WG, In order to resolve the last IESG discuss comment on the ULA draft two sets of changes are proposed. Sam Hartman, who holds the Discuss, has reviewed these changes and said these proposed changes resolve the Discuss. The changes are: o Removed all mention of centrally assigned IPv6 local address addresses based on IESG comments. L=0 is left to be defined in the future. o Added new section titled "Global Routing Considerations" that discusses the issues relating to why using these addresses for general purpose unicast address on the global internet is not a good idea. An updated draft with the proposed changes can be found at: http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr -09.txt along with an diffed version (-09 vs. -08) at: http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr -09.html (Note the htmldiff that was used to produce the html diff file got a little confused in places, but it is still useful to see the changes). The new section 5.0 is also attached inline below. We wanted the working group to review the proposed changes before a new version was submitted. Thanks, Bob Hinden / Brian Haberman IPv6 working group chairs ---------------------------- 5.0 Global Routing Considerations Section 4.1 provides operational guidelines that forbid default routing of local addresses between sites. Concerns were raised to the IPv6 working group and to the IETF as a whole that sites may attempt to use local addresses as globally routed provider- independent addresses. This section describes why using local addresses as globally-routed provider-independent addresses is unadvisable. 5.1 From the Standpoint of the Internet There is a mismatch between the structure of IPv6 local addresses and the normal IPv6 wide area routing model. The /48 prefix of an IPv6 local addresses fits nowhere in the normal hierarchy of IPv6 unicast addresses. Normal IPv6 unicast addresses can be routed hierarchically down to physical subnet (link) level and only have to be flat-routed on the physical subnet. IPv6 local addresses would have to be flat-routed even over the wide area Internet. Thus, packets whose destination address is an IPv6 local address could be routed over the wide area only if the corresponding /48 prefix were carried by the wide area routing protocol in use, such as BGP. This contravenes the operational assumption that long prefixes will be aggregated into many fewer short prefixes, to limit the table size and convergence time of the routing protocol. If a network uses both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these types of address will certainly not aggregate with each other, since they differ from the most significant bit onwards. Neither will IPv6 local addresses aggregate with each other, due to their random bit patterns. This means that there would be a very significant operational penalty for attempting to use IPv6 local address prefixes generically with currently known wide area routing technology. 5.2 From the Standpoint of a Site There are a number of design factors in IPv6 local addresses that reduce the likelihood that IPv6 local addresses will be used as arbitrary global unicast addresses. These include: - The default rules to filter packets and routes make it very difficult to use IPv6 local addresses for arbitrary use across the Internet. For a site to use them as general purpose unicast addresses, they would have to make sure that the default rules were not being used by all other sites and intermediate ISPs used for their current and future communication. - They are not mathematically guaranteed to be unique and are not registered in public databases. Collisions, while highly unlikely, are possible and a collision can compromise the integrity of the communications. The lack of public registration creates operational problems. - The addresses are allocated randomly. If a site had multiple prefixes that they wanted to be used globally the cost of advertising them would be very high as they could not be aggregated. - They have a long prefix (i.e, /48) so a single local address prefix doesn't provide enough address space to be used exclusively by the largest organizations. --------------------- --Apple-Mail-2-739051391 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTE1MDAwOTQ2WjAjBgkqhkiG9w0B CQQxFgQU/CSTMQ23H83YsWvocDwwNbFY+oIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAJdcozJKtpuifI5qyRAqpOg2ZTe4Dlzsk3Hwe1Tlyh9W44oYOsBEV+hCeXmbbyO23ODLb 8Xh6LoIWjYv1lhgX1/HkcDMZUeu2w4RVU/8641y9O9RGgmEPNYQyi4oja3wz8H8cfn7XFMc0bE85 lv0d3Z+DJh+7BBug/kp4UWzJYNfwUvW5IjAgtTci0CWqGlvR7wag1zhvmYHYjPacaonRSJSOsgIk Z4aUs5PhiXwJn/LRPgXKlgpMhUfnDYTH9muWIvnlO5Kw/0flx2oICVvEaf+6nyxmoKrqw3nFeknW tFbix/AW8iTFRIVJZS/OVPqB3U5ElgYAHTRFszNf3g3plAAAAAAAAA== --Apple-Mail-2-739051391-- --===============1225701418== 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 -------------------------------------------------------------------- --===============1225701418==-- From ipv6-bounces@ietf.org Sun Jan 16 00:13:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20500 for ; Sun, 16 Jan 2005 00:13:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cq2y4-0000so-Hn for ipv6-web-archive@ietf.org; Sun, 16 Jan 2005 00:28:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cq2YF-000489-Jr; Sun, 16 Jan 2005 00:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cq2XF-0003mH-4C for ipv6@megatron.ietf.org; Sun, 16 Jan 2005 00:01: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 AAA19763 for ; Sun, 16 Jan 2005 00:01:06 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cq2m1-0000fT-7b for ipv6@ietf.org; Sun, 16 Jan 2005 00:16:25 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 23E2562F for ; Sun, 16 Jan 2005 00:00:37 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 16 Jan 2005 00:00:36 -0500 Message-Id: <20050116050037.23E2562F@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.73% | 5 | 21.97% | 25589 | pekkas@netcore.fi 18.18% | 4 | 22.78% | 26530 | erik.nordmark@sun.com 13.64% | 3 | 9.99% | 11640 | suresh.krishnan@ericsson.ca 9.09% | 2 | 9.09% | 10586 | elwynd@dial.pipex.com 9.09% | 2 | 8.31% | 9676 | john.loughney@nokia.com 4.55% | 1 | 10.51% | 12238 | brian@innovationslab.net 4.55% | 1 | 4.13% | 4809 | jinmei@isl.rdc.toshiba.co.jp 4.55% | 1 | 3.99% | 4643 | tim@mentat.com 4.55% | 1 | 3.69% | 4304 | h.soliman@flarion.com 4.55% | 1 | 2.88% | 3356 | sra+ipng@hactrn.net 4.55% | 1 | 2.67% | 3113 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 22 |100.00% | 116484 | 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 Jan 17 05:03:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21745 for ; Mon, 17 Jan 2005 05:03:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqTyZ-0000Ba-VG for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 05:19:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTcX-0000m4-VH; Mon, 17 Jan 2005 04:56:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTWX-0008I9-Dq for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 04:50: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 EAA20728 for ; Mon, 17 Jan 2005 04:50:10 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqTlX-0008Hd-TJ for ipv6@ietf.org; Mon, 17 Jan 2005 05:05:45 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0H9nZbP202178 for ; Mon, 17 Jan 2005 09:49:35 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0H9oW1e141012 for ; Mon, 17 Jan 2005 10:50:32 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0H9nZFo015557 for ; Mon, 17 Jan 2005 10:49:35 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0H9nYA6015522; Mon, 17 Jan 2005 10:49:35 +0100 Received: from zurich.ibm.com (sig-9-145-250-216.de.ibm.com [9.145.250.216]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA53612; Mon, 17 Jan 2005 10:49:33 +0100 Message-ID: <41EB8A2D.5080606@zurich.ibm.com> Date: Mon, 17 Jan 2005 10:49: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: Brian Haberman References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: Bob Hinden , IPv6 WG Subject: Re: Proposed update to ULA Draft (-09) 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: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit I support this version. Although I don't fully agree with the concerns expressed by some IESG members, I think this new version is quite OK, and the quickest way make ULAs available to networks that need them. Brian Brian Haberman wrote: > IPv6 WG, > > In order to resolve the last IESG discuss comment on the ULA draft two > sets of changes are proposed. Sam Hartman, who holds the Discuss, has > reviewed these changes and said these proposed changes resolve the > Discuss. The changes are: > > o Removed all mention of centrally assigned IPv6 local address > addresses based on IESG comments. L=0 is left to be defined in > the future. > > o Added new section titled "Global Routing Considerations" that > discusses the issues relating to why using these addresses for > general purpose unicast address on the global internet is not a > good idea. > > An updated draft with the proposed changes can be found at: > > http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr > -09.txt > > along with an diffed version (-09 vs. -08) at: > > http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr > -09.html > > (Note the htmldiff that was used to produce the html diff file got a > little confused in places, but it is still useful to see the changes). > > The new section 5.0 is also attached inline below. > > We wanted the working group to review the proposed changes before a new > version was submitted. > > Thanks, > Bob Hinden / Brian Haberman > IPv6 working group chairs > > ---------------------------- > > > 5.0 Global Routing Considerations > > Section 4.1 provides operational guidelines that forbid default > routing of local addresses between sites. Concerns were raised to > the IPv6 working group and to the IETF as a whole that sites may > attempt to use local addresses as globally routed provider- > independent addresses. This section describes why using local > addresses as globally-routed provider-independent addresses is > unadvisable. > > 5.1 From the Standpoint of the Internet > > There is a mismatch between the structure of IPv6 local addresses and > the normal IPv6 wide area routing model. The /48 prefix of an IPv6 > local addresses fits nowhere in the normal hierarchy of IPv6 unicast > addresses. Normal IPv6 unicast addresses can be routed > hierarchically down to physical subnet (link) level and only have to > be flat-routed on the physical subnet. IPv6 local addresses would > have to be flat-routed even over the wide area Internet. > > Thus, packets whose destination address is an IPv6 local address > could be routed over the wide area only if the corresponding /48 > prefix were carried by the wide area routing protocol in use, such as > BGP. This contravenes the operational assumption that long prefixes > will be aggregated into many fewer short prefixes, to limit the table > size and convergence time of the routing protocol. If a network uses > both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these > types of address will certainly not aggregate with each other, since > they differ from the most significant bit onwards. Neither will IPv6 > local addresses aggregate with each other, due to their random bit > patterns. This means that there would be a very significant > operational penalty for attempting to use IPv6 local address prefixes > generically with currently known wide area routing technology. > > 5.2 From the Standpoint of a Site > > There are a number of design factors in IPv6 local addresses that > reduce the likelihood that IPv6 local addresses will be used as > arbitrary global unicast addresses. These include: > > - The default rules to filter packets and routes make it very > difficult to use IPv6 local addresses for arbitrary use across > the Internet. For a site to use them as general purpose unicast > addresses, they would have to make sure that the default rules > were not being used by all other sites and intermediate ISPs > used for their current and future communication. > > - They are not mathematically guaranteed to be unique and are not > registered in public databases. Collisions, while highly > unlikely, are possible and a collision can compromise the > integrity of the communications. The lack of public > registration creates operational problems. > > - The addresses are allocated randomly. If a site had multiple > prefixes that they wanted to be used globally the cost of > advertising them would be very high as they could not be > aggregated. > > - They have a long prefix (i.e, /48) so a single local address > prefix doesn't provide enough address space to be used > exclusively by the largest organizations. > > --------------------- > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > 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 Jan 17 07:43:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00203 for ; Mon, 17 Jan 2005 07:43:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWTK-00032Y-J0 for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 07:59:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWC6-00085g-Pf; Mon, 17 Jan 2005 07:41:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWBV-000817-Jw for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 07:40: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 HAA00062 for ; Mon, 17 Jan 2005 07:40:40 -0500 (EST) Received: from 211.cust6.sa.dsl.ozemail.com.au ([210.84.229.211] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWQY-0002zt-1l for ipv6@ietf.org; Mon, 17 Jan 2005 07:56:15 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 37CB162AAE; Mon, 17 Jan 2005 23:10:35 +1030 (CST) Date: Mon, 17 Jan 2005 23:10:34 +1030 From: Mark Smith To: brian@innovationslab.net, bob.hinden@nokia.com Message-Id: <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <41EB8A2D.5080606@zurich.ibm.com> References: <41EB8A2D.5080606@zurich.ibm.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Proposed update to ULA Draft (-09) 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 Hi Bob, Brian, I'm a bit concerned about this suggestion, in section 4.1, Routing : (as a side note, this is from Rev 8, the nokia web site resolves to an IPv6 address, I don't seem to be able to get to it via my 6to4 connection though) For link-state IGPs, it is suggested that a site utilizing ULA prefixes be contained either within one IGP domain or area. By containing a ULA prefix to a single link-state area or domain, the distribution of prefixes can be controlled. I think it potentially could cause conflicts with the idea of using the same subnet numbers as those used with a global prefix. Most entities (organisations, individuals etc) who might use Local Ipv6 addresses may also be assigned a single global /48, as per the RFC3177 recommendation. If an organisation follows the above suggestion, they may end up with a number of ULA /48s, in particular if they generate a new ULA per IGP area. Naively, they may, within the each area or IGP domain, assign subnet numbers starting at 0x0001. In other words, within an area or IGP domain, use a local 2^16 subnet address space. This is probably reasonable and even preferred, as the length of time the organisation "owns" its ULA address spaces is (likely to be) much longer than the time they hold a global prefix. Focusing on the available ULA address space while planning the subnet structure makes sense. The problem would occur when they try to assign these same subnet numbers to a single, global /48 they've been assigned. Of course, they couldn't, as they'd now be trying to assign multiple "subnet 0x0001"s within the single, global /48. They'd be forced to use different subnet numbers for their global and ULA prefixes. If they were less naive, they might assign ranges of non-overlapping subnet numbers to the different areas or IGP domains within the ULA /48s, then allowing them to have unique subnets within the single, global /48 they've been assigned. In other words, the subnet space they assign subnets out of is a single range of 2^16 across their network. This introduces complexity though, as they'll now have to configure prefix summarisation on the area or IGP domain at different points within the ULA and global address spaces. E.g., for the ULA assignments, they can summarise at the /48 point, where as for the single global /48 assignment, they might summarise at, for example, the /56 point. It gets a bit more complicated if they need to use variable length subnets within their global IPv6 prefix. I don't think this is overly complex, however I think it defeats the simplicity goals of either a ULA prefix per IGP domain or area, or using common subnet numbers for ULA and global prefixes. I'm not sure what my opinion is regarding which addressing model would be best, and maybe there isn't one "best" one. I suppose both of them could be suggested, with the caveats of each of them described. Possibly, it may be outside of the scope of this RFC. More discussion might help. Thanks, Mark. -- "This signature intentionally left blank." -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 17 08:23:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03306 for ; Mon, 17 Jan 2005 08:23:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqX5m-00044Z-Jd for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 08:38:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWlL-0002vN-30; Mon, 17 Jan 2005 08:17:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWdl-0002CA-JE for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 08:09: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 IAA02345 for ; Mon, 17 Jan 2005 08:09:51 -0500 (EST) Received: from 178.cust6.sa.dsl.ozemail.com.au ([210.84.229.178] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWsn-0003or-L2 for ipv6@ietf.org; Mon, 17 Jan 2005 08:25:27 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 8F5B962AAE; Mon, 17 Jan 2005 23:39:48 +1030 (CST) Date: Mon, 17 Jan 2005 23:39:48 +1030 From: Mark Smith To: brian@innovationslab.net, bob.hinden@nokia.com Message-Id: <20050117233948.097cfbc1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <41EB8A2D.5080606@zurich.ibm.com> <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Proposed update to ULA Draft (-09) 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 On Mon, 17 Jan 2005 23:10:34 +1030 Mark Smith wrote: > > I'm not sure what my opinion is regarding which addressing model would > be best, and maybe there isn't one "best" one. I suppose both of them > could be suggested, with the caveats of each of them described. > Possibly, it may be outside of the scope of this RFC. More discussion > might help. > Or, to get this ID moving, remove both suggestions, and leave this issue to be addressed somewhere else. Regards, Mark. -- "This signature intentionally left blank." -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 17 14:28:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05874 for ; Mon, 17 Jan 2005 14:28:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqcnM-0004g2-JF for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 14:44:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcTl-0003YM-Nd; Mon, 17 Jan 2005 14:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcQu-0003If-Ht for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 14:21: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 OAA05451 for ; Mon, 17 Jan 2005 14:20:58 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqcg0-0004X7-6k for ipv6@ietf.org; Mon, 17 Jan 2005 14:36:37 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HJKo429616; Mon, 17 Jan 2005 21:20:51 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 21:20:41 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0HJKfvD010909; Mon, 17 Jan 2005 21:20:41 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Sy1TmF; Mon, 17 Jan 2005 21:20:30 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 j0HJJxU00005; Mon, 17 Jan 2005 21:20:00 +0200 (EET) Received: from l5131412.nokia.com ([10.241.50.43]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 21:19:55 +0200 Message-Id: <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 17 Jan 2005 11:19:55 -0800 To: Mark Smith From: Bob Hinden In-Reply-To: <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d313 40a.nosense.org> References: <41EB8A2D.5080606@zurich.ibm.com> <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Jan 2005 19:19:56.0026 (UTC) FILETIME=[87354DA0:01C4FCC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org, brian@innovationslab.net, bob.hinden@nokia.com Subject: Re: Proposed update to ULA Draft (-09) 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: 4d87d2aa806f79fed918a62e834505ca Mark, Combining your two emails. At 04:40 AM 01/17/2005, Mark Smith wrote: >(as a side note, this is from Rev 8, the nokia web site resolves to an >IPv6 address, I don't seem to be able to get to it via my 6to4 >connection though) > > For link-state IGPs, it is suggested that a site utilizing ULA > prefixes be contained either within one IGP domain or area. By > containing a ULA prefix to a single link-state area or domain, the > distribution of prefixes can be controlled. > >I think it potentially could cause conflicts with the idea of using the >same subnet numbers as those used with a global prefix. The language "it is suggested" was chosen to allow flexibility. As you point out in large multi domain/area deployments there are reasons to do it differently. At 05:09 AM 01/17/2005, Mark Smith wrote: >On Mon, 17 Jan 2005 23:10:34 +1030 >Mark Smith wrote: > > > > > I'm not sure what my opinion is regarding which addressing model would > > be best, and maybe there isn't one "best" one. I suppose both of them > > could be suggested, with the caveats of each of them described. > > Possibly, it may be outside of the scope of this RFC. More discussion > > might help. > > > >Or, to get this ID moving, remove both suggestions, and leave this >issue to be addressed somewhere else. In my personal view, this would be the best course for now. Later on it would be good to get feedback on how people deploy ULAs in operational networks. For example, this might be a good activity for v6ops. Actually, I would be surprised if there wasn't a lot of interest in tracking deployment and operational experience. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 17 14:40:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06643 for ; Mon, 17 Jan 2005 14:40:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqczA-0004w2-5M for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 14:56:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcgA-0004iZ-Vk; Mon, 17 Jan 2005 14:36:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcbZ-0004Pb-Eo for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 14:32: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 OAA06124; Mon, 17 Jan 2005 14:31:59 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqcqf-0004lN-AA; Mon, 17 Jan 2005 14:47:38 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HJS5408335; Mon, 17 Jan 2005 21:28:06 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 21:27:28 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0HJRSE4011859; Mon, 17 Jan 2005 21:27:28 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00gze1d0; Mon, 17 Jan 2005 21:27:26 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 j0HJQMU07199; Mon, 17 Jan 2005 21:26:23 +0200 (EET) Received: from l5131412.nokia.com ([10.241.50.43]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 21:26:14 +0200 Message-Id: <6.1.2.0.2.20050117112329.032eaea0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 17 Jan 2005 11:26:13 -0800 To: IESG Secretary , Margaret Wasserman , Thomas Narten From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Jan 2005 19:26:15.0133 (UTC) FILETIME=[692C70D0:01C4FCCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IPv6 Mailing List Subject: Request to Advance:draft-ietf-ipngwg-icmp-v3-06.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 Margaret & Thomas, On behalf of the IPv6 WG, the chairs request the advancement of: 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 a Informational RFC. This document represents the consensus of the IPv6 working group. The Last Call completed on December 28, 2004. Regards, Bob Hinden & Brian Haberman IPv6 WG chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 17 15:02:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08583 for ; Mon, 17 Jan 2005 15:02:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqdJj-0005bg-HY for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 15:17:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqd1s-00007Z-NU; Mon, 17 Jan 2005 14:59:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqd0e-0008Az-8y for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 14:57: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 OAA08067 for ; Mon, 17 Jan 2005 14:57:53 -0500 (EST) Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqdFj-0005Sk-Re for ipv6@ietf.org; Mon, 17 Jan 2005 15:13:33 -0500 Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id j0HJvev07774; Mon, 17 Jan 2005 13:57:40 -0600 Message-ID: <014d01c4fcce$e155b6d0$6c0016ac@ssprunk> From: "Stephen Sprunk" To: "Mark Smith" , "Bob Hinden" References: <41EB8A2D.5080606@zurich.ibm.com><20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> Date: Mon, 17 Jan 2005 13:57:04 -0600 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: bob.hinden@nokia.com, brian@innovationslab.net, ipv6@ietf.org Subject: Re: Proposed update to ULA Draft (-09) 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 Content-Transfer-Encoding: 7bit Thus spake "Bob Hinden" > At 04:40 AM 01/17/2005, Mark Smith wrote: > >(as a side note, this is from Rev 8, the nokia web site resolves to an > >IPv6 address, I don't seem to be able to get to it via my 6to4 > >connection though) > > > > For link-state IGPs, it is suggested that a site utilizing ULA > > prefixes be contained either within one IGP domain or area. By > > containing a ULA prefix to a single link-state area or domain, the > > distribution of prefixes can be controlled. > > > >I think it potentially could cause conflicts with the idea of using the > >same subnet numbers as those used with a global prefix. > > The language "it is suggested" was chosen to allow flexibility. As you > point out in large multi domain/area deployments there are reasons to do it > differently. I think removing "area" and just leaving "domain" makes more sense; I can't see anyone actually deploying different ULA prefixes per area. The only possible justification would be different ULAs per business unit (to prepare for sell-offs) but business unit lines are rarely reflected in topology, in my experience. Also, why does this suggestion only apply to link-state IGPs? What are our recommendations for people using RIPv6, EIGRPv6, etc? Or with internal BGP peering between multiple IGPs? S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 17 16:01:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14220 for ; Mon, 17 Jan 2005 16:01:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqeFE-00075x-UZ for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 16:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqdsT-0003yU-R9; Mon, 17 Jan 2005 15:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqdoy-0002Qt-By for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 15:49: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 PAA13488 for ; Mon, 17 Jan 2005 15:49:53 -0500 (EST) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqe45-0006qZ-4n for ipv6@ietf.org; Mon, 17 Jan 2005 16:05:34 -0500 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 4782CB896; Mon, 17 Jan 2005 12:49:43 -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 71444-01-18; Mon, 17 Jan 2005 12:49:40 -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 1DDA7B859; Mon, 17 Jan 2005 12:49:40 -0800 (PST) Received: from [172.17.55.5] (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 j0HKwn4J010678 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 17 Jan 2005 12:58:51 -0800 In-Reply-To: <014d01c4fcce$e155b6d0$6c0016ac@ssprunk> References: <41EB8A2D.5080606@zurich.ibm.com><20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> <014d01c4fcce$e155b6d0$6c0016ac@ssprunk> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <3CD50986-68C9-11D9-A731-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Mon, 17 Jan 2005 15:49:10 -0500 To: "Stephen Sprunk" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: Proposed update to ULA Draft (-09) 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="===============1095240585==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb --===============1095240585== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11-986215072; protocol="application/pkcs7-signature" --Apple-Mail-11-986215072 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 17, 2005, at 14:57, Stephen Sprunk wrote: > Thus spake "Bob Hinden" >> At 04:40 AM 01/17/2005, Mark Smith wrote: >>> (as a side note, this is from Rev 8, the nokia web site resolves to >>> an >>> IPv6 address, I don't seem to be able to get to it via my 6to4 >>> connection though) >>> >>> For link-state IGPs, it is suggested that a site utilizing ULA >>> prefixes be contained either within one IGP domain or area. By >>> containing a ULA prefix to a single link-state area or domain, the >>> distribution of prefixes can be controlled. >>> >>> I think it potentially could cause conflicts with the idea of using >>> the >>> same subnet numbers as those used with a global prefix. >> >> The language "it is suggested" was chosen to allow flexibility. As >> you >> point out in large multi domain/area deployments there are reasons to >> do > it >> differently. > > I think removing "area" and just leaving "domain" makes more sense; I > can't > see anyone actually deploying different ULA prefixes per area. The > only > possible justification would be different ULAs per business unit (to > prepare > for sell-offs) but business unit lines are rarely reflected in > topology, in > my experience. This change was made to address a DISCUSS comment specifically talking about link-state routing protocols and area boundaries. The text of the comment is available at https://datatracker.ietf.org/public/pidtracker.cgi? command=view_comment&id=26775. > > Also, why does this suggestion only apply to link-state IGPs? What > are our > recommendations for people using RIPv6, EIGRPv6, etc? Or with > internal BGP > peering between multiple IGPs? > Distance-vector protocols are not generally broken up into admin areas like OSPF & IS-IS. I used to run a modified ripv6 daemon that routed the original site-locals without issues (wrt internal routing). So, I don't see much need in giving a bunch of guidance there. As to internal BGP, my question is "How many scenarios do we want to carry around in this document? Regards, Brian --Apple-Mail-11-986215072 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTE3MjA0OTEwWjAjBgkqhkiG9w0B CQQxFgQUX1j7T4JrfWnlv1an20+ZOBRQgLAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAb8nyNpK8DG0Nk1scVEf8Vvx4NufEoea9WDIarpGkGfDb+ORCV7hj658waCxUzWsAfbzF uBP0/nLB0s6yS3Os4fUyaj3SpCcdqP6aeajsMZQORa2mz15KBAyBmWdXo7WiyuXTe7QJHD78wOa+ Z4nbnoMM5uFqNvMFUmHcM65B2D7+DuQ8VdBnYenLHfcTrvjydALzZU3Ko7zLIQWcDk9QjSicU8Xr WHaBwvDQrjK7Hr6+vp/exUMWQuRVkVeqtmLNwfCs9+O5N1Xm8VGIrqaKYwp4Jio4N0b9W9gpsaxs A+EIfPdZfK/YnY/yMq5Dju+h+2lgZ2pnId5BtQkGHaEg9QAAAAAAAA== --Apple-Mail-11-986215072-- --===============1095240585== 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 -------------------------------------------------------------------- --===============1095240585==-- From ipv6-bounces@ietf.org Mon Jan 17 17:45:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01670 for ; Mon, 17 Jan 2005 17:45:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqfrk-0004XC-D7 for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 18:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqfXg-0004Jp-1Q; Mon, 17 Jan 2005 17:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqfVb-00044B-3Q for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 17:38: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 RAA01271; Mon, 17 Jan 2005 17:38:00 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqfkj-0004PO-P2; Mon, 17 Jan 2005 17:53:42 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HMbmc17526; Tue, 18 Jan 2005 00:37:51 +0200 (EET) X-Scanned: Tue, 18 Jan 2005 00:37:23 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0HMbNxp020410; Tue, 18 Jan 2005 00:37:23 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00CZ6cWY; Tue, 18 Jan 2005 00:37:22 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HMabU27786; Tue, 18 Jan 2005 00:36:37 +0200 (EET) Received: from l5131412.nokia.com ([10.241.50.43]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 Jan 2005 00:36:21 +0200 Message-Id: <6.1.2.0.2.20050117143447.03183760@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 17 Jan 2005 14:36:19 -0800 To: IESG Secretary , Margaret Wasserman , Thomas Narten From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Jan 2005 22:36:21.0906 (UTC) FILETIME=[F823DF20:01C4FCE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IPv6 Mailing List Subject: Request to Advance: [RESEND] 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: b19722fc8d3865b147c75ae2495625f2 [Corrected error in subject line] Margaret & Thomas, On behalf of the IPv6 WG, the chairs request the advancement of: 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 a Informational RFC. This document represents the consensus of the IPv6 working group. The Last Call completed on December 28, 2004. Regards, Bob Hinden & Brian Haberman IPv6 WG chairs -------------------------------------------------------------------- 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 Jan 17 21:41:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17963 for ; Mon, 17 Jan 2005 21:41:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqjYb-0001F8-11 for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 21:57:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqjEi-0002Ss-Uo; Mon, 17 Jan 2005 21:36:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqjCy-0002IO-VS for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 21:35: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 VAA17594 for ; Mon, 17 Jan 2005 21:35:02 -0500 (EST) Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqjS9-00016F-HG for ipv6@ietf.org; Mon, 17 Jan 2005 21:50:46 -0500 Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id j0I2Ylv13469; Mon, 17 Jan 2005 20:34:47 -0600 Message-ID: <04dd01c4fd06$5b4a3ec0$6c0016ac@ssprunk> From: "Stephen Sprunk" To: "Brian Haberman" References: <41EB8A2D.5080606@zurich.ibm.com><20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> <014d01c4fcce$e155b6d0$6c0016ac@ssprunk> <3CD50986-68C9-11D9-A731-000D93330CAA@innovationslab.net> Date: Mon, 17 Jan 2005 18:33:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Bob Hinden Subject: Re: Proposed update to ULA Draft (-09) 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: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Brian Haberman" To: "Stephen Sprunk" Cc: "Bob Hinden" ; "Mark Smith" ; Sent: Monday, January 17, 2005 14:49 Subject: Re: Proposed update to ULA Draft (-09) > > On Jan 17, 2005, at 14:57, Stephen Sprunk wrote: > > > Thus spake "Bob Hinden" > >> At 04:40 AM 01/17/2005, Mark Smith wrote: > >>> (as a side note, this is from Rev 8, the nokia web site resolves to > >>> an > >>> IPv6 address, I don't seem to be able to get to it via my 6to4 > >>> connection though) > >>> > >>> For link-state IGPs, it is suggested that a site utilizing ULA > >>> prefixes be contained either within one IGP domain or area. By > >>> containing a ULA prefix to a single link-state area or domain, the > >>> distribution of prefixes can be controlled. > >>> > >>> I think it potentially could cause conflicts with the idea of using > >>> the > >>> same subnet numbers as those used with a global prefix. > >> > >> The language "it is suggested" was chosen to allow flexibility. As > >> you point out in large multi domain/area deployments there are > >> reasons to do it differently. > > > > I think removing "area" and just leaving "domain" makes more > > sense; I can't see anyone actually deploying different ULA prefixes > > per area. The only possible justification would be different ULAs > > per business unit (to prepare for sell-offs) but business unit lines > > are rarely reflected in topology, in my experience. > > This change was made to address a DISCUSS comment specifically > talking about link-state routing protocols and area boundaries. The > text of the comment is available at > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_comment&id=26775. I can't find a way to agree with Alex's comments. A "site" certainly can't be (productively) smaller than a link-state area due to flooding, but it can certainly be bigger than an area and even span domains if they're under the same administrative control. Part of the problem is "site" has been overloaded to mean "administrative domain", whereas the common meaning is a single physical location. Neither makes sense to me in the 09 text, though. > > Also, why does this suggestion only apply to link-state IGPs? > > What are our recommendations for people using RIPv6, EIGRPv6, > > etc? Or with internal BGP peering between multiple IGPs? > > Distance-vector protocols are not generally broken up into admin areas > like OSPF & IS-IS. EIGRP is often broken up into "areas" of a sort due to summarization, and the consequent limitation of routing updates appears similar to link-state protocols. With EIGRP v1.1, each physical site may end up being a "stub" area; should every location then get its own ULA prefix, even if it only has one router? > I used to run a modified ripv6 daemon that routed the original > site-locals without issues (wrt internal routing). So, I don't see > much need in giving a bunch of guidance there. > > As to internal BGP, my question is "How many scenarios do we > want to carry around in this document? I question whether we should carry any. The only strong requirement is that a "site" be contained within a single AS, regardless of how many routing protocols or areas it contains. Network engineering dictates how many prefixes will be required in a given site's configuration. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 17 23:42:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26161 for ; Mon, 17 Jan 2005 23:42:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqlRO-0003pj-FY for ipv6-web-archive@ietf.org; Mon, 17 Jan 2005 23:58:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqlAm-0003Mx-Jg; Mon, 17 Jan 2005 23:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cql9l-00034n-FX for ipv6@megatron.ietf.org; Mon, 17 Jan 2005 23:39: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 XAA25991 for ; Mon, 17 Jan 2005 23:39:50 -0500 (EST) Received: from 178.cust6.sa.dsl.ozemail.com.au ([210.84.229.178] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqlOv-0003nK-Rb for ipv6@ietf.org; Mon, 17 Jan 2005 23:55:35 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 9B0D362AAE; Tue, 18 Jan 2005 15:09:47 +1030 (CST) Date: Tue, 18 Jan 2005 15:09:47 +1030 From: Mark Smith To: "Stephen Sprunk" Message-Id: <20050118150947.05fd9151.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <04dd01c4fd06$5b4a3ec0$6c0016ac@ssprunk> References: <41EB8A2D.5080606@zurich.ibm.com> <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> <014d01c4fcce$e155b6d0$6c0016ac@ssprunk> <3CD50986-68C9-11D9-A731-000D93330CAA@innovationslab.net> <04dd01c4fd06$5b4a3ec0$6c0016ac@ssprunk> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, brian@innovationslab.net, bob.hinden@nokia.com Subject: Re: Proposed update to ULA Draft (-09) 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 Mon, 17 Jan 2005 18:33:08 -0600 "Stephen Sprunk" wrote: > > Part of the problem is "site" has been overloaded to mean "administrative > domain", whereas the common meaning is a single physical location. Neither > makes sense to me in the 09 text, though. > Maybe it would be better to be even more generic and abstract about the scope of these addresses, and have some text similar to the following. This would eliminate specific reference to certain technologies and the different scenarios and execeptions that can be created with them : "Addresses and prefixes allocated from within one or more /48 ULA address spaces are only to be visible within the administrative domain of the network in question. Traffic with ULA sources and / or destinations and route advertisements containing ULA prefixes should (SHOULD(?)), by default, be prevented from leaving or entering the administrative domain." The edge of the administrative domain may coincide with the edge of a BGP AS, an IGP domain, or the boundary between a service provider and customer, in the case where static routing is being used." And then the text referring /48 or longer exceptions such as the VPN case, merging of organisations etc. As much as it would be good to stay generic, identifying BGP as a special case with a default block on the ULA /7 prefix would probably be best as non-intentional leaking of ULA address spaces could have global consequences. Other than that though, I think it would be better not to identify or suggesting boundaries to constrain ULA prefixes to, such as IGP areas. Regards, Mark. -- "This signature intentionally left blank." -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 18 04:36:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05644 for ; Tue, 18 Jan 2005 04:36:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqq2D-0002jb-Au for ipv6-web-archive@ietf.org; Tue, 18 Jan 2005 04:52:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqpe5-0002cH-DR; Tue, 18 Jan 2005 04:27:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqpbp-0002Kl-MZ for ipv6@megatron.ietf.org; Tue, 18 Jan 2005 04:25: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 EAA04194 for ; Tue, 18 Jan 2005 04:25:07 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqpr2-0002MN-VF for ipv6@ietf.org; Tue, 18 Jan 2005 04:40:54 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j0I9OUN6040172 for ; Tue, 18 Jan 2005 09:24:30 GMT Received: from d06av04.portsmouth.uk.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 j0I9Orh9133882 for ; Tue, 18 Jan 2005 09:24:54 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0I9OUk7017870 for ; Tue, 18 Jan 2005 09:24:30 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0I9OTNO017862; Tue, 18 Jan 2005 09:24:29 GMT Received: from zurich.ibm.com (dyn-9-159-99-60.bw.ch.ibm.com [9.159.99.60]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA93110; Tue, 18 Jan 2005 10:24:28 +0100 Message-ID: <41ECB96E.1000700@zurich.ibm.com> Date: Tue, 18 Jan 2005 08:23:26 +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: <41EB8A2D.5080606@zurich.ibm.com> <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> In-Reply-To: <6.1.2.0.2.20050117110533.03343b40@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: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: brian@innovationslab.net, ipv6@ietf.org Subject: Re: Proposed update to ULA Draft (-09) 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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Bob Hinden wrote: > Mark, > > Combining your two emails. > > At 04:40 AM 01/17/2005, Mark Smith wrote: > >> (as a side note, this is from Rev 8, the nokia web site resolves to an >> IPv6 address, I don't seem to be able to get to it via my 6to4 >> connection though) >> >> For link-state IGPs, it is suggested that a site utilizing ULA >> prefixes be contained either within one IGP domain or area. By >> containing a ULA prefix to a single link-state area or domain, the >> distribution of prefixes can be controlled. >> >> I think it potentially could cause conflicts with the idea of using the >> same subnet numbers as those used with a global prefix. > > > The language "it is suggested" was chosen to allow flexibility. As you > point out in large multi domain/area deployments there are reasons to do > it differently. > > At 05:09 AM 01/17/2005, Mark Smith wrote: > >> On Mon, 17 Jan 2005 23:10:34 +1030 >> Mark Smith wrote: >> >> > >> > I'm not sure what my opinion is regarding which addressing model would >> > be best, and maybe there isn't one "best" one. I suppose both of them >> > could be suggested, with the caveats of each of them described. >> > Possibly, it may be outside of the scope of this RFC. More discussion >> > might help. >> > >> >> Or, to get this ID moving, remove both suggestions, and leave this >> issue to be addressed somewhere else. > > > In my personal view, this would be the best course for now. Later on it > would be good to get feedback on how people deploy ULAs in operational > networks. For example, this might be a good activity for v6ops. > Actually, I would be surprised if there wasn't a lot of interest in > tracking deployment and operational experience. I guess. It's a shame this point didn't come up during Last Call. If we change something other than what the IESG asked us to change, we are on the edge of a process problem. I though that lower-case "suggested" was OK - it's much weaker than an official SHOULD, which would certainly be a mistake for the reasons Mark gave. Brian C -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 18 10:10:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29663 for ; Tue, 18 Jan 2005 10:10:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvEr-00022g-HU for ipv6-web-archive@ietf.org; Tue, 18 Jan 2005 10:25:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CquxJ-0000ys-FS; Tue, 18 Jan 2005 10:07:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cquw2-0008Sk-Rv for ipv6@megatron.ietf.org; Tue, 18 Jan 2005 10:06:24 -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 KAA29291 for ; Tue, 18 Jan 2005 10:06:20 -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 1CqvBK-0001x9-Hi for ipv6@ietf.org; Tue, 18 Jan 2005 10:22:10 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.7717723; Tue, 18 Jan 2005 10:05:20 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Tue, 18 Jan 2005 10:05:21 -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> Phishing:<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-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: , Content-Type: multipart/mixed; boundary="===============1150233539==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============1150233539== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-1051986488; protocol="application/pkcs7-signature" --Apple-Mail-5-1051986488 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This starts a two week IPv6 working group last call on advancing: 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 as a Draft Standard. Substantive comments should be directed to the mailing list. Editorial comments can be sent to the editor. This Last Call will end on Feb. 1, 2005. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-5-1051986488 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTE4MTUwNTIyWjAjBgkqhkiG9w0B CQQxFgQUffXjcttQuEddFguvHwCARMquvAYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAP4R0vLGDwRkFY+bljbgm31XuCmq/am3QuwI8qgA57FaVuaS1Zs9RiWcWHedtcvPQCKs8 7eaauUbBQSV+B7DvwSMakBeQEldFOuePSFYVx5JorsnE7CfAIk5fSa/l6v9YkbBbm9u1VkIsfLxa 9qIZTiVIAwFrgm/E435tMWsG1qZlEN3ZwOT2UMf+iCfHtuBTZWIxAX/pZW7Msaz5n/DeGf7i4wXd I1vO/SDq2LUyMkmNcOu7b/t59OfsZg8WkD2zGwb89EDRogzVRs80ktmtFt6dXZM24QyBmE2nXAw1 Det7hPeljtHEoG1orHzB18LH5n7FW3Lt7R0LmoSM/apffQAAAAAAAA== --Apple-Mail-5-1051986488-- --===============1150233539== 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 -------------------------------------------------------------------- --===============1150233539==-- From ipv6-bounces@ietf.org Tue Jan 18 10:49:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04464 for ; Tue, 18 Jan 2005 10:49:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvrN-0003AT-KF for ipv6-web-archive@ietf.org; Tue, 18 Jan 2005 11:05:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvWs-00064P-Px; Tue, 18 Jan 2005 10:44:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvQE-0001vM-44 for ipv6@megatron.ietf.org; Tue, 18 Jan 2005 10:37: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 KAA03037; Tue, 18 Jan 2005 10:37:30 -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 1CqvfU-0002jF-72; Tue, 18 Jan 2005 10:53:21 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.11960426; Tue, 18 Jan 2005 10:36:40 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IESG Secretary , Margaret Wasserman , Thomas Narten Message-Id: From: Brian Haberman Date: Tue, 18 Jan 2005 10:36:40 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IPv6 WG , Bob Hinden Subject: Request To Advance:draft-ietf-ipv6-host-load-sharing-03.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="===============1335750938==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --===============1335750938== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-1053865881; protocol="application/pkcs7-signature" --Apple-Mail-10-1053865881 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Margaret & Thomas, On behalf of the IPv6 WG, the chairs request the advancement of: Title : IPv6 Host to Router Load Sharing Author(s) : R. Hinden, D. Thaler Filename : draft-ietf-ipv6-host-load-sharing-03.txt Pages : 6 Date : 2004-10-21 as a Proposed Standard. This document reflects the consensus of the IPv6 WG. The Last Call completed on Nov. 1, 2004. Regards, Bob & Brian --Apple-Mail-10-1053865881 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTE4MTUzNjQxWjAjBgkqhkiG9w0B CQQxFgQU1Hu0fq4B5wNqotkJF5i4wykVL+QweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEArpQcl2XbpjzWC+s0EwLDwZYvxNiAI9zUNknghnumQVYKTCHi2UPC1qndboD4aXervwwI mQd6dIrZBGaigbKLFqUtZgSNaaWp7DLSOnq1gU5Re25FhoyVeEC/NVm1nA8PSwaKl77p6/aSTgKQ s5J0CJnHw59Wsodv35kG/necfXS3yvZcBoUwKKmC0DY28IKsSx3Ln8A7fIzv3KTQRW69Tr2co3ri h2G0pfs/Oqj+YNOkXfz3Ivxmp2zLiMRPkw9pI8Wy1VpncFvqc9z6DoojxIsr77WD9hsaG6lkR70E c2cKyOU8UYpXTE/gZ/fLx+6rD/LCrVgXt1YUHCoA/ktMxgAAAAAAAA== --Apple-Mail-10-1053865881-- --===============1335750938== 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 -------------------------------------------------------------------- --===============1335750938==-- From ipv6-bounces@ietf.org Tue Jan 18 10:57:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05295 for ; Tue, 18 Jan 2005 10:57:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqvyj-0003QG-E9 for ipv6-web-archive@ietf.org; Tue, 18 Jan 2005 11:13:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvWz-00068N-JE; Tue, 18 Jan 2005 10:44:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvUH-0005L5-Pj for ipv6@megatron.ietf.org; Tue, 18 Jan 2005 10:41:45 -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 KAA03427 for ; Tue, 18 Jan 2005 10:41:42 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvjY-0002ps-Ps for ipv6@ietf.org; Tue, 18 Jan 2005 10:57:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0IFevB13288; Tue, 18 Jan 2005 17:40:57 +0200 Date: Tue, 18 Jan 2005 17:40:57 +0200 (EET) From: Pekka Savola To: Brian Haberman 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: ea4ac80f790299f943f0a53be7e1a21a Cc: Bob Hinden , IPv6 WG Subject: Re: Proposed update to ULA Draft (-09) 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 On Fri, 14 Jan 2005, Brian Haberman wrote: > We wanted the working group to review the proposed changes before a new > version was submitted. I see no big problem with the changes, but the bullet point one of the changes refers to was this: The default behavior of exterior routing protocol sessions between administrative routing regions must be to ignore receipt of and not advertise prefixes in the FC00::/7 block. A network operator may specifically configure prefixes longer than FC00::/7 for inter-site communication. If BGP is being used at the site border with an ISP, the default BGP configuration must filter out any Local IPv6 address prefixes, both incoming and outgoing. This was discussed (without a resolution) in November: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03898.html This 'default behaviour must be to ignore' seems rather inpractical to implement from vendor's perspective (unless you create a special knob 'allow-ula' applicable to eBGP). Therefore I'm doubtful whether it gets implemented.. -- 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 Jan 18 10:59:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05438 for ; Tue, 18 Jan 2005 10:59:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqw0J-0003UH-Kw for ipv6-web-archive@ietf.org; Tue, 18 Jan 2005 11:14:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvX3-0006Fc-Dw; Tue, 18 Jan 2005 10:44:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvUw-0005Y7-Lk for ipv6@megatron.ietf.org; Tue, 18 Jan 2005 10:42: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 KAA03513 for ; Tue, 18 Jan 2005 10:42:24 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvkE-0002s9-2s for ipv6@ietf.org; Tue, 18 Jan 2005 10:58:14 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0IFgM427595; Tue, 18 Jan 2005 17:42:23 +0200 (EET) X-Scanned: Tue, 18 Jan 2005 17:42:15 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0IFgFq8025277; Tue, 18 Jan 2005 17:42:15 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00tlrUJA; Tue, 18 Jan 2005 17:41:27 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0IFf9U08624; Tue, 18 Jan 2005 17:41:09 +0200 (EET) Received: from l5131412.nokia.com ([10.241.50.43]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 Jan 2005 17:41:06 +0200 Message-Id: <6.1.2.0.2.20050118073131.034370e8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 18 Jan 2005 07:41:02 -0800 To: Brian E Carpenter From: Bob Hinden In-Reply-To: <41ECB96E.1000700@zurich.ibm.com> References: <41EB8A2D.5080606@zurich.ibm.com> <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> <41ECB96E.1000700@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Jan 2005 15:41:06.0957 (UTC) FILETIME=[20161BD0:01C4FD74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipv6@ietf.org Subject: Re: Proposed update to ULA Draft (-09) 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 Brian, >>>Or, to get this ID moving, remove both suggestions, and leave this >>>issue to be addressed somewhere else. >> >>In my personal view, this would be the best course for now. Later on it >>would be good to get feedback on how people deploy ULAs in operational >>networks. For example, this might be a good activity for v6ops. >>Actually, I would be surprised if there wasn't a lot of interest in >>tracking deployment and operational experience. > >I guess. It's a shame this point didn't come up during Last Call. >If we change something other than what the IESG asked us to change, >we are on the edge of a process problem. I though that lower-case >"suggested" was OK - it's much weaker than an official SHOULD, which >would certainly be a mistake for the reasons Mark gave. To clarify, I read Mark's text ("remove both suggestions") as "remove both of the suggestions he made in his email" and to not change the current text. Mark should verify this. I agree with your points that changing this text at this point will require going back to the ADs to revisit the issue and I don't think the further delay is worth it. 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 Jan 18 14:23:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22019 for ; Tue, 18 Jan 2005 14:23:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzC4-0000dP-Kf for ipv6-web-archive@ietf.org; Tue, 18 Jan 2005 14:39:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqyrl-0003oQ-A5; Tue, 18 Jan 2005 14:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqynt-0003N2-Q2 for ipv6@megatron.ietf.org; Tue, 18 Jan 2005 14:14: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 OAA21342; Tue, 18 Jan 2005 14:14:11 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqz3B-0000O8-MB; Tue, 18 Jan 2005 14:30:03 -0500 Received: from jurassic.eng.sun.com ([129.146.89.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j0IJE9iI006818; Tue, 18 Jan 2005 11:14:09 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0IJE81H667805; Tue, 18 Jan 2005 11:14:09 -0800 (PST) Message-ID: <41ED6002.8070003@sun.com> Date: Tue, 18 Jan 2005 11:14:10 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden References: <6.1.2.0.2.20050117143447.03183760@mailhost.iprg.nokia.com> In-Reply-To: <6.1.2.0.2.20050117143447.03183760@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Thomas Narten , IESG Secretary , IPv6 Mailing List Subject: Re: Request to Advance: [RESEND] 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 Bob Hinden wrote: > [Corrected error in subject line] > > Margaret & Thomas, > > On behalf of the IPv6 WG, the chairs request the advancement of: > > 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 a Informational RFC. This document represents the consensus of the IPv6 > working group. The Last Call completed on December 28, 2004. I for one missed the last call, because I was on vacation during much of those two weeks. Given that there isn't likely to be an IETF-wide last call, I'd wish the WG and/or ADs take these comments into account. I think there are several serious reasons why the document should not be published (which I've expressed in the past in the IPv6 WG): - There has not been much review of the document in the WG; very few if any messages have been sent on the WG mailing list and there were no last call comments. - There doesn't seem to be much interest in the protocol in the WG. If there was one would expect there to be clarifying questions (because I find the document less than clear to implement from). If there isn't much interest, maybe this item should be removed from the WG charter instead of publishing a poorly reviewed document. - The protocol, if deployed, can cause harm to the Internet. The primary source of harm is the optional loop prevention. This will cause networks to melt when proxies are configured in a loop, since proxies are constrained to not decrement the IP ttl. Note that these loops would be particularely severe for IP multicast, since such packets are duplicated and sent out each proxy interface. - Another form of potential harm is creating obstacles for deployment of Secure Neighbor Discovery. The protocol does not work in conjunction with SeND, which is particularely odd since section 3 explicitly lists this as a requirement. (The line of reasons seems to be that it is a fault of SeND that proxynd doesn't work when SeND is used, which is a bit odd.) Note that if there is sufficient interest in the WG, it isn't hard to solve the two technical issues listed above. (But the SeND interaction would require the proxies to be able to be promiscious receivers, which might be problematic in the wireless upstream scenario). There is at least one other listed requirement which the protocol doesn't seem to satisfy: - Allow dynamic removal of a proxy without adversly disrupting the network Since there will be host which have the, now dead, proxy's link layer address in their ARP/ND cache, communication will fail until this stale information is flushed, which might take a minute or so. That seems like an adverse impact on the network too me. Regards, Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 18 18:25:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17665 for ; Tue, 18 Jan 2005 18:25:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr2yU-0008Rt-8h for ipv6-web-archive@ietf.org; Tue, 18 Jan 2005 18:41:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2fZ-0000v5-WD; Tue, 18 Jan 2005 18:21:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2XK-0004Qf-Lz for ipv6@megatron.ietf.org; Tue, 18 Jan 2005 18:13:24 -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 SAA16433 for ; Tue, 18 Jan 2005 18:13:19 -0500 (EST) Received: from 178.cust6.sa.dsl.ozemail.com.au ([210.84.229.178] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr2me-0008CY-OT for ipv6@ietf.org; Tue, 18 Jan 2005 18:29:14 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 60B0862AAE; Wed, 19 Jan 2005 09:43:12 +1030 (CST) Date: Wed, 19 Jan 2005 09:43:12 +1030 From: Mark Smith To: Bob Hinden Message-Id: <20050119094312.2495a2f6.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <6.1.2.0.2.20050118073131.034370e8@mailhost.iprg.nokia.com> References: <41EB8A2D.5080606@zurich.ibm.com> <20050117231034.1b7772d6.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.1.2.0.2.20050117110533.03343b40@mailhost.iprg.nokia.com> <41ECB96E.1000700@zurich.ibm.com> <6.1.2.0.2.20050118073131.034370e8@mailhost.iprg.nokia.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: brc@zurich.ibm.com, ipv6@ietf.org Subject: Re: Proposed update to ULA Draft (-09) 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: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On Tue, 18 Jan 2005 07:41:02 -0800 Bob Hinden wrote: > Brian, > > >>>Or, to get this ID moving, remove both suggestions, and leave this > >>>issue to be addressed somewhere else. > >> > >>In my personal view, this would be the best course for now. Later on it > >>would be good to get feedback on how people deploy ULAs in operational > >>networks. For example, this might be a good activity for v6ops. > >>Actually, I would be surprised if there wasn't a lot of interest in > >>tracking deployment and operational experience. > > > >I guess. It's a shame this point didn't come up during Last Call. > >If we change something other than what the IESG asked us to change, > >we are on the edge of a process problem. I though that lower-case > >"suggested" was OK - it's much weaker than an official SHOULD, which > >would certainly be a mistake for the reasons Mark gave. > > To clarify, I read Mark's text ("remove both suggestions") as "remove both > of the suggestions he made in his email" and to not change the current > text. Mark should verify this. > I was thinking, because of the conflicts, delete both the text suggesting that subnet numbers would be shared between ULA and global prefixes, and the suggestion for separate ULA /48 prefixes per IGP domain or area. I'd think making no recommendation would be better than making ones that may need to be clarified or contradicted at a later date. Regards, Mark. -- "This signature intentionally left blank." -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 19 04:44:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25128 for ; Wed, 19 Jan 2005 04:44:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrCdk-00054s-Kg for ipv6-web-archive@ietf.org; Wed, 19 Jan 2005 05:00:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCLL-0005z9-Md; Wed, 19 Jan 2005 04:41:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCKT-0005Yq-0K for ipv6@megatron.ietf.org; Wed, 19 Jan 2005 04:40:45 -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 EAA24827 for ; Wed, 19 Jan 2005 04:40:42 -0500 (EST) Message-Id: <200501190940.EAA24827@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 1CrCZt-0004zL-SH for ipv6@ietf.org; Wed, 19 Jan 2005 04:56:42 -0500 Received: from eaglet (127.0.0.1:3125) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 19 Jan 2005 01:40:36 -0800 From: "Tony Hain" To: "'Brian E Carpenter'" , "'Brian Haberman'" Date: Wed, 19 Jan 2005 01:40:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcT8e9IksYaIRZV2T2W21s2mO9qoHABgB94w In-Reply-To: <41EB8A2D.5080606@zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Cc: "'IPv6 WG'" , "'Bob Hinden'" Subject: RE: Proposed update to ULA Draft (-09) 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.8 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit I agree this version is fine and needs to be out the door already. There area a number of conflicting trade-offs in address management and as such there will never be a one-size-fits-all solution that the IESG seems to so desperately want. This document spells out a need, discusses alternatives then shows how to fill it, and explains why this approach should not be used to solve unrelated problems. There is nothing more it can do so it is time to ship it. Tony > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Monday, January 17, 2005 1:50 AM > To: Brian Haberman > Cc: Bob Hinden; IPv6 WG > Subject: Re: Proposed update to ULA Draft (-09) > > I support this version. Although I don't fully agree with > the concerns expressed by some IESG members, I think this > new version is quite OK, and the quickest way make ULAs > available to networks that need them. > > Brian > > Brian Haberman wrote: > > IPv6 WG, > > > > In order to resolve the last IESG discuss comment on the ULA draft two > > sets of changes are proposed. Sam Hartman, who holds the Discuss, has > > reviewed these changes and said these proposed changes resolve the > > Discuss. The changes are: > > > > o Removed all mention of centrally assigned IPv6 local address > > addresses based on IESG comments. L=0 is left to be defined in > > the future. > > > > o Added new section titled "Global Routing Considerations" that > > discusses the issues relating to why using these addresses for > > general purpose unicast address on the global internet is not a > > good idea. > > > > An updated draft with the proposed changes can be found at: > > > > http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr > > -09.txt > > > > along with an diffed version (-09 vs. -08) at: > > > > http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr > > -09.html > > > > (Note the htmldiff that was used to produce the html diff file got a > > little confused in places, but it is still useful to see the changes). > > > > The new section 5.0 is also attached inline below. > > > > We wanted the working group to review the proposed changes before a new > > version was submitted. > > > > Thanks, > > Bob Hinden / Brian Haberman > > IPv6 working group chairs > > > > ---------------------------- > > > > > > 5.0 Global Routing Considerations > > > > Section 4.1 provides operational guidelines that forbid default > > routing of local addresses between sites. Concerns were raised to > > the IPv6 working group and to the IETF as a whole that sites may > > attempt to use local addresses as globally routed provider- > > independent addresses. This section describes why using local > > addresses as globally-routed provider-independent addresses is > > unadvisable. > > > > 5.1 From the Standpoint of the Internet > > > > There is a mismatch between the structure of IPv6 local addresses and > > the normal IPv6 wide area routing model. The /48 prefix of an IPv6 > > local addresses fits nowhere in the normal hierarchy of IPv6 unicast > > addresses. Normal IPv6 unicast addresses can be routed > > hierarchically down to physical subnet (link) level and only have to > > be flat-routed on the physical subnet. IPv6 local addresses would > > have to be flat-routed even over the wide area Internet. > > > > Thus, packets whose destination address is an IPv6 local address > > could be routed over the wide area only if the corresponding /48 > > prefix were carried by the wide area routing protocol in use, such as > > BGP. This contravenes the operational assumption that long prefixes > > will be aggregated into many fewer short prefixes, to limit the table > > size and convergence time of the routing protocol. If a network uses > > both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these > > types of address will certainly not aggregate with each other, since > > they differ from the most significant bit onwards. Neither will IPv6 > > local addresses aggregate with each other, due to their random bit > > patterns. This means that there would be a very significant > > operational penalty for attempting to use IPv6 local address prefixes > > generically with currently known wide area routing technology. > > > > 5.2 From the Standpoint of a Site > > > > There are a number of design factors in IPv6 local addresses that > > reduce the likelihood that IPv6 local addresses will be used as > > arbitrary global unicast addresses. These include: > > > > - The default rules to filter packets and routes make it very > > difficult to use IPv6 local addresses for arbitrary use across > > the Internet. For a site to use them as general purpose unicast > > addresses, they would have to make sure that the default rules > > were not being used by all other sites and intermediate ISPs > > used for their current and future communication. > > > > - They are not mathematically guaranteed to be unique and are not > > registered in public databases. Collisions, while highly > > unlikely, are possible and a collision can compromise the > > integrity of the communications. The lack of public > > registration creates operational problems. > > > > - The addresses are allocated randomly. If a site had multiple > > prefixes that they wanted to be used globally the cost of > > advertising them would be very high as they could not be > > aggregated. > > > > - They have a long prefix (i.e, /48) so a single local address > > prefix doesn't provide enough address space to be used > > exclusively by the largest organizations. > > > > --------------------- > > > > > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > 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 Wed Jan 19 06:46:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03420 for ; Wed, 19 Jan 2005 06:46:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrEXq-0007vV-N0 for ipv6-web-archive@ietf.org; Wed, 19 Jan 2005 07:02:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrEGn-0006Qd-EH; Wed, 19 Jan 2005 06:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrEGJ-0006H7-LQ for ipv6@megatron.ietf.org; Wed, 19 Jan 2005 06:44: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 GAA03371 for ; Wed, 19 Jan 2005 06:44:32 -0500 (EST) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrEVj-0007re-VA for ipv6@ietf.org; Wed, 19 Jan 2005 07:00:34 -0500 Received: from [81.187.254.249] (helo=study.dial.pipex.com) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1CrEG4-0004Ng-9G; Wed, 19 Jan 2005 11:44:20 +0000 Message-Id: <6.2.0.14.0.20050119103411.01ecf158@imap.dial.pipex.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Jan 2005 11:46:50 +0000 To: Brian Haberman , IPv6 WG From: Elwyn Davies In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Bob Hinden Subject: Re: Proposed update to ULA Draft (-09) 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: c0bedb65cce30976f0bf60a0a39edea4 Hi. Overall this should be out there rsn. However, there are is one point that needs clearing up in the estimation of collision probability (S3.2.3): In para 2 (above the formula), N is stated to be the total number of such IDs whereas in parentheses after the formula N is defined to be the number of connections). I believe what is meant is that N is the total number of Global IDs that are interconnected. Also suggest the phrase after the formula would be better as: where P is the probability of collision, N is the number Global IDs interconnected and L is the length of the global ID. Few minor wording grumbles: S3.1.1, last para: Trillion is not an internationally unique term: s/trillion/*10^12/ S3.2.1, para 1: The second sentence doesn't say quite what it means now: s/ It is important to ensure a reasonable likelihood of uniqueness that all sites generating a Global IDs use a functionally similar algorithm. / It is important that all sites generating Global IDs use a functionally similar [equivalent??] algorithm to ensure there is a reasonable likelihood [high probability???] of uniqueness. / I have vague recollections that the word 'similar' was settled on here after considerable discussion. Many places (S3.1 (3 places), S3.1.1 (3 places), S3.2.1 (2 places), S3.2.2 (2 places), S3.2.3(8 places), S6.2): Capitalization of Global ID is not consistent: s/global ID/Global ID/ S3.2.2, last para; S4.4 (2 places): s/local IPv6/Local IPv6/ S4.3, paras 2 and 3: There seems to be some duplication of words here: The "reject" route is installed twice and ICMPv6 considerations are duplicated. I am not sure if these were originally intended to say different things? S4.5: s/reachable any point/reachable at any point/ S4.6: s/automatically the way/automatically in the way/ S5.0, first para: s/unadvisable/inadvisable/ [OK... this is a personal thing] Regards, Elwyn At 00:09 15/01/2005, Brian Haberman wrote: >IPv6 WG, > >In order to resolve the last IESG discuss comment on the ULA draft two >sets of changes are proposed. Sam Hartman, who holds the Discuss, has >reviewed these changes and said these proposed changes resolve the >Discuss. The changes are: <> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 19 15:57:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22299 for ; Wed, 19 Jan 2005 15:57:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrN96-0006AQ-NJ for ipv6-web-archive@ietf.org; Wed, 19 Jan 2005 16:13:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrMgU-0003d9-W9; Wed, 19 Jan 2005 15:44:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrMUr-0006O6-Uv; Wed, 19 Jan 2005 15:32:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19245; Wed, 19 Jan 2005 15:32:08 -0500 (EST) Message-Id: <200501192032.PAA19245@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 19 Jan 2005 15:32:08 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-router-selection-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: 1a1bf7677bfe77d8af1ebe0e91045c5b --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 : Default Router Preferences and More-Specific Routes Author(s) : R. Draves, D. Thaler Filename : draft-ietf-ipv6-router-selection-07.txt Pages : 14 Date : 2005-1-19 This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-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-router-selection-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-router-selection-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: <2005-1-19154421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-router-selection-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-router-selection-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-19154421.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 Jan 20 07:11:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20154 for ; Thu, 20 Jan 2005 07:11:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrbPH-0004KW-0k for ipv6-web-archive@ietf.org; Thu, 20 Jan 2005 07:27:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crb6e-00041t-5b; Thu, 20 Jan 2005 07:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crb11-00035D-Oq for ipv6@megatron.ietf.org; Thu, 20 Jan 2005 07:02: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 HAA19498 for ; Thu, 20 Jan 2005 07:02:14 -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 1CrbGd-00045i-3K for ipv6@ietf.org; Thu, 20 Jan 2005 07:18:29 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.11/8.12.6) with ESMTP id j0KC1eVm095412 for ; Thu, 20 Jan 2005 21:01:40 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp150.64translator.com [10.21.32.150]) by bahamas.64translator.com (8.12.9p2/8.12.9) with SMTP id j0KC1eEn051121 for ; Thu, 20 Jan 2005 21:01:40 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Thu, 20 Jan 2005 21:01:39 +0900 From: Yukiyo Akisada To: ipv6@ietf.org Message-Id: <20050120210139.38897abf.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [2461bis] host variables on router 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 Content-Transfer-Encoding: 7bit Hi, all. 2461bis is still unclear for me. 6.2.1. says, 2369 The above variables contain information that is placed in outgoing 2370 Router Advertisement messages. Hosts use the received information to 2371 initialize a set of analogous variables that control their external 2372 behavior (see Section 6.3.2). Some of these host variables (e.g., 2373 CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes 2374 including routers. In practice, these variables may not actually be 2375 present on routers, since their contents can be derived from the 2376 variables described above. However, external router behavior MUST be 2377 the same as host behavior with respect to these variables. In 2378 particular, this includes the occasional randomization of the 2379 ReachableTime value as described in Section 6.3.2. Especially, the sentence - "external router behavior MUST be the same as host behavior with respect to these variables.", is unclear for me. Does it mean that the router has the same values as what the host receives from RA? For example, If the router is sending RA which contains RetransTimer=5 sec., should the router use 5 sec. as his own RetransTimer? I think 2461bis can be more clear. Regards, ---- 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 Jan 20 15:01:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29568 for ; Thu, 20 Jan 2005 15:01:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrikT-0000Hr-TX for ipv6-web-archive@ietf.org; Thu, 20 Jan 2005 15:17:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriIC-0005Tj-U0; Thu, 20 Jan 2005 14:48:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriEn-00053v-Ug for ipv6@megatron.ietf.org; Thu, 20 Jan 2005 14:45: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 OAA28343 for ; Thu, 20 Jan 2005 14:45:00 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CriUX-0008JU-EB for ipv6@ietf.org; Thu, 20 Jan 2005 15:01:17 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0KJiqO14100; Thu, 20 Jan 2005 21:44:53 +0200 (EET) X-Scanned: Thu, 20 Jan 2005 21:44:47 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0KJil7i029338; Thu, 20 Jan 2005 21:44:47 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00VSzpqA; Thu, 20 Jan 2005 21:44:45 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 j0KJhGU23757; Thu, 20 Jan 2005 21:43:17 +0200 (EET) Received: from l5131412.nokia.com ([172.19.69.218]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 Jan 2005 21:43:09 +0200 Message-Id: <6.1.2.0.2.20050120113637.0218fae8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 20 Jan 2005 11:43:06 -0800 To: Elwyn Davies From: Bob Hinden In-Reply-To: <6.2.0.14.0.20050119103411.01ecf158@imap.dial.pipex.com> References: <6.2.0.14.0.20050119103411.01ecf158@imap.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jan 2005 19:43:10.0044 (UTC) FILETIME=[4558D1C0:01C4FF28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Brian Haberman , IPv6 WG Subject: Re: Proposed update to ULA Draft (-09) 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 Elwyn, At 03:46 AM 01/19/2005, Elwyn Davies wrote: >Hi. > >Overall this should be out there rsn. > >However, there are is one point that needs clearing up in the estimation >of collision probability (S3.2.3): >In para 2 (above the formula), N is stated to be the total number of such >IDs whereas in parentheses after the formula N is defined to be the number >of connections). I believe what is meant is that N is the total number of >Global IDs that are interconnected. Also suggest the phrase after the >formula would be better as: > > where P is the probability of collision, N is the number > Global IDs interconnected and L is the length of the global ID. I agree. It the text after the formula should be: approximates the probability of collision (where N is the number interconnections global IDs and L is the length of the global ID). >Few minor wording grumbles: Thanks for the editorial suggestions. I will incorporate them as appropriate in the next draft. Thanks, Bob >S3.1.1, last para: Trillion is not an internationally unique term: >s/trillion/*10^12/ >S3.2.1, para 1: The second sentence doesn't say quite what it means now: >s/ > It is important to ensure a reasonable > likelihood of uniqueness that all sites generating a Global IDs use a > functionally similar algorithm. >/ > It is important that all sites generating Global IDs use a functionally > similar [equivalent??] algorithm to ensure there is a reasonable > likelihood [high probability???] of uniqueness. >/ >I have vague recollections that the word 'similar' was settled on here >after considerable discussion. > >Many places (S3.1 (3 places), S3.1.1 (3 places), S3.2.1 (2 places), S3.2.2 >(2 places), S3.2.3(8 places), S6.2): Capitalization of Global ID is not >consistent: s/global ID/Global ID/ > >S3.2.2, last para; S4.4 (2 places): s/local IPv6/Local IPv6/ > >S4.3, paras 2 and 3: There seems to be some duplication of words here: The >"reject" route is installed twice and ICMPv6 considerations are >duplicated. I am not sure if these were originally intended to say >different things? > >S4.5: s/reachable any point/reachable at any point/ > >S4.6: s/automatically the way/automatically in the way/ >S5.0, first para: s/unadvisable/inadvisable/ [OK... this is a personal thing] > >Regards, >Elwyn > >At 00:09 15/01/2005, Brian Haberman wrote: >>IPv6 WG, >> >>In order to resolve the last IESG discuss comment on the ULA draft two >>sets of changes are proposed. Sam Hartman, who holds the Discuss, has >>reviewed these changes and said these proposed changes resolve the >>Discuss. The changes are: ><> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 20 15:10:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00895 for ; Thu, 20 Jan 2005 15:10:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CritQ-0000Yw-NX for ipv6-web-archive@ietf.org; Thu, 20 Jan 2005 15:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriVY-00018t-Cx; Thu, 20 Jan 2005 15:02:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriLn-0006L9-2U for ipv6@megatron.ietf.org; Thu, 20 Jan 2005 14:52: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 OAA28932 for ; Thu, 20 Jan 2005 14:52:13 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CribW-0008Ub-Pg for ipv6@ietf.org; Thu, 20 Jan 2005 15:08:31 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0KJq6p08458; Thu, 20 Jan 2005 21:52:07 +0200 (EET) X-Scanned: Thu, 20 Jan 2005 21:51:45 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0KJpjBE008061; Thu, 20 Jan 2005 21:51:45 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 004SesTx; Thu, 20 Jan 2005 21:51:37 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0KJpWx17618; Thu, 20 Jan 2005 21:51:32 +0200 (EET) Received: from l5131412.nokia.com ([172.19.69.218]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 Jan 2005 21:51:30 +0200 Message-Id: <6.1.2.0.2.20050120114539.0311e660@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 20 Jan 2005 11:51:26 -0800 To: Pekka Savola From: Bob Hinden In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jan 2005 19:51:30.0870 (UTC) FILETIME=[6FDCCD60:01C4FF29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Brian Haberman , IPv6 WG Subject: Re: Proposed update to ULA Draft (-09) 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 Pekka, At 07:40 AM 01/18/2005, Pekka Savola wrote: >On Fri, 14 Jan 2005, Brian Haberman wrote: >>We wanted the working group to review the proposed changes before a new >>version was submitted. > >I see no big problem with the changes, but the bullet point one of the Thanks. Good to hear! >changes refers to was this: > > The default behavior of exterior routing protocol sessions between > administrative routing regions must be to ignore receipt of and not > advertise prefixes in the FC00::/7 block. A network operator may > specifically configure prefixes longer than FC00::/7 for inter-site > communication. > > If BGP is being used at the site border with an ISP, the default BGP > configuration must filter out any Local IPv6 address prefixes, both > incoming and outgoing. > > >This was discussed (without a resolution) in November: >http://www1.ietf.org/mail-archive/web/ipv6/current/msg03898.html > >This 'default behaviour must be to ignore' seems rather inpractical to >implement from vendor's perspective (unless you create a special knob >'allow-ula' applicable to eBGP). Therefore I'm doubtful whether it gets >implemented.. I think this was responded to: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03901.html This is mean as operational guidelines. We are not precluding a vendor from implementing such a "knob", but do not require it. This is based on discussion with the routing ADs as part of their review of the document. Regards, 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 Jan 20 16:00:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05392 for ; Thu, 20 Jan 2005 16:00:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crjfl-0001sV-Hy for ipv6-web-archive@ietf.org; Thu, 20 Jan 2005 16:16:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjG1-0003jT-9U; Thu, 20 Jan 2005 15:50:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjAw-0000wr-QB for ipv6@megatron.ietf.org; Thu, 20 Jan 2005 15:45: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 PAA04128 for ; Thu, 20 Jan 2005 15:45:04 -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 1CrjQh-0001Mm-22 for ipv6@ietf.org; Thu, 20 Jan 2005 16:01:23 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.7815525; Thu, 20 Jan 2005 15:44:10 -0500 In-Reply-To: <41ED6002.8070003@sun.com> References: <6.1.2.0.2.20050117143447.03183760@mailhost.iprg.nokia.com> <41ED6002.8070003@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <09184DF0-6B24-11D9-9FE3-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Thu, 20 Jan 2005 15:44:09 -0500 To: Erik Nordmark 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> Phishing:<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: 93e7fb8fef2e780414389440f367c879 Cc: Thomas Narten , Margaret Wasserman , IPv6 Mailing List , Bob Hinden Subject: Re: Request to Advance: [RESEND] 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="===============0849279646==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 --===============0849279646== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--902368847; protocol="application/pkcs7-signature" --Apple-Mail-2--902368847 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Erik, On Jan 18, 2005, at 14:14, Erik Nordmark wrote: > > I for one missed the last call, because I was on vacation during much > of those two weeks. Given that there isn't likely to be an IETF-wide > last call, I'd wish the WG and/or ADs take these comments into > account. > > I think there are several serious reasons why the document should not > be published (which I've expressed in the past in the IPv6 WG): > - There has not been much review of the document in the WG; very few > if > any messages have been sent on the WG mailing list and there were no > last call comments. For the most part, there has been less than optimal public discussion. The minutes from Seoul indicate that Thomas was less than happy with the level of comments. However, the people who did speak up were in favor of it. > - There doesn't seem to be much interest in the protocol in the WG. > If there was one would expect there to be clarifying questions > (because I find the document less than clear to implement from). > If there isn't much interest, maybe this item should be removed from > the WG charter instead of publishing a poorly reviewed document. > > - The protocol, if deployed, can cause harm to the Internet. The > primary source of harm is the optional loop prevention. This will > cause networks to melt when proxies are configured in a loop, since > proxies are constrained to not decrement the IP ttl. Note that these > loops would be particularely severe for IP multicast, since such > packets are duplicated and sent out each proxy interface. I think that saying it harms the Internet is a little broad. The use cases for proxynd is more at the edge. Loops will be localized and shouldn't bring the whole Internet down. > - Another form of potential harm is creating obstacles for deployment > of Secure Neighbor Discovery. The protocol does not work in > conjunction with SeND, which is particularely odd since section 3 > explicitly lists this as a requirement. (The line of reasons seems > to > be that it is a fault of SeND that proxynd doesn't work when SeND is > used, which is a bit odd.) The security section points out, correctly, that 2461 supports proxying and that SeND doesn't support it. In addition, the scenarios supported by proxynd don't seem to be the same as those where SeND would be used. > > Note that if there is sufficient interest in the WG, it isn't hard to > solve the two technical issues listed above. (But the SeND interaction > would require the proxies to be able to be promiscious receivers, > which might be problematic in the wireless upstream scenario). Agree that may be an issue. The question is whether SeND would be used in that scenario. > > There is at least one other listed requirement which the protocol > doesn't seem to satisfy: > - Allow dynamic removal of a proxy without adversly disrupting the > network > Since there will be host which have the, now dead, proxy's link layer > address in their ARP/ND cache, communication will fail until this > stale information is flushed, which might take a minute or so. > That seems like an adverse impact on the network too me. Agree that removal of a proxy, or the loss of a proxy, could adversely affect the network. However, this seems equivalent to a network failure or re-design and not an everyday activity. Regards, Brian --Apple-Mail-2--902368847 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTIwMjA0NDEwWjAjBgkqhkiG9w0B CQQxFgQUz11HL+IAi4Wf/bwms/KHXZ4IDwcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAeek1f6Q3TwcL76WqWGCJwDBxVhn3+iOo8fn3wmZ2sPYqkvurkqHOnivVXfPj4dZjxPAH sYev+WwwhW7Zk4YQUcf8ijE4eLxv9XOWSbA8i+KsqFdbnVrTgKqHWO3VhK9CQSAf2DRpPH/TUZdA 1HfHOz+ZUxLJCiG5/syJhd2MSQ16tRuYROV99pU81P6HxfTs1Kyb6mFoP8in7mrM2TIcGsACc95b 9GCCYJXpqeERstsNLYpsSMVUEw2ubVyHj+jKSvu/NVdbMFvlFYCT9y1P2X8zgB5nZL9uvFZKCRfB V+NF3cn1cT3t4zPA0fMhLw6g2h5C8WvnLoQ21iiXYLtpGQAAAAAAAA== --Apple-Mail-2--902368847-- --===============0849279646== 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 -------------------------------------------------------------------- --===============0849279646==-- From ipv6-bounces@ietf.org Thu Jan 20 17:41:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21181 for ; Thu, 20 Jan 2005 17:41:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrlEw-00079r-At for ipv6-web-archive@ietf.org; Thu, 20 Jan 2005 17:57:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkhE-0005kF-D1; Thu, 20 Jan 2005 17:22:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkSE-0007aZ-8Q for ipv6@megatron.ietf.org; Thu, 20 Jan 2005 17:07: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 RAA16879 for ; Thu, 20 Jan 2005 17:06:59 -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 1Crkhy-0005h6-78 for ipv6@ietf.org; Thu, 20 Jan 2005 17:23:19 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.7818368; Thu, 20 Jan 2005 17:06:07 -0500 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Message-Id: <7BFD08ED-6B2F-11D9-9FE3-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Thu, 20 Jan 2005 17:06:06 -0500 To: IPv6 WG 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> Phishing:<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: 0fa76816851382eb71b0a882ccdc29ac Subject: Re: Proposed update to ULA Draft (-09) 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="===============0865500924==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============0865500924== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--897451624; protocol="application/pkcs7-signature" --Apple-Mail-4--897451624 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Given that the changes proposed to the ULA spec are in response to IESG Discuss comments, I have not seen reasonable justification to make any of the functional changes mentioned in this thread. Given that, I am directing Bob to only incorporate editorial changes where necessary. For those of you who did make technical comments on the operational guidelines in the document, the goal is to use get the ULAs out so that they can be used and feedback gathered on their behavior. At that time, the spec will be open for modifications as they are needed. Regards, Brian --Apple-Mail-4--897451624 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTIwMjIwNjA3WjAjBgkqhkiG9w0B CQQxFgQUyCw6Xt3o8++6+DjtvcK6BiW7FRcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAr2pYvoMO3R/Ed1tWnnEzkJdmw3Fj3YcWPuHit4sASLI3ciW2NGmzG2XxJOi2AEKi49wo N6V7s+geuj5k2tn85mKg7/GYOyIVhhckR85Nyk7ZUalsD1++jCrGe1sQVES1x+7PDKanZUxiEykZ v0yxB5+BwjqPUBnILUUSemHPOWJZN7gKbPYNVF97XC97B6gBkNioHhVb1S4nPnJGP9+Zffk8qKpd EXRCCDym18De0w6dG+m3HLaqvuxDBuZ0Y15br6ns6ZSEgp90Ksxj8PlRffImr1073/HcagYGE/xH ubmPGPHSlVvdM3dPIDbjQHfuMYzW8G9dWk9oCEkDctih4AAAAAAAAA== --Apple-Mail-4--897451624-- --===============0865500924== 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 -------------------------------------------------------------------- --===============0865500924==-- From ipv6-bounces@ietf.org Thu Jan 20 21:03:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06719 for ; Thu, 20 Jan 2005 21:03:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CroOj-0003W3-6W for ipv6-web-archive@ietf.org; Thu, 20 Jan 2005 21:19:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cro3i-0004O0-Pb; Thu, 20 Jan 2005 20:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrnzT-0003g4-Fj for ipv6@megatron.ietf.org; Thu, 20 Jan 2005 20:53: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 UAA06164 for ; Thu, 20 Jan 2005 20:53:32 -0500 (EST) Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CroFE-0003Ke-B8 for ipv6@ietf.org; Thu, 20 Jan 2005 21:09:54 -0500 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id j0L1kEhi021000 for ; Fri, 21 Jan 2005 09:46:23 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jan 21 09:52:25 2005 +0800 Received: from asbmail2.sbell.com.cn ([172.24.208.62]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 09:52:24 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Jan 2005 09:52:25 +0800 Message-ID: <9570C1261494D54D9D3115BC2C83429A0BB696@asbmail2.sbell.com.cn> Thread-Topic: new draft (ietf-yan-ipv6-ra-dns-00.txt) Thread-Index: AcT/W9qb+0LnCxCoQdK526ep5ze2Dg== From: "CTO YAN Renxiang" To: X-OriginalArrivalTime: 21 Jan 2005 01:52:24.0898 (UTC) FILETIME=[DAAB4220:01C4FF5B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: new draft (ietf-yan-ipv6-ra-dns-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="===============1307066151==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is a multi-part message in MIME format. --===============1307066151== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FF5B.DAC49D24" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FF5B.DAC49D24 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, =20 I've written a new individual submissions: http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt =20 Abstract: This document specifies a method to update domain name for IPv6 node whose address is configured using IPv6 stateless address configuration. It is implemented by defining a new option in=20 Router Advertisement (RA) / Router Solicitation (RS) messages. =20 Please take a look at it and provide comments. I'd like to request this = to become IPv6 WG work items.=20 =20 Thanks. =20 - Renxiang =20 =20 =20 ------_=_NextPart_001_01C4FF5B.DAC49D24 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi = all,
 
I've written a = new=20 individual submissions:
http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt
 
Abstract:
   This document = specifies a=20 method to update domain name for IPv6 node
   whose address = is=20 configured using IPv6 stateless address
   = configuration.  It=20 is implemented by defining a new option in
   Router = Advertisement=20 (RA) / Router Solicitation (RS) messages.
 
Please take a look = at it=20 and provide comments. I'd like to request this to = become
IPv6 WG work items. =
 
Thanks.
 
- = Renxiang
 
 
 
------_=_NextPart_001_01C4FF5B.DAC49D24-- --===============1307066151== 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 -------------------------------------------------------------------- --===============1307066151==-- From ipv6-bounces@ietf.org Fri Jan 21 00:46:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19679 for ; Fri, 21 Jan 2005 00:46:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crrsb-0008En-IH for ipv6-web-archive@ietf.org; Fri, 21 Jan 2005 01:02:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrrWI-0006D1-1W; Fri, 21 Jan 2005 00:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrrRg-0005Qt-N8 for ipv6@megatron.ietf.org; Fri, 21 Jan 2005 00:34: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 AAA18669 for ; Fri, 21 Jan 2005 00:34:53 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrrhV-0007xe-HF for ipv6@ietf.org; Fri, 21 Jan 2005 00:51:17 -0500 Received: from jurassic.eng.sun.com ([129.146.83.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0L5YsVu022763; Thu, 20 Jan 2005 22:34:54 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0L5Yrt0853934; Thu, 20 Jan 2005 21:34:53 -0800 (PST) Message-ID: <41F09480.8010707@sun.com> Date: Thu, 20 Jan 2005 21:34:56 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: brian@innovationslab.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , IPv6 Subject: Re: Request to Advance: [RESEND] 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hello Brian, > For the most part, there has been less than optimal public > discussion. The minutes from Seoul indicate that Thomas was less than > happy with the level of comments. However, the people who did speak > up were in favor of it. Hmm - I'm spoken up in more than one IPv6 WG meeting pointing out the flaws in the protocol. So clearly all people that spoke up were not in favor of it. I take it from your detailed responses below that you see it in IETF's best interest to publish this document and protocol without any quality improvements to neither the document nor the protocol. Did I understand that correctly? > I think that saying it harms the Internet is a little broad. The use > cases for proxynd is more at the edge. Loops will be localized and > shouldn't bring the whole Internet down. I suspect the users that will have their "measly" edge networks melt down would disagree with this; the harm doesn't have to make everything melt at once for it to be a harmful thing AFAIK. > - Another form of potential harm is creating obstacles for deployment > of Secure Neighbor Discovery. The protocol does not work in > conjunction with SeND, which is particularely odd since section 3 > explicitly lists this as a requirement. (The line of reasons seems to > be that it is a fault of SeND that proxynd doesn't work when SeND is > used, which is a bit odd.) > > > The security section points out, correctly, that 2461 supports > proxying and that SeND doesn't support it. In addition, the scenarios > supported by proxynd don't seem to be the same as those where SeND > would be used. Yes, but as I stated above, section 3 explicitly says that working with SeND is a requirement for proxynd. And then the protocol doesn't satisfy that. Given that the protocol doesn't satisfy what the document itself says are the requirements, the document (and perhaps the protocol as well) has a quality problem by being self-inconsistent. > Note that if there is sufficient interest in the WG, it isn't hard to > solve the two technical issues listed above. (But the SeND > interaction would require the proxies to be able to be promiscious > receivers, which might be problematic in the wireless upstream > scenario). > > > Agree that may be an issue. The question is whether SeND would be > used in that scenario. The counterexample is that there are ISPs that have their home users with 802.11 run public hotspots and get some compensation from the ISP. In this case, since it is a public access 802.11, SeND would be a good thing to use. And 802.11 is also a key scenario for proxynd. > There is at least one other listed requirement which the protocol > doesn't seem to satisfy: - Allow dynamic removal of a proxy without > adversly disrupting the network Since there will be host which have > the, now dead, proxy's link layer address in their ARP/ND cache, > communication will fail until this stale information is flushed, > which might take a minute or so. That seems like an adverse impact on > the network too me. > > > Agree that removal of a proxy, or the loss of a proxy, could > adversely affect the network. However, this seems equivalent to a > network failure or re-design and not an everyday activity. Again, the issue is the self-inconsistency in the document/protocol. Section 3 says that dynamic removal of a proxy should adversely disrupt the network. Yet the protocol doesn't satisfy this requirement as far as I can see. Regards, Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 21 10:03:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16758 for ; Fri, 21 Jan 2005 10:03:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs0Zo-0005wR-0I for ipv6-web-archive@ietf.org; Fri, 21 Jan 2005 10:19:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs08s-00053q-2k; Fri, 21 Jan 2005 09:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs01e-00033Z-G0 for ipv6@megatron.ietf.org; Fri, 21 Jan 2005 09:44: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 JAA15449 for ; Fri, 21 Jan 2005 09:44:36 -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 1Cs0HY-0005Mw-7F for ipv6@ietf.org; Fri, 21 Jan 2005 10:01:04 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.7839648; Fri, 21 Jan 2005 09:43:43 -0500 In-Reply-To: <41F09480.8010707@sun.com> References: <41F09480.8010707@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Brian Haberman Date: Fri, 21 Jan 2005 09:43:42 -0500 To: Erik Nordmark 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> Phishing:<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: 0cff8c3ec906d056784362c06f5f88c1 Cc: Thomas Narten , Margaret Wasserman , IPv6 Subject: Re: Request to Advance: [RESEND] 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="===============1448137283==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb --===============1448137283== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--837596550; protocol="application/pkcs7-signature" --Apple-Mail-2--837596550 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Erik, On Jan 21, 2005, at 0:34, Erik Nordmark wrote: > > Hello Brian, > >> For the most part, there has been less than optimal public >> discussion. The minutes from Seoul indicate that Thomas was less than >> happy with the level of comments. However, the people who did speak >> up were in favor of it. > > Hmm - I'm spoken up in more than one IPv6 WG meeting pointing out the > flaws in the protocol. So clearly all people that spoke up were not in > favor of it. I misspoke. Most people who spoke up were in favor. The last comments I see from you in the meeting minutes are from IETF 57. > > I take it from your detailed responses below that you see it in IETF's > best interest to publish this document and protocol without any quality > improvements to neither the document nor the protocol. Did I understand > that correctly? I never said that. I was commenting on the very broad brush you were painting with. If there are things that can be changed to improve a spec, they should be considered. In this particular case, it appears that the supporters of the spec are limiting the deployment scenarios. With those limitations, I am not sure that SeND would be used in concert with proxy ND. > >> I think that saying it harms the Internet is a little broad. The use >> cases for proxynd is more at the edge. Loops will be localized and >> shouldn't bring the whole Internet down. > > I suspect the users that will have their "measly" edge networks melt > down would disagree with this; the harm doesn't have to make everything > melt at once for it to be a harmful thing AFAIK. First, lets keep in mind that this is an Informational document. I don't see it as the eventual solution for the problem space. Secondly, I see proxy ND being used in very small, cost-constrained networks. Something where a router is over-kill. > >> - Another form of potential harm is creating obstacles for deployment >> of Secure Neighbor Discovery. The protocol does not work in >> conjunction with SeND, which is particularely odd since section 3 >> explicitly lists this as a requirement. (The line of reasons seems to >> be that it is a fault of SeND that proxynd doesn't work when SeND is >> used, which is a bit odd.) >> The security section points out, correctly, that 2461 supports >> proxying and that SeND doesn't support it. In addition, the scenarios >> supported by proxynd don't seem to be the same as those where SeND >> would be used. > > Yes, but as I stated above, section 3 explicitly says that working with > SeND is a requirement for proxynd. And then the protocol doesn't > satisfy > that. Given that the protocol doesn't satisfy what the document itself > says are the requirements, the document (and perhaps the protocol as > well) has a quality problem by being self-inconsistent. I will admit to missing the stated requirement in to support SeND. The Security Considerations section spells out how SeND does not work with the existing proxy text in 2461. That, to me, made interoperating with SeND a non-requirement. > >> Note that if there is sufficient interest in the WG, it isn't hard to >> solve the two technical issues listed above. (But the SeND >> interaction would require the proxies to be able to be promiscious >> receivers, which might be problematic in the wireless upstream >> scenario). >> Agree that may be an issue. The question is whether SeND would be >> used in that scenario. > > The counterexample is that there are ISPs that have their home users > with 802.11 run public hotspots and get some compensation from the > ISP. In this case, since it is a public access 802.11, SeND would be a > good thing to use. And 802.11 is also a key scenario for proxynd. This is the first I have ever heard of that particular scenario. > > >> There is at least one other listed requirement which the protocol >> doesn't seem to satisfy: - Allow dynamic removal of a proxy without >> adversly disrupting the network Since there will be host which have >> the, now dead, proxy's link layer address in their ARP/ND cache, >> communication will fail until this stale information is flushed, >> which might take a minute or so. That seems like an adverse impact on >> the network too me. >> Agree that removal of a proxy, or the loss of a proxy, could >> adversely affect the network. However, this seems equivalent to a >> network failure or re-design and not an everyday activity. > > Again, the issue is the self-inconsistency in the document/protocol. > Section 3 says that dynamic removal of a proxy should adversely > disrupt the network. Yet the protocol doesn't satisfy this requirement > as far as I can see. > At this point, I think it would be useful if the supporters of this document chimed in on these issues. Regards, Brian --Apple-Mail-2--837596550 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTIxMTQ0MzQyWjAjBgkqhkiG9w0B CQQxFgQU9ULgqB4Fr/deN9T8FZ8jKxX8l30weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAWYiBXpxdVCPSh9/dhuHUE5/hWDkhdmIqsM79CGCKkbDs/DxU6yQ1YPcversd8i/jn7qP ZS4Ki1SbrbhaTnkhG+Q8RIxyjXBvY6C6+0m5+AmE+0kH0iC9g2tew3QvbIsMB803Z7PvTwKJYVJB qcrXNQ0f3wymXXFtgh81OJn5YYXe4prKW2CRsHM1MPwn+yzS0O8+Ld6TrukSJxbMMQ6wMSIyfAJA TKiIPLOAKWkn6XJWMRAY/VtP3uh1AwZIks0QPmZlXmOq7Pq20vXilBLU3b7gkkd6Wm66/F8nyOZt 6uhlKzMaJym0oAdxzDIKFDfJCId3OghjJSpMkUc7QBBPEwAAAAAAAA== --Apple-Mail-2--837596550-- --===============1448137283== 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 -------------------------------------------------------------------- --===============1448137283==-- From ipv6-bounces@ietf.org Fri Jan 21 11:44:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25838 for ; Fri, 21 Jan 2005 11:44:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs29w-0000jY-0L for ipv6-web-archive@ietf.org; Fri, 21 Jan 2005 12: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 1Cs1lM-0000eO-NX; Fri, 21 Jan 2005 11:35:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1Wn-0004vv-Hl for ipv6@megatron.ietf.org; Fri, 21 Jan 2005 11:20: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 LAA23774 for ; Fri, 21 Jan 2005 11:20:51 -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 1Cs1mh-0008NY-BZ for ipv6@ietf.org; Fri, 21 Jan 2005 11:37:20 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.7843645; Fri, 21 Jan 2005 11:19:57 -0500 In-Reply-To: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Fri, 21 Jan 2005 11:19:56 -0500 To: IPv6 WG 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> Phishing:<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: Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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="===============0341262655==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 --===============0341262655== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--831822451; protocol="application/pkcs7-signature" --Apple-Mail-3--831822451 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This Last Call ended yesterday with no comments. At a minimum, I would like to hear from those people who commented previously whether or not this version satisfies their concerns. Regards, Brian On Jan 6, 2005, at 15:47, Brian Haberman wrote: > All, > This starts an IPv6 WG Last Call on advancing: > > Title : Optimistic Duplicate Address Detection for IPv6 > Author(s) : N. Moore > Filename : draft-ietf-ipv6-optimistic-dad-03.txt > Pages : 17 > Date : 2005-1-3 > > as a Proposed Standard. This last call will end on Jan 20, 2005. > Substantive comments should be directed to the IPv6 WG mailing > list. Editorial comments can be sent to the list or the document > editor. > > Regards, > Bob & Brian > IPv6 WG co-chairs > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-3--831822451 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTIxMTYxOTU2WjAjBgkqhkiG9w0B CQQxFgQUgwjC7V4Yv/ZtLwvNQX5OjpFFg6wweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAhNJpf+0q+K2JJesnIw19iGc1ecEbj5m0WGlmep97bnGb0sK8C6NPrmPIKMXc0ExoEeSv OdLFF6Plji/t4NY9FQ/01r/PFaoEhm9jzKmpolq5jdxFoBQ0ApTXf9BQ7oDxPV7rtf52w7vAd2pO Wx/sp4E7n2dgWd42ieBnN/afR+LxmikP88sI1Xoq5j+lwn051w/mMwGR/Ua4nl5jDzoDO0vGolBB gGhwwc/yDI5i12AABC/ZirTq+himYe4h+ouedbbA2Zvc4X0nMIYjGpN1PrlVGVKVrxJGQDGZFSyM WWXaLFmuC6qNUbJ6hw6TjjZ+gG4EMllhqc/9kFEL3lRDwQAAAAAAAA== --Apple-Mail-3--831822451-- --===============0341262655== 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 -------------------------------------------------------------------- --===============0341262655==-- From ipv6-bounces@ietf.org Fri Jan 21 12:21:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28776 for ; Fri, 21 Jan 2005 12:21:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2jB-0001lL-H8 for ipv6-web-archive@ietf.org; Fri, 21 Jan 2005 12:37:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2GN-0007rT-0Q; Fri, 21 Jan 2005 12:07:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs26E-0006FJ-B3 for ipv6@megatron.ietf.org; Fri, 21 Jan 2005 11: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 LAA27305 for ; Fri, 21 Jan 2005 11:57:27 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2M8-000191-1Y for ipv6@ietf.org; Fri, 21 Jan 2005 12:13:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0LGuam22168; Fri, 21 Jan 2005 18:56:41 +0200 Date: Fri, 21 Jan 2005 18:56:36 +0200 (EET) From: Pekka Savola To: CTO YAN Renxiang In-Reply-To: <9570C1261494D54D9D3115BC2C83429A0BB696@asbmail2.sbell.com.cn> Message-ID: References: <9570C1261494D54D9D3115BC2C83429A0BB696@asbmail2.sbell.com.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org Subject: Re: new draft (ietf-yan-ipv6-ra-dns-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 Hi, On Fri, 21 Jan 2005, CTO YAN Renxiang wrote: > I've written a new individual submissions: > http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt > > Abstract: > This document specifies a method to update domain name for IPv6 node > whose address is configured using IPv6 stateless address > configuration. It is implemented by defining a new option in > Router Advertisement (RA) / Router Solicitation (RS) messages. > > Please take a look at it and provide comments. I'd like to request this to become > IPv6 WG work items. This should probably be brought up in DNSOP mailing list as well. http://www.ietf.org/html.charters/dnsop-charter.html You may also want to take a look at sections 6 and 7 of draft-ietf-dnsop-ipv6-dns-issues-10.txt and reflect how that fits there. -- 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 Fri Jan 21 13:19:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03187 for ; Fri, 21 Jan 2005 13:19:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3dr-0003PV-Mm for ipv6-web-archive@ietf.org; Fri, 21 Jan 2005 13:36:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3MI-0000aK-6z; Fri, 21 Jan 2005 13:18:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3J2-00082K-UY for ipv6@megatron.ietf.org; Fri, 21 Jan 2005 13:14: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 NAA02740 for ; Fri, 21 Jan 2005 13:14:46 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3Yx-0003Fg-I9 for ipv6@ietf.org; Fri, 21 Jan 2005 13:31:17 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0LIEdl02912 for ; Fri, 21 Jan 2005 20:14:45 +0200 (EET) X-Scanned: Fri, 21 Jan 2005 20:23:35 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0LINZYe022296 for ; Fri, 21 Jan 2005 20:23:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00byQ63Z; Fri, 21 Jan 2005 20:23:13 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0LIDGU11815 for ; Fri, 21 Jan 2005 20:13:16 +0200 (EET) Received: from l5131412.nokia.com ([10.241.50.43]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 Jan 2005 20:13:14 +0200 Message-Id: <6.1.2.0.2.20050121101117.033c3480@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 21 Jan 2005 10:13:11 -0800 To: IPv6 WG From: ietf-secretariat@ietf.org (by way of Bob Hinden ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Jan 2005 18:13:14.0885 (UTC) FILETIME=[DFFEA350:01C4FFE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting in Minneapolis, MN 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 There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET, but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 23 00:10:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04561 for ; Sun, 23 Jan 2005 00:10:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsaHe-0006oZ-Vj for ipv6-web-archive@ietf.org; Sun, 23 Jan 2005 00:27:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsZv8-0005EM-CJ; Sun, 23 Jan 2005 00:04:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsZsD-0004i5-Ty for ipv6@megatron.ietf.org; Sun, 23 Jan 2005 00:01: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 AAA04071 for ; Sun, 23 Jan 2005 00:01:14 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csa8Q-0006c7-Rx for ipv6@ietf.org; Sun, 23 Jan 2005 00:18:04 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 6F322694 for ; Sun, 23 Jan 2005 00:00:40 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 23 Jan 2005 00:00:40 -0500 Message-Id: <20050123050040.6F322694@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: 9466e0365fc95844abaf7c3f15a05c7d Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.88% | 7 | 32.02% | 64496 | brian@innovationslab.net 18.75% | 6 | 15.12% | 30457 | bob.hinden@nokia.com 12.50% | 4 | 9.44% | 19013 | ipng@69706e6720323030352d30312d31340a.nosense.org 6.25% | 2 | 7.52% | 15145 | brc@zurich.ibm.com 6.25% | 2 | 6.18% | 12446 | erik.nordmark@sun.com 6.25% | 2 | 5.72% | 11513 | stephen@sprunk.org 6.25% | 2 | 3.82% | 7703 | pekkas@netcore.fi 3.12% | 1 | 4.71% | 9495 | alh-ietf@tndh.net 3.12% | 1 | 3.39% | 6827 | renxiang.yan@alcatel-sbell.com.cn 3.12% | 1 | 2.96% | 5967 | internet-drafts@ietf.org 3.12% | 1 | 2.59% | 5210 | ietf-secretariat@ietf.org 3.12% | 1 | 2.53% | 5094 | elwynd@dial.pipex.com 3.12% | 1 | 2.17% | 4364 | yukiyo.akisada@jp.yokogawa.com 3.12% | 1 | 1.82% | 3670 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 32 |100.00% | 201400 | 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 Jan 23 02:42:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26576 for ; Sun, 23 Jan 2005 02:42:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsceI-0000l6-Vv for ipv6-web-archive@ietf.org; Sun, 23 Jan 2005 02:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CscLz-0007oY-68; Sun, 23 Jan 2005 02: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 1CscKw-0007ia-S2 for ipv6@megatron.ietf.org; Sun, 23 Jan 2005 02:39: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 CAA26436 for ; Sun, 23 Jan 2005 02:39:05 -0500 (EST) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CscbA-0000ih-Uf for ipv6@ietf.org; Sun, 23 Jan 2005 02:55:54 -0500 Received: (qmail 19388 invoked by uid 417); 23 Jan 2005 07:38:53 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 23 Jan 2005 07:38:53 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Sun, 23 Jan 2005 00:38:50 -0700 Message-ID: <001201c5011e$74f99ed0$6b081eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org, ipv6@ietf.org Date: Sun, 23 Jan 2005 09:37:55 +0200 MIME-Version: 1.0 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.6 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: White Paper - The Challenges of Next Generation IP Address Management 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="===============0092115919==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This is a multi-part message in MIME format. --===============0092115919== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C5012F.374497A0" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C5012F.374497A0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable (cross posted to IPv6 and V6 Ops) In case any of you would like to see how some of this is being = implemented here is a nice (free) white paper from Lucent (it is a = little vendor biased, but still valid). Eric The Challenges of Next Generation IP Address Management=20 The concept of managing two parallel IP spaces and the interaction = between them is somewhat foreign and comes with its own set of = complexities and challenges. This paper will address the challenges of = adopting IPv6, as well as managing, monitoring and streamlining your = next generation networks.=20 http://www.fattail.com/redir/redirect.asp?CID=3D94032 ------=_NextPart_000_000F_01C5012F.374497A0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

(cross posted to IPv6 and V6 Ops)

In case any of you would like to see how some of this is being = implemented=20 here is a nice (free) white paper from Lucent (it is a little = vendor=20 biased, but still valid).

Eric

The Challenges of Next Generation IP Address = Management

The concept of managing two parallel IP spaces and the interaction = between=20 them is somewhat foreign and comes with its own set of complexities and=20 challenges. This paper will address the challenges of adopting IPv6, as = well as=20 managing, monitoring and streamlining your next generation networks. =

http://www.fattail.com/redir/redirect.asp?CID=3D94032=

------=_NextPart_000_000F_01C5012F.374497A0-- --===============0092115919== 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 -------------------------------------------------------------------- --===============0092115919==-- From ipv6-bounces@ietf.org Mon Jan 24 05:28:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24324 for ; Mon, 24 Jan 2005 05:28:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct1iz-0006RW-7s for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 05: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 1Ct1Q2-00048U-3U; Mon, 24 Jan 2005 05:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct1PD-00042k-A0 for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 05:25: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 FAA24153 for ; Mon, 24 Jan 2005 05:25:08 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct1fg-0006KY-Q1 for ipv6@ietf.org; Mon, 24 Jan 2005 05:42:13 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0OAOZvU166796 for ; Mon, 24 Jan 2005 10:24:35 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0OAPZCB125242 for ; Mon, 24 Jan 2005 11:25:35 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0OAOZSf007086 for ; Mon, 24 Jan 2005 11:24:35 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0OAOYCe007062; Mon, 24 Jan 2005 11:24:34 +0100 Received: from zurich.ibm.com (sig-9-146-220-248.de.ibm.com [9.146.220.248]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA50122; Mon, 24 Jan 2005 11:24:33 +0100 Message-ID: <41F4CCDE.9040408@zurich.ibm.com> Date: Mon, 24 Jan 2005 11:24:30 +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: Brian Haberman References: <41F09480.8010707@sun.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: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , Erik Nordmark , IPv6 Subject: Re: Request to Advance: [RESEND] 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: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit > First, lets keep in mind that this is an Informational document. I wonder whether Experimental wouldn't send a clearer signal that there is some doubt about the viability of the solution. I can see how this could be very useful in certain types of network environment, and publishing as Experimental will allow people to share experience and try to fix the open questions. Since the deployment future of SEND is unknown, I don't think it's appropriate to block this work because of SEND. Brian Brian Haberman wrote: > Erik, > > On Jan 21, 2005, at 0:34, Erik Nordmark wrote: > >> >> Hello Brian, >> >>> For the most part, there has been less than optimal public >>> discussion. The minutes from Seoul indicate that Thomas was less than >>> happy with the level of comments. However, the people who did speak >>> up were in favor of it. >> >> >> Hmm - I'm spoken up in more than one IPv6 WG meeting pointing out the >> flaws in the protocol. So clearly all people that spoke up were not in >> favor of it. > > > I misspoke. Most people who spoke up were in favor. The last comments > I see from you in the meeting minutes are from IETF 57. > >> >> I take it from your detailed responses below that you see it in IETF's >> best interest to publish this document and protocol without any quality >> improvements to neither the document nor the protocol. Did I understand >> that correctly? > > > I never said that. I was commenting on the very broad brush you were > painting with. If there are things that can be changed to improve a spec, > they should be considered. In this particular case, it appears that the > supporters of the spec are limiting the deployment scenarios. With > those limitations, I am not sure that SeND would be used in concert with > proxy ND. > >> >>> I think that saying it harms the Internet is a little broad. The use >>> cases for proxynd is more at the edge. Loops will be localized and >>> shouldn't bring the whole Internet down. >> >> >> I suspect the users that will have their "measly" edge networks melt >> down would disagree with this; the harm doesn't have to make everything >> melt at once for it to be a harmful thing AFAIK. > > > First, lets keep in mind that this is an Informational document. I don't > see it as the eventual solution for the problem space. Secondly, > I see proxy ND being used in very small, cost-constrained networks. > Something where a router is over-kill. > >> >>> - Another form of potential harm is creating obstacles for deployment >>> of Secure Neighbor Discovery. The protocol does not work in >>> conjunction with SeND, which is particularely odd since section 3 >>> explicitly lists this as a requirement. (The line of reasons seems to >>> be that it is a fault of SeND that proxynd doesn't work when SeND is >>> used, which is a bit odd.) >>> The security section points out, correctly, that 2461 supports >>> proxying and that SeND doesn't support it. In addition, the scenarios >>> supported by proxynd don't seem to be the same as those where SeND >>> would be used. >> >> >> Yes, but as I stated above, section 3 explicitly says that working with >> SeND is a requirement for proxynd. And then the protocol doesn't satisfy >> that. Given that the protocol doesn't satisfy what the document itself >> says are the requirements, the document (and perhaps the protocol as >> well) has a quality problem by being self-inconsistent. > > > I will admit to missing the stated requirement in to support SeND. The > Security Considerations section spells out how SeND does not work > with the existing proxy text in 2461. That, to me, made interoperating > with SeND a non-requirement. > >> >>> Note that if there is sufficient interest in the WG, it isn't hard to >>> solve the two technical issues listed above. (But the SeND >>> interaction would require the proxies to be able to be promiscious >>> receivers, which might be problematic in the wireless upstream >>> scenario). >>> Agree that may be an issue. The question is whether SeND would be >>> used in that scenario. >> >> >> The counterexample is that there are ISPs that have their home users >> with 802.11 run public hotspots and get some compensation from the >> ISP. In this case, since it is a public access 802.11, SeND would be a >> good thing to use. And 802.11 is also a key scenario for proxynd. > > > This is the first I have ever heard of that particular scenario. > >> >> >>> There is at least one other listed requirement which the protocol >>> doesn't seem to satisfy: - Allow dynamic removal of a proxy without >>> adversly disrupting the network Since there will be host which have >>> the, now dead, proxy's link layer address in their ARP/ND cache, >>> communication will fail until this stale information is flushed, >>> which might take a minute or so. That seems like an adverse impact on >>> the network too me. >>> Agree that removal of a proxy, or the loss of a proxy, could >>> adversely affect the network. However, this seems equivalent to a >>> network failure or re-design and not an everyday activity. >> >> >> Again, the issue is the self-inconsistency in the document/protocol. >> Section 3 says that dynamic removal of a proxy should adversely >> disrupt the network. Yet the protocol doesn't satisfy this requirement >> as far as I can see. >> > > At this point, I think it would be useful if the supporters of this > document > chimed in on these issues. > > Regards, > 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 Mon Jan 24 06:23:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27528 for ; Mon, 24 Jan 2005 06:23:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct2aA-0007nj-77 for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 06:40:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct2HE-0006uM-AE; Mon, 24 Jan 2005 06:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct2Go-0006pm-M9 for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 06:20: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 GAA27331 for ; Mon, 24 Jan 2005 06:20:31 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct2XJ-0007ib-4o for ipv6@ietf.org; Mon, 24 Jan 2005 06:37:37 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0OBKKc17892; Mon, 24 Jan 2005 13:20:23 +0200 (EET) X-Scanned: Mon, 24 Jan 2005 13:09:08 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0OB98hv008342; Mon, 24 Jan 2005 13:09:08 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00eOeF3P; Mon, 24 Jan 2005 13:07:52 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0OB7qx06444; Mon, 24 Jan 2005 13:07:52 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 Jan 2005 13:03:20 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 Jan 2005 13:03:20 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 Jan 2005 13:03:19 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Jan 2005 13:03:19 +0200 Message-ID: Thread-Topic: Request to Advance: [RESEND] Thread-Index: AcUCA3Sk52Twq/tVRRGBIxUCj6WMEgAAMWgg To: , X-OriginalArrivalTime: 24 Jan 2005 11:03:19.0525 (UTC) FILETIME=[50005150:01C50204] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: narten@us.ibm.com, margaret@thingmagic.com, erik.nordmark@sun.com, ipv6@ietf.org Subject: RE: Request to Advance: [RESEND] 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Brian H, > > First, lets keep in mind that this is an Informational document. >=20 > I wonder whether Experimental wouldn't send a clearer signal > that there is some doubt about the viability of the solution. >=20 > I can see how this could be very useful in certain types of > network environment, and publishing as Experimental will allow > people to share experience and try to fix the open questions. >=20 > Since the deployment future of SEND is unknown, I don't think > it's appropriate to block this work because of SEND. I agree with Brian C.; I think epxerimental might be appropriate=20 for this. =20 John=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 24 11:55:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29414 for ; Mon, 24 Jan 2005 11:55:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7ld-00035k-2P for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 12:12:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7Kd-0006UP-0T; Mon, 24 Jan 2005 11:44:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7GP-0005ky-Rf for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 11:40: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 LAA28328 for ; Mon, 24 Jan 2005 11:40:26 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7Ww-0002UP-1c for ipv6@ietf.org; Mon, 24 Jan 2005 11:57:35 -0500 Received: from ocean.jinmei.org (PPP277.air128.dti.ne.jp [210.170.213.48]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8205215210; Tue, 25 Jan 2005 01:40:07 +0900 (JST) Date: Tue, 25 Jan 2005 01:40:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Bob Hinden , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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: 7baded97d9887f7a0c7e8a33c2e3ea1b >>>>> On Fri, 21 Jan 2005 11:19:56 -0500, >>>>> Brian Haberman said: > This Last Call ended yesterday with no comments. At a minimum, > I would like to hear from those people who commented previously > whether or not this version satisfies their concerns. I think I should have responded during the LC period...sorry for my poor response. I've checked the latest version, and I basically have no objection to submitting this document. I have one additional question specific to the latest version. This one has a new requirement on SEND in section 3.1: * Nodes implementing Optimistic DAD SHOULD additionally implement Secure Neighbor Discovery [SEND]. I don't recall why this was added, but if this is based on a consensus, I don't oppose to the requirement itself. However, I believe if we use this wording with the SHOULD, the reference to SEND must be a normative reference (even though the word "additionally" might weaken the requirement level). Upgrading the reference won't become a procedural problem, since the SEND spec is already in the RFC editor queue and both documents will become a PS. In any event, this is not a strong opinion. If others think it's okay to keep it as an informative reference, I can live with that. Also, even if we agree on changing the reference category, I think we can do that later with IESG 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 Mon Jan 24 13:40:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10233 for ; Mon, 24 Jan 2005 13:40:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9P0-0007T5-Hq for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 13:57:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8yA-0007Gu-AW; Mon, 24 Jan 2005 13:29:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8vS-0006Qh-6b for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 13:26: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 NAA09049 for ; Mon, 24 Jan 2005 13:26:54 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9Bv-0006sb-3P for ipv6@ietf.org; Mon, 24 Jan 2005 13:44:04 -0500 Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j0OIQopv025423; Mon, 24 Jan 2005 10:26:50 -0800 (PST) Received: from [129.146.89.81] (bobo.SFBay.Sun.COM [129.146.89.81]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0OIQnXG976071; Mon, 24 Jan 2005 10:26:49 -0800 (PST) Message-ID: <41F52FB3.5020204@sun.com> Date: Mon, 24 Jan 2005 09:26:11 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter References: <41F09480.8010707@sun.com> <41F4CCDE.9040408@zurich.ibm.com> In-Reply-To: <41F4CCDE.9040408@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , Brian Haberman , IPv6 Subject: Re: Request to Advance: [RESEND] 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 Brian E Carpenter wrote: > > First, lets keep in mind that this is an Informational document. > > I wonder whether Experimental wouldn't send a clearer signal > that there is some doubt about the viability of the solution. That would be better than informational. But I still think the document should say "MUST prevent loops; SHOULD run IEEE 802.1D to prevent loops" and then talk about cases when the protocol is not needed. The one example we have is the case of PPP (e.g. to a GGSN) where the probability of a loop would be very small, so in that particular case there is no need for 802.1D (and there might be other examples, but the 802.11 scenario in the document isn't one of them). > I can see how this could be very useful in certain types of > network environment, and publishing as Experimental will allow > people to share experience and try to fix the open questions. ok > Since the deployment future of SEND is unknown, I don't think > it's appropriate to block this work because of SEND. Yes, but at least the document should be internally inconsistent and not claim in section 3 that working with SeND is a requirement, even though it doesn't work with SeND. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 24 13:54:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11558 for ; Mon, 24 Jan 2005 13:54:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9ct-00081M-5v for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 14:11:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9Cb-0001sQ-2R; Mon, 24 Jan 2005 13:44:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct97Y-0000dj-KI for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 13:39: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 NAA10156 for ; Mon, 24 Jan 2005 13:39:27 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9O5-0007Om-QH for ipv6@ietf.org; Mon, 24 Jan 2005 13:56:35 -0500 Received: from jurassic.eng.sun.com ([129.146.89.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j0OIdOiI018791; Mon, 24 Jan 2005 10:39:24 -0800 (PST) Received: from [129.146.89.81] (bobo.SFBay.Sun.COM [129.146.89.81]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0OIdOq3979572; Mon, 24 Jan 2005 10:39:24 -0800 (PST) Message-ID: <41F532A6.1080809@sun.com> Date: Mon, 24 Jan 2005 09:38:46 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <41F09480.8010707@sun.com> 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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , IPv6 Subject: Re: Request to Advance: [RESEND] 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 Brian Haberman wrote: >> I take it from your detailed responses below that you see it in IETF's >> best interest to publish this document and protocol without any quality >> improvements to neither the document nor the protocol. Did I understand >> that correctly? > > > I never said that. I was commenting on the very broad brush you were > painting with. If there are things that can be changed to improve a spec, > they should be considered. In this particular case, it appears that the > supporters of the spec are limiting the deployment scenarios. With > those limitations, I am not sure that SeND would be used in concert with > proxy ND. You say that, yet you fail to respond to my comment that the 802.11 scenario in the document is a case where this might be used and there is also a desire to use SeND. > First, lets keep in mind that this is an Informational document. I don't > see it as the eventual solution for the problem space. Secondly, I think INFO documents produced by IETF WGs should have "truth in advertising", so I don't buy the claim that the document can be silent on the dangers of loops, and misleading (internally inconsistent) on whether it works in the presence of SeND. > I see proxy ND being used in very small, cost-constrained networks. > Something where a router is over-kill. Unfortunately, there are many times when the IETF has created a protocol intending it to be used in a limited environment, where the generality of IP has resulted in it being more widely deployed. The IETF tries to avoid this (for example, see the security requirements for IP Storage, where the original argument was that it would be used in a limited local environment, hence no need for things like IPsec), by requiring that protocols not cause harm should they be deployed much more widely than the designers anticipated. > I will admit to missing the stated requirement in to support SeND. The > Security Considerations section spells out how SeND does not work > with the existing proxy text in 2461. That, to me, made interoperating > with SeND a non-requirement. So now you understand the issue. I suspect that the requirement should effect how a protocol is designed, as opposed to creating requirements which are the things that the artifact is capable of supporting. But as I said to Brian, in this case the issue is to make the document clear what it supports and doesn't support, with some explicit warnings that it can't be deployed in conjunction with SeND. >> The counterexample is that there are ISPs that have their home users >> with 802.11 run public hotspots and get some compensation from the >> ISP. In this case, since it is a public access 802.11, SeND would be a >> good thing to use. And 802.11 is also a key scenario for proxynd. > > > This is the first I have ever heard of that particular scenario. And Jim Kempf said, it's being deployed that way. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 24 15:01:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17283 for ; Mon, 24 Jan 2005 15:01:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAfC-0002Bg-6e for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 15:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAGY-0000EW-1j; Mon, 24 Jan 2005 14:52:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtADO-000848-4j for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 14:49: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 OAA16470 for ; Mon, 24 Jan 2005 14:49:31 -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 1CtATt-0001jM-NE for ipv6@ietf.org; Mon, 24 Jan 2005 15:06:41 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.12194684; Mon, 24 Jan 2005 14:48:23 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Brian Haberman Date: Mon, 24 Jan 2005 14:48:23 -0500 To: john.loughney@nokia.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: narten@us.ibm.com, margaret@thingmagic.com, erik.nordmark@sun.com, ipv6@ietf.org, brc@zurich.ibm.com Subject: Re: Request to Advance: [RESEND] 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="===============1542293647==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============1542293647== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--560115277; protocol="application/pkcs7-signature" --Apple-Mail-8--560115277 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jan 24, 2005, at 6:03, john.loughney@nokia.com wrote: > Brian H, > >>> First, lets keep in mind that this is an Informational document. >> >> I wonder whether Experimental wouldn't send a clearer signal >> that there is some doubt about the viability of the solution. >> >> I can see how this could be very useful in certain types of >> network environment, and publishing as Experimental will allow >> people to share experience and try to fix the open questions. >> >> Since the deployment future of SEND is unknown, I don't think >> it's appropriate to block this work because of SEND. > > I agree with Brian C.; I think epxerimental might be appropriate > for this. > I have no issues with making it Experimental. I am still waiting for responses from proxy-nd supporters on Erik's initial set of comments. Regards, Brian --Apple-Mail-8--560115277 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTI0MTk0ODIzWjAjBgkqhkiG9w0B CQQxFgQUaDiZup82ZFaAPRDcBMoFzYIrIugweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAww2Y7l/8TIVd+PODF4jl8UMKcGPHutvlCJXUH5FsbAh6rjl1ZrMz3iz+27kkQNUseaPF vtnIjwkGl5CTuTky19MZtdUQuFPmJGF8nwc0ieE/zxAkI9Gyg82UZFTEwNeeEFFNF6Nm4GoyZc6u vqpkd//O+r4Zz/dsotOwUDgFCfdeHt34bpnvZ9JAVGSfGv7uQ/o2dBS1611x48WyvuloKeC6RFo/ n1ABXFyPEGIdOjKBM7pwDze/xLVUVXQBqCCykgiTu/VhtfbXMAluQMMZp2YwaymsU5BMyO4uH73G LeHcRBvlmABrzYFOG7wcfwr6nfKQ2uiZg0mNA3XTcAQiuAAAAAAAAA== --Apple-Mail-8--560115277-- --===============1542293647== 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 -------------------------------------------------------------------- --===============1542293647==-- From ipv6-bounces@ietf.org Mon Jan 24 15:36:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21046 for ; Mon, 24 Jan 2005 15:36:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBDQ-0003RF-L6 for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 15:53:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtApO-0002ao-Qo; Mon, 24 Jan 2005 15:28:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAkt-0000BB-OW for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 15:24: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 PAA20319 for ; Mon, 24 Jan 2005 15:24:07 -0500 (EST) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtB1N-000346-HV for ipv6@ietf.org; Mon, 24 Jan 2005 15:41:17 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 55C22700814; Tue, 25 Jan 2005 07:23:48 +1100 (EST) Date: Tue, 25 Jan 2005 07:23:48 +1100 From: "Nick 'Sharkey' Moore" To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20050124202347.GA22574@zoic.org> Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , ipv6@ietf.org References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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: 69a74e02bbee44ab4f8eafdbcedd94a1 On 2005-01-25, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > I think I should have responded during the LC period...sorry for my > poor response. I've checked the latest version, and I basically have > no objection to submitting this document. Thanks, I was pretty sure you'd be happy since the last version was 99% there ... > I have one additional question specific to the latest version. This > one has a new requirement on SEND in section 3.1: > > * Nodes implementing Optimistic DAD SHOULD additionally implement > Secure Neighbor Discovery [SEND]. > > I don't recall why this was added, but if this is based on a > consensus, I don't oppose to the requirement itself. However, I > believe if we use this wording with the SHOULD, the reference to SEND > must be a normative reference (even though the word "additionally" > might weaken the requirement level). It's just there to address security considerations ... you're right, it should have been upgraded to a normative reference, I missed that. > In any event, this is not a strong opinion. If others think it's okay > to keep it as an informative reference, I can live with that. Also, > even if we agree on changing the reference category, I think we can do > that later with IESG comments. Yep. Thanks for your feedback on this and previous versions! -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 24 16:11:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27693 for ; Mon, 24 Jan 2005 16:11:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBlb-0005tL-2L for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 16:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB2q-0000KN-4X; Mon, 24 Jan 2005 15:42:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAzv-0007Yg-TW; Mon, 24 Jan 2005 15:39:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21365; Mon, 24 Jan 2005 15:39:41 -0500 (EST) Message-Id: <200501242039.PAA21365@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, 24 Jan 2005 15:39:41 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-09.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: 8de5f93cb2b4e3bee75302e9eacc33db --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 : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-addr-09.txt Pages : 19 Date : 2005-1-24 This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-09.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-unique-local-addr-09.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-unique-local-addr-09.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: <2005-1-24154124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unique-local-addr-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-24154124.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 Jan 24 16:51:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05038 for ; Mon, 24 Jan 2005 16:51:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCNo-0000JK-KW for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 17:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBwD-0004TT-RV; Mon, 24 Jan 2005 16:39:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBji-0004D9-0V for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 16:27: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 QAA01125 for ; Mon, 24 Jan 2005 16:26:58 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC0G-0007Fy-9S for ipv6@ietf.org; Mon, 24 Jan 2005 16:44:09 -0500 Message-ID: <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Erik Nordmark" , "Brian Haberman" References: <41F09480.8010707@sun.com> <41F532A6.1080809@sun.com> Date: Mon, 24 Jan 2005 13:27:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , IPv6 Subject: Re: Request to Advance: [RESEND] 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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit > >> The counterexample is that there are ISPs that have their home users > >> with 802.11 run public hotspots and get some compensation from the > >> ISP. In this case, since it is a public access 802.11, SeND would be a > >> good thing to use. And 802.11 is also a key scenario for proxynd. > > > > > > This is the first I have ever heard of that particular scenario. > > And Jim Kempf said, it's being deployed that way. > > Erik > specifically, speakeasy has a program listed on their web site where you get credits for routing your neighbor's traffic through your .11 ap. perhaps other isps too? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 24 18:32:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17655 for ; Mon, 24 Jan 2005 18:32:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDxf-0005Fe-Kj for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 18:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDX9-0005ad-Su; Mon, 24 Jan 2005 18:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDQu-0008H4-7C for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 18:15: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 SAA15436 for ; Mon, 24 Jan 2005 18:15:40 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDhT-0004QO-Ma for ipv6@ietf.org; Mon, 24 Jan 2005 18:32:52 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1E393898A4; Tue, 25 Jan 2005 01:15:10 +0200 (EET) Message-ID: <41F58141.7060504@kolumbus.fi> Date: Tue, 25 Jan 2005 01:14:09 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark References: <41F09480.8010707@sun.com> <41F4CCDE.9040408@zurich.ibm.com> <41F52FB3.5020204@sun.com> In-Reply-To: <41F52FB3.5020204@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Brian E Carpenter , IPv6 Subject: Re: Request to Advance: [RESEND] 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: 7bit Erik Nordmark wrote: >> I wonder whether Experimental wouldn't send a clearer signal >> that there is some doubt about the viability of the solution. > > That would be better than informational. I agree. But I also think that if the document has inconsistencies those should be corrected even before publishing it as experimental. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 24 18:48:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19236 for ; Mon, 24 Jan 2005 18:48:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtED0-0005sl-UW for ipv6-web-archive@ietf.org; Mon, 24 Jan 2005 19:05:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDsh-00054z-Pz; Mon, 24 Jan 2005 18:44:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDmc-0003CZ-BX for ipv6@megatron.ietf.org; Mon, 24 Jan 2005 18:38:10 -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 SAA18217 for ; Mon, 24 Jan 2005 18:38:07 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtE3C-0005Tl-IB for ipv6@ietf.org; Mon, 24 Jan 2005 18:55:19 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Jan 2005 15:43:15 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0ONbZM8006210 for ; Mon, 24 Jan 2005 15:37:36 -0800 (PST) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-144.cisco.com [10.21.96.144]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOO33333; Mon, 24 Jan 2005 18:37:34 -0500 (EST) Message-Id: <4.3.2.7.2.20050124183549.02013ab8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jan 2005 18:37:31 -0500 To: From: Ralph Droms In-Reply-To: <41F58141.7060504@kolumbus.fi> References: <41F52FB3.5020204@sun.com> <41F09480.8010707@sun.com> <41F4CCDE.9040408@zurich.ibm.com> <41F52FB3.5020204@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: Request to Advance: [RESEND] 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 I apologize if I've missed this particular point earlier in the discussion - Experimental seems appropriate to me unless there is widespread deployment of some version of the protocol that this document is specifying. And I agree about correcting any inconsistencies prior to publication... - Ralph At 01:14 AM 1/25/2005 +0200, Jari Arkko wrote: >Erik Nordmark wrote: > >>>I wonder whether Experimental wouldn't send a clearer signal >>>that there is some doubt about the viability of the solution. >>That would be better than informational. > >I agree. But I also think that if the document has >inconsistencies those should be corrected even before >publishing it as experimental. > >--Jari > >-------------------------------------------------------------------- >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 Jan 25 16:51:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14023 for ; Tue, 25 Jan 2005 16:51:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtYrv-0002ON-Bz for ipv6-web-archive@ietf.org; Tue, 25 Jan 2005 17:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtYGJ-0002v0-1W; Tue, 25 Jan 2005 16:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtXtP-0006sL-8N for ipv6@megatron.ietf.org; Tue, 25 Jan 2005 16:06: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 QAA07778 for ; Tue, 25 Jan 2005 16:06: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 1CtYAA-0008EN-NI for ipv6@ietf.org; Tue, 25 Jan 2005 16:23:52 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:f48a:d969:a943:c365]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 206FB15210; Wed, 26 Jan 2005 06:06:05 +0900 (JST) Date: Wed, 26 Jan 2005 06:06:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: <6.2.0.14.0.20050112090031.01e8c270@imap.dial.pipex.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: 8abaac9e10c826e8252866cbe6766464 Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: ICMPv6 Source Address Determination - Paranoid catch all? 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: 69a74e02bbee44ab4f8eafdbcedd94a1 >>>>> On Wed, 12 Jan 2005 12:06:44 +0200 (EET), >>>>> Pekka Savola said: >> On the other hand, not implementing (c) could lead to situations where using >> (d) could result in the ICMPv6 message having a link local address as source >> if the interface itself only has a link local address. This is OK for >> neighbor discovery where everything is link local but less so for an ICMPv6 >> message that came from outside the local link. > In that case, I guess (d) would have to be reworded to better match > reality, for example, from: > (d) Otherwise, the node's routing table must be examined to > determine which interface will be used to transmit the message > to its destination, and a unicast address belonging to that > interface MUST be used as the Source Address of the message. > to: > (d) Otherwise, the source address is determined by the same > way as for any other packet the node originates. I tend to agree with removing 2.2(c) and with the revised text. And, FWIW, in some recent versions of the KAME implementation we apply the default address selection rule defined in RFC3484 in case of 2.2 (d), partly because the resulting source address(es) would be more deterministic. 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 Jan 25 19:40:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00975 for ; Tue, 25 Jan 2005 19:40:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtbVi-0000kC-7Y for ipv6-web-archive@ietf.org; Tue, 25 Jan 2005 19:58:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctb8F-0000am-Fs; Tue, 25 Jan 2005 19:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctb2p-0007Eo-92 for ipv6@megatron.ietf.org; Tue, 25 Jan 2005 19:28: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 TAA00137 for ; Tue, 25 Jan 2005 19:28:24 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtbJc-0000LS-KW for ipv6@ietf.org; Tue, 25 Jan 2005 19:45:50 -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 j0Q0SKpv017567; Tue, 25 Jan 2005 16:28:20 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0Q0SI0r711048; Tue, 25 Jan 2005 16:28:19 -0800 (PST) Message-ID: <41F6E3FD.4010607@sun.com> Date: Tue, 25 Jan 2005 16:27:41 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf References: <41F09480.8010707@sun.com> <41F532A6.1080809@sun.com> <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> In-Reply-To: <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , Brian Haberman , IPv6 Subject: Re: Request to Advance: [RESEND] 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 Content-Transfer-Encoding: 7bit James Kempf wrote: > specifically, speakeasy has a program listed on their web site where you get > credits for routing your neighbor's traffic through your .11 ap. perhaps > other isps too? sonic.net is another case. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 25 23:59:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19714 for ; Tue, 25 Jan 2005 23:59:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtfXs-0000WI-3J for ipv6-web-archive@ietf.org; Wed, 26 Jan 2005 00:16:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtfFL-0007IG-95; Tue, 25 Jan 2005 23:57:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtfBQ-0006ji-JJ for ipv6@megatron.ietf.org; Tue, 25 Jan 2005 23:53: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 XAA19484 for ; Tue, 25 Jan 2005 23:53:33 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtfSG-0000O7-8M for ipv6@ietf.org; Wed, 26 Jan 2005 00:11:01 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0Q4rKO02181; Wed, 26 Jan 2005 06:53:21 +0200 (EET) X-Scanned: Wed, 26 Jan 2005 07:02:18 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0Q52I7b013969; Wed, 26 Jan 2005 07:02:18 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00cpjSG8; Wed, 26 Jan 2005 07:02:17 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0Q4qJx20587; Wed, 26 Jan 2005 06:52:19 +0200 (EET) Received: from l5131412.nokia.com ([10.162.14.93]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 Jan 2005 06:51:20 +0200 Message-Id: <6.1.2.0.2.20050125204826.032ef8a8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 25 Jan 2005 20:51:20 -0800 To: James Kempf From: Bob Hinden In-Reply-To: <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> References: <41F09480.8010707@sun.com> <41F532A6.1080809@sun.com> <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jan 2005 04:51:20.0445 (UTC) FILETIME=[AD9E7AD0:01C50362] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Thomas Narten , Margaret Wasserman , Brian Haberman , Erik Nordmark , IPv6 Subject: Re: Request to Advance: [RESEND] 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 James, >specifically, speakeasy has a program listed on their web site where you get >credits for routing your neighbor's traffic through your .11 ap. perhaps >other isps too? Thanks. Could supply a link to additional information on this? Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 26 04:29:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04463 for ; Wed, 26 Jan 2005 04:29:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctjlg-0007GI-HP for ipv6-web-archive@ietf.org; Wed, 26 Jan 2005 04:47:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtjQ5-000780-E9; Wed, 26 Jan 2005 04:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtjGE-0004iX-Rq for ipv6@megatron.ietf.org; Wed, 26 Jan 2005 04:14: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 EAA03536 for ; Wed, 26 Jan 2005 04:14:48 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtjX7-0006pS-0R for ipv6@ietf.org; Wed, 26 Jan 2005 04:32:17 -0500 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0Q9ECV8122428 for ; Wed, 26 Jan 2005 09:14:12 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 j0Q9DCo2031268 for ; Wed, 26 Jan 2005 10:13:12 +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 j0Q9DCsp005863 for ; Wed, 26 Jan 2005 10:13:12 +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 j0Q9DCI8005849 for ; Wed, 26 Jan 2005 10:13:12 +0100 Received: from zurich.ibm.com (sig-9-146-217-210.de.ibm.com [9.146.217.210]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA78970 for ; Wed, 26 Jan 2005 10:13:11 +0100 Message-ID: <41F75F27.6060401@zurich.ibm.com> Date: Wed, 26 Jan 2005 10:13: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: IPv6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Subject: A little piece of IPv6 makes full Standard status 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 fyi, this includes the IPv6 address format (obsoleting RFC 2732). Brian -------- Original Message -------- Subject: STD 66, RFC 3986 on Uniform Resource Identifier (URI): Generic Syntax Date: Tue, 25 Jan 2005 17:32:09 -0800 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. STD 66 RFC 3986 Title: Uniform Resource Identifier (URI): Generic Syntax Author(s): T. Berners-Lee, R. Fielding, L. Masinter Status: Standards Track Date: January 2005 Mailbox: timbl@w3.org, fielding@gbiv.com, LMM@acm.org Pages: 61 Characters: 141811 Updates: 1738 Obsoletes: 2732, 2396, 1808 I-D Tag: draft-fielding-uri-rfc2396bis-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. This is now a Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 26 05:10:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07046 for ; Wed, 26 Jan 2005 05:10:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtkP3-0008M7-OR for ipv6-web-archive@ietf.org; Wed, 26 Jan 2005 05:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctk02-0005dI-OA; Wed, 26 Jan 2005 05:02:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctg60-0005l8-K5 for ipv6@megatron.ietf.org; Wed, 26 Jan 2005 00:52: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 AAA22403 for ; Wed, 26 Jan 2005 00:52:01 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtgMo-0001ky-SQ for ipv6@ietf.org; Wed, 26 Jan 2005 01:09:30 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0Q5pudt000545; Tue, 25 Jan 2005 22:51:57 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0Q5puQp029433; Wed, 26 Jan 2005 00:51:56 -0500 (EST) From: Bill Sommerfeld To: Bob Hinden In-Reply-To: <6.1.2.0.2.20050125204826.032ef8a8@mailhost.iprg.nokia.com> References: <41F09480.8010707@sun.com> <41F532A6.1080809@sun.com> <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> <6.1.2.0.2.20050125204826.032ef8a8@mailhost.iprg.nokia.com> Content-Type: text/plain Message-Id: <1106718687.4566.5.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Wed, 26 Jan 2005 00:51:28 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 Jan 2005 05:02:08 -0500 Cc: Thomas Narten , Brian Haberman , James Kempf , IPv6 , Margaret Wasserman , Erik Nordmark Subject: Re: Request to Advance: [RESEND] 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 Tue, 2005-01-25 at 23:51, Bob Hinden wrote: > >specifically, speakeasy has a program listed on their web site where you get > >credits for routing your neighbor's traffic through your .11 ap. perhaps > >other isps too? > > Thanks. Could supply a link to additional information on this? http://www.speakeasy.net/netshare/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 26 05:35:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08634 for ; Wed, 26 Jan 2005 05:35:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctkmr-0000aV-0I for ipv6-web-archive@ietf.org; Wed, 26 Jan 2005 05:52:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtkRc-0003sR-TE; Wed, 26 Jan 2005 05:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtkJn-0002FM-OL for ipv6@megatron.ietf.org; Wed, 26 Jan 2005 05:22: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 FAA07718 for ; Wed, 26 Jan 2005 05:22:33 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctkag-0000Fq-8E for ipv6@ietf.org; Wed, 26 Jan 2005 05:40:03 -0500 Received: from [220.181.31.171] (helo=126.com) by mx2.foretec.com with smtp (Exim 4.24) id 1CtkJl-0008CH-33 for ipv6@ietf.org; Wed, 26 Jan 2005 05:22:33 -0500 Received: from home (unknown [218.88.101.170]) by smtp2 (Coremail) with SMTP id EwDjXkFv90FU4reo.1 for ; Wed, 26 Jan 2005 18:21:56 +0800 (CST) X-Originating-IP: [218.88.101.170] Date: Wed, 26 Jan 2005 18:25:25 +0800 From: "QinKe" To: "ipv6" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 4.8 (++++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: would you please send me a copy of draft-ietf-msec-mesp-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: 4.8 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Dear sir: Would you please send me a copy of draft-ietf-msec-mesp-01.txt ? Thank you a million! Best regards! QinKe 2005-1-26 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 26 11:47:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14779 for ; Wed, 26 Jan 2005 11:47:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctqax-0003kw-CW for ipv6-web-archive@ietf.org; Wed, 26 Jan 2005 12:04:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctq4W-0008DQ-RR; Wed, 26 Jan 2005 11:31:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctq1P-0006wK-69 for ipv6@megatron.ietf.org; Wed, 26 Jan 2005 11:27: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 LAA12707 for ; Wed, 26 Jan 2005 11:27:56 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtqIK-00037f-U3 for ipv6@ietf.org; Wed, 26 Jan 2005 11:45:30 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0QGRr821816; Wed, 26 Jan 2005 18:27:55 +0200 (EET) X-Scanned: Wed, 26 Jan 2005 18:34:05 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0QGY5qn017619; Wed, 26 Jan 2005 18:34:05 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00XIgnGM; Wed, 26 Jan 2005 18:32:57 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0QGMux01862; Wed, 26 Jan 2005 18:22:56 +0200 (EET) Received: from l5131412.nokia.com ([10.162.15.163]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 Jan 2005 18:19:07 +0200 Message-Id: <6.1.2.0.2.20050126081817.030817e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 26 Jan 2005 08:19:04 -0800 To: Brian E Carpenter From: Bob Hinden In-Reply-To: <41F75F27.6060401@zurich.ibm.com> References: <41F75F27.6060401@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jan 2005 16:19:07.0955 (UTC) FILETIME=[C2F8C830:01C503C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: IPv6 Subject: Re: A little piece of IPv6 makes full Standard status 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: 057ebe9b96adec30a7efb2aeda4c26a4 Brian, At 01:13 AM 01/26/2005, Brian E Carpenter wrote: >fyi, this includes the IPv6 address format (obsoleting RFC 2732). Cool! Maybe we should start thinking about moving more of IPv6 to Standard. Bob > Brian > >-------- Original Message -------- >Subject: STD 66, RFC 3986 on Uniform Resource Identifier (URI): >Generic Syntax >Date: Tue, 25 Jan 2005 17:32:09 -0800 >From: rfc-editor@rfc-editor.org >To: ietf-announce@ietf.org >CC: rfc-editor@rfc-editor.org > > >A new Request for Comments is now available in online RFC libraries. > > > STD 66 > RFC 3986 > > Title: Uniform Resource Identifier (URI): Generic Syntax > Author(s): T. Berners-Lee, R. Fielding, L. Masinter > Status: Standards Track > Date: January 2005 > Mailbox: timbl@w3.org, fielding@gbiv.com, LMM@acm.org > Pages: 61 > Characters: 141811 > Updates: 1738 > Obsoletes: 2732, 2396, 1808 > > I-D Tag: draft-fielding-uri-rfc2396bis-07.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt > > >A Uniform Resource Identifier (URI) is a compact sequence of >characters that identifies an abstract or physical resource. This >specification defines the generic URI syntax and a process for >resolving URI references that might be in relative form, along with >guidelines and security considerations for the use of URIs on the >Internet. The URI syntax defines a grammar that is a superset of all >valid URIs, allowing an implementation to parse the common >components of a URI reference without knowing the scheme-specific >requirements of every possible identifier. This specification does >not define a generative grammar for URIs; that task is performed by >the individual specifications of each URI scheme. > >This is now a Standard Protocol. > >This document specifies an Internet standards track protocol for the >Internet community, and requests discussion and suggestions for >improvements. Please refer to the current edition of the "Internet >Official Protocol Standards" (STD 1) for the standardization state >and status of this protocol. Distribution of this memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > > > > >-------------------------------------------------------------------- >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 Jan 26 11:50:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15238 for ; Wed, 26 Jan 2005 11:50:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtqeA-0003sz-I1 for ipv6-web-archive@ietf.org; Wed, 26 Jan 2005 12:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtqLJ-0007VU-4s; Wed, 26 Jan 2005 11:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctq79-0000V0-NX for ipv6@megatron.ietf.org; Wed, 26 Jan 2005 11:33: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 LAA13223 for ; Wed, 26 Jan 2005 11:33:52 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtqO5-0003I6-5g for ipv6@ietf.org; Wed, 26 Jan 2005 11:51:26 -0500 Message-ID: <03f501c503c4$f69720e0$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Bob Hinden" References: <41F09480.8010707@sun.com> <41F532A6.1080809@sun.com> <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> <6.1.2.0.2.20050125204826.032ef8a8@mailhost.iprg.nokia.com> Date: Wed, 26 Jan 2005 08:34:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , Brian Haberman , Erik Nordmark , IPv6 Subject: Re: Request to Advance: [RESEND] 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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit http://www.speakeasy.net/netshare/ jak ----- Original Message ----- From: "Bob Hinden" To: "James Kempf" Cc: "Erik Nordmark" ; "Brian Haberman" ; "Thomas Narten" ; "Margaret Wasserman" ; "IPv6" Sent: Tuesday, January 25, 2005 8:51 PM Subject: Re: Request to Advance: [RESEND] > James, > > >specifically, speakeasy has a program listed on their web site where you get > >credits for routing your neighbor's traffic through your .11 ap. perhaps > >other isps too? > > Thanks. Could supply a link to additional information on this? > > Bob > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 26 22:12:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22450 for ; Wed, 26 Jan 2005 22:12:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu0MS-0004mC-PB for ipv6-web-archive@ietf.org; Wed, 26 Jan 2005 22:30:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu030-0007Kg-LD; Wed, 26 Jan 2005 22:10:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu02c-00079Q-Jc for ipv6@megatron.ietf.org; Wed, 26 Jan 2005 22:09: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 WAA22284 for ; Wed, 26 Jan 2005 22:09:52 -0500 (EST) Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu0Je-0004i0-N3 for ipv6@ietf.org; Wed, 26 Jan 2005 22:27:31 -0500 Received: from [203.119.0.34] (wav34.apnic.net [203.119.0.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 0F315D5F2D; Thu, 27 Jan 2005 13:02:17 +1000 (EST) Message-ID: <41F85B63.3000400@apnic.net> Date: Thu, 27 Jan 2005 13:09:23 +1000 From: Paul Wilson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter References: <41F75F27.6060401@zurich.ibm.com> In-Reply-To: <41F75F27.6060401@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: A little piece of IPv6 makes full Standard status 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 It seems that sect 3.2.2 this RFC 3986 requires left padding of each 16-bit piece of an IPv6 address with "0" eg 0000::/16 is allowed but 0::/16 is not If so, that seems incompatible with some common usages, including many of those listed in sect 2 of RFC 2732. I note that the form "::192.9.5.5" also seems to be disallowed by the new RFC. Paul Wilson APNIC Brian E Carpenter wrote: > fyi, this includes the IPv6 address format (obsoleting RFC 2732). > > Brian > > -------- Original Message -------- > Subject: STD 66, RFC 3986 on Uniform Resource Identifier (URI): > Generic Syntax > Date: Tue, 25 Jan 2005 17:32:09 -0800 > From: rfc-editor@rfc-editor.org > To: ietf-announce@ietf.org > CC: rfc-editor@rfc-editor.org > > > A new Request for Comments is now available in online RFC libraries. > > > STD 66 > RFC 3986 > > Title: Uniform Resource Identifier (URI): Generic Syntax > Author(s): T. Berners-Lee, R. Fielding, L. Masinter > Status: Standards Track > Date: January 2005 > Mailbox: timbl@w3.org, fielding@gbiv.com, LMM@acm.org > Pages: 61 > Characters: 141811 > Updates: 1738 > Obsoletes: 2732, 2396, 1808 > > I-D Tag: draft-fielding-uri-rfc2396bis-07.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt > > > A Uniform Resource Identifier (URI) is a compact sequence of > characters that identifies an abstract or physical resource. This > specification defines the generic URI syntax and a process for > resolving URI references that might be in relative form, along with > guidelines and security considerations for the use of URIs on the > Internet. The URI syntax defines a grammar that is a superset of all > valid URIs, allowing an implementation to parse the common > components of a URI reference without knowing the scheme-specific > requirements of every possible identifier. This specification does > not define a generative grammar for URIs; that task is performed by > the individual specifications of each URI scheme. > > This is now a Standard Protocol. > > This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state > and status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3858 3100/99 ------------------------------------------------------------------------ See you at APNIC-19! Kyoto, Japan, 21 to 25 Feb 2005 and APRICOT 2005 http://www.apnic.net/meetings ------------------------------------------------------------------------ ASIAN TSUNAMI & EARTHQUAKE RELIEF APPEAL see http://www.apnic.net -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 27 04:03:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04299 for ; Thu, 27 Jan 2005 04:03:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu5pb-00047o-PM for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 04:20:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu5RE-0001hQ-Sh; Thu, 27 Jan 2005 03:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu5PW-0001Ox-8h for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 03:53: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 DAA03576 for ; Thu, 27 Jan 2005 03:53:52 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu5ga-0003vj-H1 for ipv6@ietf.org; Thu, 27 Jan 2005 04:11:34 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0R8r0Q08719; Thu, 27 Jan 2005 10:53:04 +0200 Date: Thu, 27 Jan 2005 10:53:00 +0200 (EET) From: Pekka Savola To: Brian Haberman In-Reply-To: <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> Message-ID: References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Bob Hinden , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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: 14582b0692e7f70ce7111d04db3781c8 On Fri, 21 Jan 2005, Brian Haberman wrote: > This Last Call ended yesterday with no comments. At a minimum, > I would like to hear from those people who commented previously > whether or not this version satisfies their concerns. Hi, I took a quick look at -03, with comments below. I think the main oDAD functionality is OK, but the draft likely needs a revision to make a few textual corrections. substantial ----------- Sorry that I did not catch this earlier, but I think the analysis in Appendix A on collision probability is not quite accurate. [SOTO] describes the collision of a random interface identifier. For that, looking at 62 bits is OK. What we are mostly concerned with are: - manual configuration - stateless address autoconfiguration - RFC3041 addresses Now, we cannot really analyze manual configuration mismatches, but we can analyze the probability of collision of SLAAC addresses. For RFC3041, the current calculations would apply, but we should calculate the maximal feasible probability as it is larger with SLAAC addresses. And for that, you'll have to use a different instead of 2^62; you could take for example Ethernet, and analyze 2^48. Text also needs to be massaged a bit to state which probability you are actually calculating. (Unfortunately, as the L2 address lengths are variable, you can't do much better calculations than this..) I don't think this changes the results in any meaningful way (the probabilities are about 16K larger), but this should probably still be changed. semi-substantial ---------------- * Nodes implementing Optimistic DAD SHOULD additionally implement Secure Neighbor Discovery [SEND]. ==> I agree with Jinmei's concern. SEND should be a normative reference if it's a SHOULD. * (modifies 5.5) A host MAY choose to configure a new address as an Optimistic Address. A host which does not know the SLLAO of its router SHOULD NOT configure a new address as Optimistic. A router MUST NOT configure an Optimistic Address. ==> Why MUST NOT for routers? It seems too strong. Sooner or later (if not already) folks deploying Mobile Routers (for example) are going to want to use this for their upstream interface, at least. Either you should justify clearly somewhere why it's technically unfeasible to use oDAD on routers, or weaken the text a bit, e.g., to a SHOULD NOT. editorial --------- The existing IPv6 address configuration mechanisms provide adequate collision detection mechanisms for the static hosts they were designed for. ==> s/static/fixed/ ? SAA - Stateless Address Autoconfiguration. The process described in [RFC2462] ==> "SAA" is ambiguous, because it could as well be Stateful AA. I suggest using either SLAC or SLAAC (both have been used). 4.2 Collision case ==> this section does not explicitly state at which point the ON unconfigures the address. Should it say that? When considering collision probability, the Birthday Paradox is generally mentioned. When randomly selecting k values from n possiblities, the probability of two values being the same is: ==> s/possib/possibi/ When considering the effect of collisions on a individual nodes, we ==> "a invididual nodes" ? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 27 04:56:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09164 for ; Thu, 27 Jan 2005 04:56:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu6f5-0005Po-OB for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 05:14:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6JT-0006Zh-V2; Thu, 27 Jan 2005 04:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6BT-0005MC-71 for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 04: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 EAA07601 for ; Thu, 27 Jan 2005 04:43:22 -0500 (EST) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu6SW-000503-Dx for ipv6@ietf.org; Thu, 27 Jan 2005 05:01:05 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 68D79701A9E; Thu, 27 Jan 2005 20:43:11 +1100 (EST) Date: Thu, 27 Jan 2005 20:43:11 +1100 From: "Nick 'Sharkey' Moore" To: Pekka Savola Message-ID: <20050127094311.GA16361@zoic.org> Mail-Followup-To: Pekka Savola , ipv6@ietf.org References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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: 41c17b4b16d1eedaa8395c26e9a251c4 On 2005-01-27, Pekka Savola wrote: > > I took a quick look at -03, with comments below. I think the main > oDAD functionality is OK, but the draft likely needs a revision to > make a few textual corrections. G'day Pekka, Thanks for looking at the draft ... looks like there's still I few things I missed, dang! > Sorry that I did not catch this earlier, but I think the analysis in > Appendix A on collision probability is not quite accurate. Ah, Appendix A is new. And you're right, I should have made it much clearer that I was talking about 3041 addresses. My main reason for including the text in Appendix A was to provide a permanent home for the work done by Soto et al. Ethernet-derived addresses are indeed also an issue, but they're hypothetically unique ... so we're back to estimating the inestimable ... are they less likely to collide than 3041 because of this supposed uniqueness, or more likely to collide because of the possibility of human error? > I don't think this changes the results in any meaningful way (the > probabilities are about 16K larger), but this should probably still be > changed. I'm open to suggestions ... I can just do the analysis with N=2^48 in parallel with N=2^62 if that seems useful ... but the non-random distribution of Ethernet addresses I think negates that point. I should definitely mention it. Would it be sufficient to change the first para of Appendix A to: | In assessing the usefulness of Duplicate Address Detection, the | probability of collision must be considered. Various mechanisms, | such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee | uniqueness of the address, but they add complexity to address | configuration and may introduce a risk of collision due to | misconfiguration. | | Privacy Extensions to SLAAC [RFC3041] avoid this issue by | picking an Interface Identifier (IID) at random from 2^62 possible | 64-bit IIDs (allowing for the reserved U and G bits). No | attempt is made to guarantee uniqueness, but as the following | discussion shows, probability is exceedingly unlikely. ... or do I need to be even clearer? > semi-substantial > ---------------- > [...] > editorial > --------- > [...] I agree on all of these, and will fix them immediately. Thanks heaps for your scrutiny! -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 27 05:29:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12138 for ; Thu, 27 Jan 2005 05:29:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu7As-0006Dm-Po for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 05:46:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6qT-00019X-Hl; Thu, 27 Jan 2005 05:25:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6e8-00066A-V5 for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 05:13: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 FAA10726 for ; Thu, 27 Jan 2005 05:13:02 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu6vE-0005oo-UR for ipv6@ietf.org; Thu, 27 Jan 2005 05:30:45 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0RACPN10641; Thu, 27 Jan 2005 12:12:25 +0200 Date: Thu, 27 Jan 2005 12:12:25 +0200 (EET) From: Pekka Savola To: "Nick 'Sharkey' Moore" In-Reply-To: <20050127094311.GA16361@zoic.org> Message-ID: References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> <20050127094311.GA16361@zoic.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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: 92df29fa99cf13e554b84c8374345c17 On Thu, 27 Jan 2005, Nick 'Sharkey' Moore wrote: > Ethernet-derived addresses are indeed also an issue, but they're > hypothetically unique ... so we're back to estimating the > inestimable ... are they less likely to collide than 3041 because > of this supposed uniqueness, or more likely to collide because > of the possibility of human error? Good question.. The reason why Ethernet MAC addresses would not be unique would probably be either human error (manually configuring the mac address) or a manufacturing error -- and in either case, it's not certain how much analysis on 2^48 would help.. > Would it be sufficient to change the first para of Appendix A to: > > | In assessing the usefulness of Duplicate Address Detection, the > | probability of collision must be considered. Various mechanisms, > | such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee > | uniqueness of the address, but they add complexity to address > | configuration and may introduce a risk of collision due to > | misconfiguration. > | > | Privacy Extensions to SLAAC [RFC3041] avoid this issue by > | picking an Interface Identifier (IID) at random from 2^62 possible > | 64-bit IIDs (allowing for the reserved U and G bits). No > | attempt is made to guarantee uniqueness, but as the following > | discussion shows, probability is exceedingly unlikely. > > ... or do I need to be even clearer? I'm open to hearing if others have thoughts about this. If we go through this kind of text, which would be basically OK by me, a couple of modifications will be needed, because the first paragraph seems to assign blame on SLAAC and DHCPv6 for complexity and recommending using RFC3041 instead. That's not good, the text needs to be more balanced. RFC3041 have many drawbacks, e.g., about their renumbering and the use for longer term than they are valid, and are solution only in some limited cases. Maybe use the following rewording? (I would also have wanted to say that due to these factors, it is impossible to calculate the collision probability of SLAAC in particular, but couldn't find the right words for that) In assessing the usefulness of Duplicate Address Detection, the probability of collision must be considered. Various mechanisms, such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee uniqueness of the address. The uniqueness of SLAAC depends on the reliability of the manufacturing process (so that duplicate L2 addresses are not assigned) and the human factors if L2 addresses are manually. The uniqueness of DHCPv6 assigned addresses relies on the correctness of implementation in ensuring that no two nodes can be given the same address. Privacy Extensions to SLAAC [RFC3041] avoid these potential error cases by picking an Interface Identifier (IID) at random from 2^62 possible 64-bit IIDs (allowing for the reserved U and G bits). No attempt is made to guarantee uniqueness, but the probability can be easily estimated, and as the following discussion shows, probability is exceedingly unlikely. -- 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 Jan 27 05:38:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13258 for ; Thu, 27 Jan 2005 05:38:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu7Jx-0006TO-AS for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 05:56:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6rv-0001uY-5A; Thu, 27 Jan 2005 05:27:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6lF-00088f-CX for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 05:20: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 FAA11520 for ; Thu, 27 Jan 2005 05:20:22 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu72I-00061p-QC for ipv6@ietf.org; Thu, 27 Jan 2005 05:38:06 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0RAKKdt025860 for ; Thu, 27 Jan 2005 03:20:20 -0700 (MST) Received: from fe7 (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 <0IAZ00C7I0PWAN@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 27 Jan 2005 03:20:20 -0700 (MST) Received: from [192.168.1.2] ([83.193.77.74]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAZ005UT0PTUK@mail.sun.net> for ipv6@ietf.org; Thu, 27 Jan 2005 03:20:20 -0700 (MST) Date: Thu, 27 Jan 2005 02:20:15 -0800 From: Alain Durand In-reply-to: <41F58141.7060504@kolumbus.fi> To: IPv6 Message-id: <0977F884-704D-11D9-AA6C-00039358A080@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: <41F09480.8010707@sun.com> <41F4CCDE.9040408@zurich.ibm.com> <41F52FB3.5020204@sun.com> <41F58141.7060504@kolumbus.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7BIT Cc: Erik Nordmark Subject: Re: Request to Advance: [RESEND] 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 Content-Transfer-Encoding: 7BIT On Jan 24, 2005, at 3:14 PM, Jari Arkko wrote: > Erik Nordmark wrote: > >>> I wonder whether Experimental wouldn't send a clearer signal >>> that there is some doubt about the viability of the solution. >> That would be better than informational. > > I agree. But I also think that if the document has > inconsistencies those should be corrected even before > publishing it as experimental. Fixing inconsistencies is a strict minimum that can be expected. This is a wg duty. That said, I have a problem with publishing a document related to ND that specify something that will not work with the IETF standardized approach to secure ND. Either, the deployment of ndproxy will be marginal and there will be no problems, but in that case, why even bother publishing it? Or NDproxy picks up and it may become an obstacle to get SEND deployed. The argument that NDproxy will only be used in a certain environments where SEND is not needed is clearly bogus, The IETF is not about defining standards for special cases but for the whole Internet. Erik seems to hint that there are ways to get NDproxy to work with SEND, IMHO, those should be explored and the current document should be put on hold until this is resolved. - 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 Jan 27 09:07:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07529 for ; Thu, 27 Jan 2005 09:07:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuAZo-0003l0-DD for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 09: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 1CuA9m-00082j-E7; Thu, 27 Jan 2005 08:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuA8O-0007dk-Ka for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 08:56: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 IAA06256 for ; Thu, 27 Jan 2005 08:56:29 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuAPP-0003L3-U3 for ipv6@ietf.org; Thu, 27 Jan 2005 09:14:14 -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 j0RDtm7E148426 for ; Thu, 27 Jan 2005 13:55:48 GMT Received: from d06av04.portsmouth.uk.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 j0RDtm4u157260 for ; Thu, 27 Jan 2005 13:55:48 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0RDtlZI003263 for ; Thu, 27 Jan 2005 13:55:48 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0RDtlhN003256; Thu, 27 Jan 2005 13:55:47 GMT Received: from zurich.ibm.com (sig-9-146-223-181.de.ibm.com [9.146.223.181]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA71240; Thu, 27 Jan 2005 14:55:46 +0100 Message-ID: <41F8F2DF.4090400@zurich.ibm.com> Date: Thu, 27 Jan 2005 14:55: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: Paul Wilson References: <41F75F27.6060401@zurich.ibm.com> <41F85B63.3000400@apnic.net> In-Reply-To: <41F85B63.3000400@apnic.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: A little piece of IPv6 makes full Standard status 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: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Apparently you missed this at last call :-) Well, that's why this WG withdrew its feeble attempts at ABNF. It's very, very hard to get 100.00% right. If you are convinced it's wrong, why not file an erratum with the RFC-Editor? http://www.rfc-editor.org/errata.html Brian Paul Wilson wrote: > It seems that sect 3.2.2 this RFC 3986 requires left padding of each > 16-bit piece of an IPv6 address with "0" > > eg 0000::/16 is allowed but 0::/16 is not > > If so, that seems incompatible with some common usages, including many > of those listed in sect 2 of RFC 2732. > > I note that the form "::192.9.5.5" also seems to be disallowed by the > new RFC. > > Paul Wilson > APNIC > > > Brian E Carpenter wrote: > >> fyi, this includes the IPv6 address format (obsoleting RFC 2732). >> >> Brian >> >> -------- Original Message -------- >> Subject: STD 66, RFC 3986 on Uniform Resource Identifier (URI): >> Generic Syntax >> Date: Tue, 25 Jan 2005 17:32:09 -0800 >> From: rfc-editor@rfc-editor.org >> To: ietf-announce@ietf.org >> CC: rfc-editor@rfc-editor.org >> >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> STD 66 >> RFC 3986 >> >> Title: Uniform Resource Identifier (URI): Generic Syntax >> Author(s): T. Berners-Lee, R. Fielding, L. Masinter >> Status: Standards Track >> Date: January 2005 >> Mailbox: timbl@w3.org, fielding@gbiv.com, LMM@acm.org >> Pages: 61 >> Characters: 141811 >> Updates: 1738 >> Obsoletes: 2732, 2396, 1808 >> >> I-D Tag: draft-fielding-uri-rfc2396bis-07.txt >> >> URL: ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt >> >> >> A Uniform Resource Identifier (URI) is a compact sequence of >> characters that identifies an abstract or physical resource. This >> specification defines the generic URI syntax and a process for >> resolving URI references that might be in relative form, along with >> guidelines and security considerations for the use of URIs on the >> Internet. The URI syntax defines a grammar that is a superset of all >> valid URIs, allowing an implementation to parse the common >> components of a URI reference without knowing the scheme-specific >> requirements of every possible identifier. This specification does >> not define a generative grammar for URIs; that task is performed by >> the individual specifications of each URI scheme. >> >> This is now a Standard Protocol. >> >> This document specifies an Internet standards track protocol for the >> Internet community, and requests discussion and suggestions for >> improvements. Please refer to the current edition of the "Internet >> Official Protocol Standards" (STD 1) for the standardization state >> and status of this protocol. Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF list and the RFC-DIST list. >> Requests to be added to or deleted from the IETF distribution list >> should be sent to IETF-REQUEST@IETF.ORG. Requests to be >> added to or deleted from the RFC-DIST distribution list should >> be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. >> >> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >> an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >> help: ways_to_get_rfcs. For example: >> >> To: rfc-info@RFC-EDITOR.ORG >> Subject: getting rfcs >> >> help: ways_to_get_rfcs >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> Submissions for Requests for Comments should be sent to >> RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >> Authors, for further information. >> >> >> Joyce K. Reynolds and Sandy Ginoza >> USC/Information Sciences Institute >> >> >> >> >> -------------------------------------------------------------------- >> 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 Jan 27 09:17:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08473 for ; Thu, 27 Jan 2005 09:17:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuAk8-00043z-Ps for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 09: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 1CuAO6-0003N1-GA; Thu, 27 Jan 2005 09:12:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuAEj-0000d1-FW for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 09:03: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 JAA07272 for ; Thu, 27 Jan 2005 09:03:03 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuAVq-0003fB-98 for ipv6@ietf.org; Thu, 27 Jan 2005 09:20:48 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0RE2QvU228612 for ; Thu, 27 Jan 2005 14:02:26 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0RE2Qv2166966 for ; Thu, 27 Jan 2005 15:02:26 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0RE2Q4W004957 for ; Thu, 27 Jan 2005 15:02:26 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0RE2PYu004943; Thu, 27 Jan 2005 15:02:25 +0100 Received: from zurich.ibm.com (sig-9-146-223-181.de.ibm.com [9.146.223.181]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA36200; Thu, 27 Jan 2005 15:02:24 +0100 Message-ID: <41F8F46E.5050600@zurich.ibm.com> Date: Thu, 27 Jan 2005 15:02: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: Alain Durand References: <41F09480.8010707@sun.com> <41F4CCDE.9040408@zurich.ibm.com> <41F52FB3.5020204@sun.com> <41F58141.7060504@kolumbus.fi> <0977F884-704D-11D9-AA6C-00039358A080@sun.com> In-Reply-To: <0977F884-704D-11D9-AA6C-00039358A080@sun.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: Erik Nordmark , IPv6 Subject: Re: Request to Advance: [RESEND] 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 Alain Durand wrote: ... > The argument that NDproxy will only be used in a certain environments > where SEND is not needed is clearly bogus, The IETF is not about > defining standards for special cases but for the whole Internet. I disagree as a matter of principle. It is perfectly OK to have specs that are incompatible with each other as long as they are never implemented on the same network. It isn't OK to do that without documenting the incompatibility. It's clear that this argument doesn't apply to end to end protocols, but strictly to things that have topologically limited scope. Actually we have plenty of examples of this; they are called routing protocols. That doesn't settle the issue of whether SEND and NDproxy are or are not incompatible, but I have no problem with the concept that a given (bridged) LAN can only run one of them. 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 Jan 27 13:15:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08112 for ; Thu, 27 Jan 2005 13:15:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuERp-0002RI-7w for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 13:32:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDzL-0004MG-Gl; Thu, 27 Jan 2005 13:03:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDt4-0002hK-UN for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 12:56: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 MAA06834 for ; Thu, 27 Jan 2005 12:56: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 1CuEAE-00023a-1Z for ipv6@ietf.org; Thu, 27 Jan 2005 13:14:43 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0RHuudt004787 for ; Thu, 27 Jan 2005 10:56:56 -0700 (MST) Received: from fe7 (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 <0IAZ00A00LUVTN@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 27 Jan 2005 10:56:56 -0700 (MST) Received: from [192.168.1.2] ([83.193.4.37]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAZ005ROLUSUN@mail.sun.net> for ipv6@ietf.org; Thu, 27 Jan 2005 10:56:55 -0700 (MST) Date: Thu, 27 Jan 2005 09:56:50 -0800 From: Alain Durand In-reply-to: <41F8F46E.5050600@zurich.ibm.com> To: Brian E Carpenter Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <41F09480.8010707@sun.com> <41F4CCDE.9040408@zurich.ibm.com> <41F52FB3.5020204@sun.com> <41F58141.7060504@kolumbus.fi> <0977F884-704D-11D9-AA6C-00039358A080@sun.com> <41F8F46E.5050600@zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: Erik Nordmark , IPv6 Subject: Re: Request to Advance: [RESEND] 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 On Jan 27, 2005, at 6:02 AM, Brian E Carpenter wrote: > Alain Durand wrote: > ... >> The argument that NDproxy will only be used in a certain environments >> where SEND is not needed is clearly bogus, The IETF is not about >> defining standards for special cases but for the whole Internet. > > I disagree as a matter of principle. It is perfectly OK to have > specs that are incompatible with each other as long as they are > never implemented on the same network. It isn't OK to do that without > documenting the incompatibility. > > It's clear that this argument doesn't apply to end to end > protocols, but strictly to things that have topologically limited > scope. > > Actually we have plenty of examples of this; they are called routing > protocols. I'm not sure the parallel is relevant. Routing protocols are self-contained elements that do not need each other... Here, at least in the example Jim Kempf & Erik gave, the two elements could very well be used together... As a matter of principle, I think it is better to standardize things so they work together all the time rather than balkanizing the domain of application by defining mutually exclusive standards. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 28 02:49:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01954 for ; Fri, 28 Jan 2005 02:49:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuR9a-0005M9-0R for ipv6-web-archive@ietf.org; Fri, 28 Jan 2005 03:06:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuQpX-0004Ob-8d; Fri, 28 Jan 2005 02:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuQlU-0003YL-Bg for ipv6@megatron.ietf.org; Fri, 28 Jan 2005 02:42: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 CAA00921 for ; Fri, 28 Jan 2005 02:41:58 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuR2l-00058k-UK for ipv6@ietf.org; Fri, 28 Jan 2005 02:59:52 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 23:41:26 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 23:41:27 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 27 Jan 2005 23:41:27 -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.1289); Thu, 27 Jan 2005 23:41:26 -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: Thu, 27 Jan 2005 23:41:29 -0800 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.txt Thread-Index: AcUEW09BxNmimHnVTgmmulsMpmRXvQAsQWjg From: "Christian Huitema" To: "Pekka Savola" , "Nick 'Sharkey' Moore" X-OriginalArrivalTime: 28 Jan 2005 07:41:26.0739 (UTC) FILETIME=[C5DEDA30:01C5050C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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: quoted-printable > On Thu, 27 Jan 2005, Nick 'Sharkey' Moore wrote: > > Ethernet-derived addresses are indeed also an issue, but they're > > hypothetically unique ... so we're back to estimating the > > inestimable ... are they less likely to collide than 3041 because > > of this supposed uniqueness, or more likely to collide because > > of the possibility of human error? >=20 > Good question.. The reason why Ethernet MAC addresses would not be > unique would probably be either human error (manually configuring the > mac address) or a manufacturing error -- and in either case, it's not > certain how much analysis on 2^48 would help.. Or, maybe, privacy. If we question the privacy aspects of sending unique identifiers in IPv6 addresses, then we might also question the privacy impact of broadcasting unique 48 bit identifiers in Ethernet or WIFI frames. Rhetorical question: how long will it take before computers systematically configure a new MAC address each time they reboot, or each time they roam to a new network? -- Christian Huitema=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 28 03:29:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06988 for ; Fri, 28 Jan 2005 03:29:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuRmY-0006IZ-S0 for ipv6-web-archive@ietf.org; Fri, 28 Jan 2005 03: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 1CuRTU-00064h-BD; Fri, 28 Jan 2005 03:27:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuRSB-0005n1-CN for ipv6@megatron.ietf.org; Fri, 28 Jan 2005 03:26: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 DAA06552 for ; Fri, 28 Jan 2005 03:26:05 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuRjS-0006Cs-GG for ipv6@ietf.org; Fri, 28 Jan 2005 03:43:59 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0S8Poc13144; Fri, 28 Jan 2005 10:25:50 +0200 (EET) X-Scanned: Fri, 28 Jan 2005 10:24:54 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0S8OseY024253; Fri, 28 Jan 2005 10:24:54 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003gGF0a; Fri, 28 Jan 2005 10:24:52 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0S8Oqx28315; Fri, 28 Jan 2005 10:24:52 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jan 2005 10:20:38 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jan 2005 10:20:37 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jan 2005 10:20:37 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2005 10:20:36 +0200 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.txt Thread-Index: AcUEW09BxNmimHnVTgmmulsMpmRXvQAsQWjgAAFyg7A= To: , , X-OriginalArrivalTime: 28 Jan 2005 08:20:37.0497 (UTC) FILETIME=[3F080E90:01C50512] X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Christian, > Rhetorical question: how long will it take before computers > systematically configure a new MAC address each time they reboot, or > each time they roam to a new network? Some l2's / networks are doing this already. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 28 03:38:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07733 for ; Fri, 28 Jan 2005 03:38:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuRvY-0006Vg-NA for ipv6-web-archive@ietf.org; Fri, 28 Jan 2005 03:56:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuRar-0007K1-T8; Fri, 28 Jan 2005 03: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 1CuRUT-0006DS-Em for ipv6@megatron.ietf.org; Fri, 28 Jan 2005 03:28: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 DAA06975 for ; Fri, 28 Jan 2005 03:28:27 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuRlk-0006Gi-FQ for ipv6@ietf.org; Fri, 28 Jan 2005 03:46:21 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0S8RkM10516; Fri, 28 Jan 2005 10:27:46 +0200 Date: Fri, 28 Jan 2005 10:27:46 +0200 (EET) From: Pekka Savola To: Christian Huitema 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: MAC-address randomizing privacy [RE: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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 On Thu, 27 Jan 2005, Christian Huitema wrote: >> On Thu, 27 Jan 2005, Nick 'Sharkey' Moore wrote: >>> Ethernet-derived addresses are indeed also an issue, but they're >>> hypothetically unique ... so we're back to estimating the >>> inestimable ... are they less likely to collide than 3041 because >>> of this supposed uniqueness, or more likely to collide because >>> of the possibility of human error? >> >> Good question.. The reason why Ethernet MAC addresses would not be >> unique would probably be either human error (manually configuring the >> mac address) or a manufacturing error -- and in either case, it's not >> certain how much analysis on 2^48 would help.. > > Or, maybe, privacy. If we question the privacy aspects of sending unique > identifiers in IPv6 addresses, then we might also question the privacy > impact of broadcasting unique 48 bit identifiers in Ethernet or WIFI > frames. Rhetorical question: how long will it take before computers > systematically configure a new MAC address each time they reboot, or > each time they roam to a new network? Actually, a friend of mine wrote this kind of code (Ethernet address randomization at bootup) to Linux as an alternative to RFC3041 maybe two years ago. I didn't push for it too much because it would have caused confusion under those cases where you have a stationary node and MAC address "locking" is used in Ethernet switches. (And there's AFAICS no good way to automatically determine this..) But for example on laptops which are expected to roam a bit more, this might make some amount of sense. It might be better than RFC3041 from the L3 perspective, at least. But the implications should IMHO be explored at some length first (maybe write an I-D?). Changing MAC addresses is going to cause more disruption on the roaming host in case of false positives, i.e., the laptop thinks it moved but actually didn't, because the communication using the old MAC address and resulting IP addresses is going to be disrupted unless you assume some kind of Neighbor Advertisement message use ("gratuitous ARP"). -- 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 Fri Jan 28 04:53:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12909 for ; Fri, 28 Jan 2005 04:53:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuT5c-0008HR-ES for ipv6-web-archive@ietf.org; Fri, 28 Jan 2005 05:10:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuSkQ-0000Vm-DZ; Fri, 28 Jan 2005 04:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuSim-0008OP-Es for ipv6@megatron.ietf.org; Fri, 28 Jan 2005 04:47: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 EAA12481 for ; Fri, 28 Jan 2005 04:47:18 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuT04-000890-1t for ipv6@ietf.org; Fri, 28 Jan 2005 05:05:13 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j0S9kem16600; Fri, 28 Jan 2005 10:46:40 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j0S9kdSj066473; Fri, 28 Jan 2005 10:46:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501280946.j0S9kdSj066473@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola In-reply-to: Your message of Fri, 28 Jan 2005 10:27:46 +0200. Date: Fri, 28 Jan 2005 10:46:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Christian Huitema , "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: MAC-address randomizing privacy [RE: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.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 In your previous mail you wrote: But the implications should IMHO be explored at some length first (maybe write an I-D?). Changing MAC addresses is going to cause more disruption on the roaming host in case of false positives, i.e., the laptop thinks it moved but actually didn't, because the communication using the old MAC address and resulting IP addresses is going to be disrupted unless you assume some kind of Neighbor Advertisement message use ("gratuitous ARP"). => I have a concern here: this topic is clearly outside the scope of the IETF, i.e., it should be handled at the IEEE (in fact IMHO it is already handled by the IEEE :-). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 28 15:30:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10563 for ; Fri, 28 Jan 2005 15:30:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cud2u-0007Ff-11 for ipv6-web-archive@ietf.org; Fri, 28 Jan 2005 15:48:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cucgo-0007h9-9K; Fri, 28 Jan 2005 15:25:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CucfF-0006uX-SH for ipv6@megatron.ietf.org; Fri, 28 Jan 2005 15:24: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 PAA10050 for ; Fri, 28 Jan 2005 15:24:19 -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 1Cucwd-000777-AI for ipv6@ietf.org; Fri, 28 Jan 2005 15:42:20 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Jan 2005 15:23:14 -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: Fri, 28 Jan 2005 15:23:13 -0500 Message-ID: Thread-Topic: Request to Advance: [RESEND] Thread-Index: AcUEewl+5NjqBKfyQF2AUZheUnV5zwA+50hA From: "Soliman, Hesham" To: "Brian E Carpenter" , "Alain Durand" X-OriginalArrivalTime: 28 Jan 2005 20:23:14.0010 (UTC) FILETIME=[3186EBA0:01C50577] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , IPv6 Subject: RE: Request to Advance: [RESEND] 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: quoted-printable > Alain Durand wrote: > ... > > The argument that NDproxy will only be used in a certain=20 > environments > > where SEND is not needed is clearly bogus, The IETF is not about > > defining standards for special cases but for the whole Internet.=20 >=20 > I disagree as a matter of principle. It is perfectly OK to have > specs that are incompatible with each other as long as they are > never implemented on the same network. It isn't OK to do that without > documenting the incompatibility. >=20 > It's clear that this argument doesn't apply to end to end > protocols, but strictly to things that have topologically limited > scope. >=20 > Actually we have plenty of examples of this; they are called routing > protocols. =3D> I don't think this is the right comparison though. Routing = protocols are performing similar functions and are alternatives to each other. What's being discussed here is two unrelated functions: Security and=20 "bridging" that are not compatible. This is quite different. FWIW I don't have a problem with ndproxy being published while = incompatible with SeND. There are other examples of completely insecure experimental RFCs, e.g. Fast handoffs. It's essential to make the document consistent = though. Hesham >=20 > That doesn't settle the issue of whether SEND and NDproxy are or > are not incompatible, but I have no problem with the concept that > a given (bridged) LAN can only run one of them. >=20 > Brian >=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 Fri Jan 28 18:08:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00668 for ; Fri, 28 Jan 2005 18:08:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CufVy-0004zg-Nj for ipv6-web-archive@ietf.org; Fri, 28 Jan 2005 18:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuf76-00035O-Jy; Fri, 28 Jan 2005 18:01:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuf6K-0002Pm-Aa for ipv6@megatron.ietf.org; Fri, 28 Jan 2005 18:00: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 SAA29675 for ; Fri, 28 Jan 2005 18:00:24 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CufNi-0004ob-Cd for ipv6@ietf.org; Fri, 28 Jan 2005 18:18:27 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IB100204UJTAX@mailout2.samsung.com> for ipv6@ietf.org; Sat, 29 Jan 2005 07:59:53 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IB100EUTUJTGO@mailout2.samsung.com> for ipv6@ietf.org; Sat, 29 Jan 2005 07:59:53 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IB100CLZUJRCQ@mmp2.samsung.com> for ipv6@ietf.org; Sat, 29 Jan 2005 07:59:53 +0900 (KST) Date: Fri, 28 Jan 2005 14:59:50 -0800 From: Alper Yegin In-reply-to: <0977F884-704D-11D9-AA6C-00039358A080@sun.com> To: "'IPv6'" Message-id: <00ec01c5058d$13b58d00$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7BIT Subject: RE: Request to Advance: [RESEND] 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 I know NDproxy is a WG item, but I think this problem space deserves a discussion on its own. Although it has implications on IPv6 ND, I think stretching subnets beyond links mean further than that. And there is already another proposal contending for a similar problem space, Rbridging. Before we drive NDproxy to finish line, shouldn't we be having a thorough discussion on this problem space and proposals? Alper -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 28 19:12:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06098 for ; Fri, 28 Jan 2005 19:12:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CugV7-0006I7-5B for ipv6-web-archive@ietf.org; Fri, 28 Jan 2005 19:30:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cug9Q-0000Ar-Na; Fri, 28 Jan 2005 19:07:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cug19-0006zz-8u for ipv6@megatron.ietf.org; Fri, 28 Jan 2005 18:59: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 SAA05065 for ; Fri, 28 Jan 2005 18:59:07 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CugIY-0005zJ-6u for ipv6@ietf.org; Fri, 28 Jan 2005 19:17:11 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IB100201X9PN8@mailout1.samsung.com> for ipv6@ietf.org; Sat, 29 Jan 2005 08:58:37 +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 <0IB1008JXX9O5Z@mailout1.samsung.com> for ipv6@ietf.org; Sat, 29 Jan 2005 08:58:36 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IB100L1HX9MFR@mmp1.samsung.com> for ipv6@ietf.org; Sat, 29 Jan 2005 08:58:36 +0900 (KST) Date: Fri, 28 Jan 2005 15:58:33 -0800 From: Alper Yegin In-reply-to: <200501280946.j0S9kdSj066473@givry.rennes.enst-bretagne.fr> To: "'Francis Dupont'" , "'Pekka Savola'" Message-id: <00f501c50595$47dbcba0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT Cc: "'Christian Huitema'" , "'Nick 'Sharkey' Moore'" , ipv6@ietf.org Subject: RE: MAC-address randomizing privacy [RE: IPv6 WG LastCall:draft-ietf-ipv6-optimistic-dad-03.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 > > In your previous mail you wrote: > > But the implications should IMHO be explored at some length first > (maybe write an I-D?). Changing MAC addresses is going to cause more > disruption on the roaming host in case of false positives, i.e., the > laptop thinks it moved but actually didn't, because the communication > using the old MAC address and resulting IP addresses is going to be > disrupted unless you assume some kind of Neighbor Advertisement > message use ("gratuitous ARP"). > > => I have a concern here: this topic is clearly outside the scope of > the IETF, i.e., it should be handled at the IEEE (in fact IMHO it is > already handled by the IEEE :-). Then how come this issue is discussed in this "I-D" (check the author list :-) http://ietf.org/internet-drafts/draft-haddad-momipriv-problem-statement- 00.txt Since IETF's ARP and ND deal with the MAC addresses, I think some discussion on that is needed at IETF. Alper -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 29 00:17:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25789 for ; Sat, 29 Jan 2005 00:17:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CulGP-0003QI-SS for ipv6-web-archive@ietf.org; Sat, 29 Jan 2005 00:35:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cukw1-0006jb-Ei; Sat, 29 Jan 2005 00:14:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cukvg-0006Tm-SW for ipv6@megatron.ietf.org; Sat, 29 Jan 2005 00:13: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 AAA25564 for ; Sat, 29 Jan 2005 00:13:49 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CulD8-0003MS-QK for ipv6@ietf.org; Sat, 29 Jan 2005 00:31:56 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0T5iAq00611; Fri, 28 Jan 2005 21:44:10 -0800 X-mProtect: <200501290544> Nokia Silicon Valley Messaging Protection Received: from esnira-pool401556.nokia.com (10.162.15.56, claiming to be "[10.162.15.56]") by darkstar.iprg.nokia.com smtpdnzOJ7K; Fri, 28 Jan 2005 20:18:00 PST Message-ID: <41FB0725.7090001@iprg.nokia.com> Date: Fri, 28 Jan 2005 19:46:45 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" 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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Alain Durand , Brian E Carpenter , IPv6 , Erik Nordmark Subject: Re: Request to Advance: [RESEND] 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 Soliman, Hesham wrote: > FWIW I don't have a problem with ndproxy being published while incompatible > with SeND. There are other examples of completely insecure experimental > RFCs, e.g. Fast handoffs. It's essential to make the document consistent though. what is being discussed is incompatibility between two protocols. not insecure experimental protocols. FWIW, draft-kempf-mobopts-handover-key-00.txt is tring to define how SEND can be used to create keys for fast handoffs. Vijay > > Hesham > > > > > That doesn't settle the issue of whether SEND and NDproxy are or > > are not incompatible, but I have no problem with the concept that > > a given (bridged) LAN can only run one of them. > > > > Brian > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > =========================================================== > 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. > =========================================================== > > > -------------------------------------------------------------------- > 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 Sun Jan 30 00:11:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16052 for ; Sun, 30 Jan 2005 00:11:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cv7f3-0004aU-65 for ipv6-web-archive@ietf.org; Sun, 30 Jan 2005 00:30:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cv7Kp-0007JW-S1; Sun, 30 Jan 2005 00:09:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cv7Cv-0006ra-C2 for ipv6@megatron.ietf.org; Sun, 30 Jan 2005 00:01: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 AAA15458 for ; Sun, 30 Jan 2005 00:01:06 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cv7Ub-0004PC-AU for ipv6@ietf.org; Sun, 30 Jan 2005 00:19:25 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 1A287749 for ; Sun, 30 Jan 2005 00:00:35 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 30 Jan 2005 00:00:34 -0500 Message-Id: <20050130050035.1A287749@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.81% | 4 | 15.54% | 29156 | brc@zurich.ibm.com 8.11% | 3 | 9.24% | 17337 | pekkas@netcore.fi 8.11% | 3 | 7.40% | 13887 | erik.nordmark@sun.com 5.41% | 2 | 6.05% | 11346 | bob.hinden@nokia.com 5.41% | 2 | 5.11% | 9580 | sharkey@zoic.org 5.41% | 2 | 4.96% | 9309 | alain.durand@sun.com 5.41% | 2 | 4.88% | 9164 | jinmei@isl.rdc.toshiba.co.jp 5.41% | 2 | 4.75% | 8906 | john.loughney@nokia.com 5.41% | 2 | 4.43% | 8319 | alper.yegin@samsung.com 5.41% | 2 | 3.76% | 7049 | kempf@docomolabs-usa.com 2.70% | 1 | 4.22% | 7922 | brian@innovationslab.net 2.70% | 1 | 3.89% | 7308 | pwilson@apnic.net 2.70% | 1 | 3.03% | 5680 | internet-drafts@ietf.org 2.70% | 1 | 3.03% | 5676 | ericlklein@softhome.net 2.70% | 1 | 2.91% | 5453 | h.soliman@flarion.com 2.70% | 1 | 2.60% | 4873 | vijayd@iprg.nokia.com 2.70% | 1 | 2.45% | 4594 | huitema@windows.microsoft.com 2.70% | 1 | 2.24% | 4203 | rdroms@cisco.com 2.70% | 1 | 2.11% | 3966 | francis.dupont@enst-bretagne.fr 2.70% | 1 | 2.06% | 3872 | sra+ipng@hactrn.net 2.70% | 1 | 2.01% | 3764 | sommerfeld@sun.com 2.70% | 1 | 1.74% | 3261 | jari.arkko@kolumbus.fi 2.70% | 1 | 1.60% | 3011 | yuxuanqk@126.com --------+------+--------+----------+------------------------ 100.00% | 37 |100.00% | 187636 | 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 Jan 30 05:25:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18863 for ; Sun, 30 Jan 2005 05:25:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvCYW-0006BJ-Qo for ipv6-web-archive@ietf.org; Sun, 30 Jan 2005 05:43:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvCEY-0004cR-JR; Sun, 30 Jan 2005 05:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvCC1-0004Le-VY for ipv6@megatron.ietf.org; Sun, 30 Jan 2005 05: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 FAA18715 for ; Sun, 30 Jan 2005 05:20:31 -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 1CvCTk-00066c-OH for ipv6@ietf.org; Sun, 30 Jan 2005 05:38:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Jan 2005 03:29:45 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0UAJsl2024518; Sun, 30 Jan 2005 02:19:55 -0800 (PST) Received: from rdroms-w2k01.cisco.com (sjc-vpn6-54.cisco.com [10.21.120.54]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOS02613; Sun, 30 Jan 2005 05:19:55 -0500 (EST) Message-Id: <4.3.2.7.2.20050130051824.02c50f30@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 30 Jan 2005 05:19:53 -0500 To: IPv6 From: Ralph Droms In-Reply-To: <03f501c503c4$f69720e0$626015ac@dcml.docomolabsusa.com> References: <41F09480.8010707@sun.com> <41F532A6.1080809@sun.com> <01ba01c5025b$91780a90$626015ac@dcml.docomolabsusa.com> <6.1.2.0.2.20050125204826.032ef8a8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Thomas Narten , Margaret Wasserman , Brian Haberman , Erik Nordmark , Bob Hinden Subject: Re: Request to Advance: [RESEND] 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 Some comments on draft-ietf-ipv6-ndproxy-00.txt... Substantive comments: I think this document would be more appropriately published as an Experimental RFC rather than Informational. The inconsistencies between the requirements for securing IPv6 neighbor discovery and allowing dynamic addition/removal of a proxy and the text itself should be fixed. In section 1.1, there is a description of a scenario in which ND bridging would provide in-site networking when a service provider provides just a single address to a customer. The current IAB recommendation is to provide a /48 prefix to each customer. Do we have supporting evidence that some service providers will, in fact, provide just a single address? All of the service providers I've talked to expect to provide a /48 to each customer, through the use of prefix delegation that requires no configuration of the CPE on the part of the customer. As another example of deployment where a loop might be possible but unexpected, there is a specification under development for cable-broadband deployments in which the in-home coax cable may be used as a link, using different frequencies than the frequencies used between the cable modem and the CMTS. The in-home coax link is logically separate from the CM-CMTS link. It is possible that a device that can communicate on both links would employ NDproxy between the two links. If there is more than one such device, a loop is possible. There are two small issues with the mechanism for accommodating DHCPv4. First, the mechanism is incompatible with the authentication protocol for DHCPv4 described in RFC 3118. In fact, the mechanism will be incompatible with any authentication that verifies the integrity of the data in the DHCPv4 message header, as changing the broadcast bit from 0 to 1 should be detected as a change in the contents of the message. Second, there should be a warning that a DHCPv4 client might detect, with subsequently undefined behavior, that the broadcast bit has been changed from the setting in the message originally set by the client. Editorial suggestion: My understanding is that NDproxy is intended for use between media that cannot be bridged at the link-layer, and which, presumably, have different link-layer header formats. While it would, I guess be obvious to an implementor, It would clarify the text to add a sentence or two in the last paragraph of section 4.1 explaining that the entire layer two header in the outgoing packet must be modified to the format of the layer 2 media over which the packet will be forwarded. Unimportant editorial nits: Although the title is "Bridge-like Neighbor Discovery Proxies (ND Proxy)", the Abstract does not restrict the protocols in the specification to IPv6. In fact, there is support for IPv4 bridging, including ARP and DHCPv4. I think it would clarify the intent of the draft to change the title (or, at least, the abstract) to reflect that bridging of some IPv4 protocols is included in this specification. Sections 4.1 and 4.2 might be more accurately titled "Forwarding Packets" and "Originating packets". -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 30 05:51:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20523 for ; Sun, 30 Jan 2005 05:51:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvCxW-0006fo-Ji for ipv6-web-archive@ietf.org; Sun, 30 Jan 2005 06:09:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvCdi-00087M-Cc; Sun, 30 Jan 2005 05:49:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvCcL-0007v6-Ch for ipv6@megatron.ietf.org; Sun, 30 Jan 2005 05:47:45 -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 FAA20354 for ; Sun, 30 Jan 2005 05:47:42 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvCu2-0006bR-7U for ipv6@ietf.org; Sun, 30 Jan 2005 06:06:04 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j0UAl3s23870; Sun, 30 Jan 2005 11:47:04 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j0UAl1Sj077478; Sun, 30 Jan 2005 11:47:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501301047.j0UAl1Sj077478@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alper Yegin In-reply-to: Your message of Fri, 28 Jan 2005 15:58:33 PST. <00f501c50595$47dbcba0$291d9069@sisa.samsung.com> Date: Sun, 30 Jan 2005 11:47:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "'Christian Huitema'" , "'Nick 'Sharkey' Moore'" , ipv6@ietf.org, "'Pekka Savola'" Subject: Re: MAC-address randomizing privacy [RE: IPv6 WG LastCall:draft-ietf-ipv6-optimistic-dad-03.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 In your previous mail you wrote: Since IETF's ARP and ND deal with the MAC addresses, I think some discussion on that is needed at IETF. => I was not clear enough: my concern is about producing an IETF document about MAC address changing, not about discussion about this topics. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 30 21:53:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24826 for ; Sun, 30 Jan 2005 21:53:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvRz4-0007Ah-Sz for ipv6-web-archive@ietf.org; Sun, 30 Jan 2005 22:12:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvRet-0004E9-1R; Sun, 30 Jan 2005 21:51:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvRcI-00041J-MR for ipv6@megatron.ietf.org; Sun, 30 Jan 2005 21:48: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 VAA24490 for ; Sun, 30 Jan 2005 21:48:40 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvRu9-00076A-9E for ipv6@ietf.org; Sun, 30 Jan 2005 22:07:10 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0V2mdc14717; Mon, 31 Jan 2005 04:48:39 +0200 (EET) X-Scanned: Mon, 31 Jan 2005 04:47:36 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0V2laAK021427; Mon, 31 Jan 2005 04:47:36 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00e9nTVL; Mon, 31 Jan 2005 04:47:34 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 j0V2lNU25557; Mon, 31 Jan 2005 04:47:23 +0200 (EET) Received: from l5131412.nokia.com ([10.162.15.83]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 04:47:22 +0200 Message-Id: <6.1.2.0.2.20050130183751.03168ec0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 30 Jan 2005 18:47:21 -0800 To: IPv6 WG From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jan 2005 02:47:22.0485 (UTC) FILETIME=[30509A50:01C5073F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Brian Haberman , Bob.Hinden@nokia.com Subject: Next steps with 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 The chairs have reviewed the comments on on the mailing list received after the "Request to Advance". It would have been nice if this discussion had occurred during the working group last call, but we do agree there are some serious issues with the draft that should be fixed. We will ask the ADs to send it back to the working group. Based on our reading of the discussion, we believe there is still a consensus to publish this document once these issues are resolved. We also agree that it would be better to publish it as an Experimental RFC, than at Informational. Bob Hinden & Brian Haberman IPv6 w.g. chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 31 08:07:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24909 for ; Mon, 31 Jan 2005 08:07:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvbZO-0002Zt-QN for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 08:26:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvb85-0003nn-V8; Mon, 31 Jan 2005 07:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvazx-0001qQ-PG for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 07:49:45 -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 HAA23177 for ; Mon, 31 Jan 2005 07:49:44 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvbHt-00027T-J3 for ipv6@ietf.org; Mon, 31 Jan 2005 08:08:19 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VCnfc20968 for ; Mon, 31 Jan 2005 14:49:41 +0200 (EET) X-Scanned: Mon, 31 Jan 2005 14:59:34 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0VCxYXX004860 for ; Mon, 31 Jan 2005 14:59:34 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 006QeYD0; Mon, 31 Jan 2005 14:59:33 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 j0VCmkU09576 for ; Mon, 31 Jan 2005 14:48:46 +0200 (EET) Received: from l5131412.nokia.com ([172.21.81.93]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 14:48:39 +0200 Message-Id: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 31 Jan 2005 04:48:36 -0800 To: IPv6 WG From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jan 2005 12:48:39.0567 (UTC) FILETIME=[2FEE71F0:01C50793] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: IPv6 Address Architecture update 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.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi, I am working on an update to the IPv6 address architecture. In doing this I am working through the comments on the previous draft. One comment made was to remove Section 2.5.5 "IPv6 Addresses with Embedded IPv4 Addresses" from the document. This would include removing the special case in the textual representation (section 2.2, 3.). I would like to solicit the working group's thoughts on this. I don't have a strong opinion one way or another. It's not clear it has ever been that useful and add a certain degree of complexity. On the other hand, it appears in several places in the document and requires some careful editing :-) Since I expect this is widely implemented, please be sure to report any problem that might occur if this is to be removed from the specification. This includes would it break other documents that refer to the IPv6 address architecture specification. The plan is to submit the updated draft for Draft Standard. In general removing things that are not found to be useful is OK when going to Draft standard. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 31 08:30:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29279 for ; Mon, 31 Jan 2005 08:30:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvbvK-0003Kc-Q3 for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 08:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbaS-000213-GR; Mon, 31 Jan 2005 08:27:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbY9-0001Xp-Ba for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 08:25: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 IAA28671 for ; Mon, 31 Jan 2005 08:25:03 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvbq4-0003Da-1Y for ipv6@ietf.org; Mon, 31 Jan 2005 08:43:38 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 727F92400D; Mon, 31 Jan 2005 14:24:48 +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 08208-06; Mon, 31 Jan 2005 14:24:48 +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 DA1182400C; Mon, 31 Jan 2005 14:24:47 +0100 (CET) From: Jeroen Massar To: Bob Hinden In-Reply-To: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> Organization: Unfix Date: Mon, 31 Jan 2005 14:24:46 +0100 Message-Id: <1107177886.27827.80.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.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: IPv6 WG Subject: Re: IPv6 Address Architecture update 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="===============0111723531==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --===============0111723531== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-w9dpeWRGxGRrikQi8/bW" --=-w9dpeWRGxGRrikQi8/bW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-31 at 04:48 -0800, Bob Hinden wrote: > Hi, >=20 > I am working on an update to the IPv6 address architecture. In doing thi= s=20 > I am working through the comments on the previous draft. One comment mad= e=20 > was to remove Section 2.5.5 "IPv6 Addresses with Embedded IPv4 Addresses"= =20 > from the document. This would include removing the special case in the=20 > textual representation (section 2.2, 3.). In http://www.ietf.org/rfc/rfc2373.txt it is section 2.5.4. Or am I looking at the wrong document? :) > Since I expect this is widely implemented, please be sure to report any=20 > problem that might occur if this is to be removed from the=20 > specification. I think that at least all the BSD's and most Linuxes are using this. They allow binding on :: (IPv6 any) and also accept IPv4 connections on the same socket, which are then represented in netstat etc as ::ffff:1.2.3.4. Both OS's nowadays have a bind-ipv6-only flag or similar, but many applications rely on this behaviour in that they either bind to the IPv6 any or the IPv4 any address (0.0.0.0). Removing it, thus would mean that all these applications are broken and need to be updated, which actually is true, having that programs should use multiple sockets and use getaddrinfo() to figure out the correct sockets to bind on. This has some programming overhead though and as many people are lazy they did not do it. The mixing of the stacks, thus having IPv6 also accept IPv4 connections, did have some negative side effects for the applications that did/do support getaddrinfo() type binding and bind to multiple sockets, as they would first bind to IPv6 any, after which they bind to IPv4 any which would fail with socket already in use, giving an error message that is not entirely true. IMO the section can be removed and programmers need to be learned the correct thing for which I always very inclined to point people to Eva's excellent document at http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and/or draft-ietf-v6ops-application-transition-02.txt The various Operating Systems that support this should be thought the same tricks too of course... > This includes would it break other documents that refer to=20 > the IPv6 address architecture specification. At least RFC3484 has a short section (3.3) on it, though it mentions handling them as 'global scope', which is basically the default case, for address selection. Greets, Jeroen --=-w9dpeWRGxGRrikQi8/bW 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/ iD8DBQBB/jGdKaooUjM+fCMRAp+wAJ0XRYeA8AscWypBpmS6sruzu1hvNACfd+JM EnaqOcnZyFVoZ1dEx9K+qH8= =jTpW -----END PGP SIGNATURE----- --=-w9dpeWRGxGRrikQi8/bW-- --===============0111723531== 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 -------------------------------------------------------------------- --===============0111723531==-- From ipv6-bounces@ietf.org Mon Jan 31 08:48:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01363 for ; Mon, 31 Jan 2005 08:48:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvcCj-0003mK-WB for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 09: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 1Cvbs1-0004R6-Vz; Mon, 31 Jan 2005 08:45:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvbr2-0004Au-Fj for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 08:44: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 IAA00910 for ; Mon, 31 Jan 2005 08:44:35 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvc8z-0003gp-T1 for ipv6@ietf.org; Mon, 31 Jan 2005 09:03:10 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VDiV802645; Mon, 31 Jan 2005 15:44:32 +0200 (EET) X-Scanned: Mon, 31 Jan 2005 15:52:41 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0VDqfNt003194; Mon, 31 Jan 2005 15:52:41 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 009NOvKP; Mon, 31 Jan 2005 15:52:40 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 j0VDfgU08742; Mon, 31 Jan 2005 15:41:42 +0200 (EET) Received: from l5131412.nokia.com ([172.21.81.93]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 15:41:09 +0200 Message-Id: <6.1.2.0.2.20050131053603.0302c938@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 31 Jan 2005 05:41:05 -0800 To: Jeroen Massar From: Bob Hinden In-Reply-To: <1107177886.27827.80.camel@firenze.zurich.ibm.com> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <1107177886.27827.80.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jan 2005 13:41:09.0664 (UTC) FILETIME=[85891A00:01C5079A] X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: IPv6 WG Subject: Re: IPv6 Address Architecture update 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.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Jeroen, At 05:24 AM 01/31/2005, Jeroen Massar wrote: >On Mon, 2005-01-31 at 04:48 -0800, Bob Hinden wrote: > > Hi, > > > > I am working on an update to the IPv6 address architecture. In doing this > > I am working through the comments on the previous draft. One comment made > > was to remove Section 2.5.5 "IPv6 Addresses with Embedded IPv4 Addresses" > > from the document. This would include removing the special case in the > > textual representation (section 2.2, 3.). > >In http://www.ietf.org/rfc/rfc2373.txt it is section 2.5.4. >Or am I looking at the wrong document? :) Right it's section 2.5.4 in RFC2373. The section changed a little in the new draft. > > > > Since I expect this is widely implemented, please be sure to report any > > problem that might occur if this is to be removed from the > > specification. > >I think that at least all the BSD's and most Linuxes are using this. >They allow binding on :: (IPv6 any) and also accept IPv4 connections on >the same socket, which are then represented in netstat etc >as ::ffff:1.2.3.4. Both OS's nowadays have a bind-ipv6-only flag or >similar, but many applications rely on this behaviour in that they >either bind to the IPv6 any or the IPv4 any address (0.0.0.0). > >Removing it, thus would mean that all these applications are broken and >need to be updated, which actually is true, having that programs should >use multiple sockets and use getaddrinfo() to figure out the correct >sockets to bind on. This has some programming overhead though and as >many people are lazy they did not do it. I am not sure they would be broken. They would be doing something in addition to what is in the new RFC. In any case, thanks for the comments. Bob >The mixing of the stacks, thus having IPv6 also accept IPv4 connections, >did have some negative side effects for the applications that did/do >support getaddrinfo() type binding and bind to multiple sockets, as they >would first bind to IPv6 any, after which they bind to IPv4 any which >would fail with socket already in use, giving an error message that is >not entirely true. > >IMO the section can be removed and programmers need to be learned the >correct thing for which I always very inclined to point people to Eva's >excellent document at http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html >and/or draft-ietf-v6ops-application-transition-02.txt > >The various Operating Systems that support this should be thought the >same tricks too of course... > > > This includes would it break other documents that refer to > > the IPv6 address architecture specification. > >At least RFC3484 has a short section (3.3) on it, though it mentions >handling them as 'global scope', which is basically the default case, >for address selection. > >Greets, > Jeroen > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 31 11:56:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22880 for ; Mon, 31 Jan 2005 11:56:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvf8r-0008Tx-F7 for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 12:15:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvepH-0008Jm-In; Mon, 31 Jan 2005 11:54:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvcpI-0004ZP-Qm for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 09:46: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 JAA07027 for ; Mon, 31 Jan 2005 09:46:49 -0500 (EST) Received: from [66.79.184.10] (helo=cpanel.pcextreme.nl) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvd7E-000554-3B for ipv6@ietf.org; Mon, 31 Jan 2005 10:05:25 -0500 Received: from nobody by cpanel.pcextreme.nl with local (Exim 4.44) id 1Cvcol-0005vo-Nx for ipv6@ietf.org; Mon, 31 Jan 2005 15:46:19 +0100 To: ipv6@ietf.org From: Washington Mutual Bank MIME-Version: 1.0 Message-Id: Date: Mon, 31 Jan 2005 15:46:19 +0100 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel.pcextreme.nl X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - cpanel.pcextreme.nl X-Spam-Score: 1.9 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Mon, 31 Jan 2005 11:54:58 -0500 Subject: Unauthorized Access To Your Washington Mutual Internet Banking Account 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="===============0629954443==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 --===============0629954443== Content-Type: text/html Content-Transfer-Encoding: 8bit Dear Washington Mutual customer

Dear Washington Mutual customer,

We recently reviewed your account, and suspect that your Washington Mutual Internet Banking account may have been accessed by an unauthorized third party.
Protecting the security of your account and of the Washington Mutual network is our primary concern. Therefore, as a preventative measure, we have temporarily limited access to sensitive account features.

To restore your account access , please take the following steps to ensure that your account has not been compromised:

1. Login to your Washington Mutual Internet Banking account. In case you are not enrolled yet for Internet Banking, you will have to use your Social Security Number as both your Personal ID and Password and fill in the required information, including your name and account number.

2. Review your recent account history for any unauthorized withdrawals or deposits, and check your account profile to make sure no changes have been made. If any unauthorized activity has taken place on your account, report to Washington Mutual staff immediately.

To get started, please click the link below:

https://login.personal.wamu.com/logon/logon.asp?dd=1

We apologize for any inconvenience this may cause, and appreciate your assistance in helping us maintain the integrity of the entire Washington Mutual system. Thank your for your prompt attention to this matter.

Sincerely,

The Washington Mutual Team.

Please do not reply to this email. Mails sent to thi address cannot be answered. For assistance, log in to your Washington Mutual account and choose the "Help" link in the header of any page.

--===============0629954443== 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 -------------------------------------------------------------------- --===============0629954443==-- From ipv6-bounces@ietf.org Mon Jan 31 12:04:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23622 for ; Mon, 31 Jan 2005 12:04:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfGJ-0000Ct-Em for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 12:22:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvepI-0008Jv-HP; Mon, 31 Jan 2005 11:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cveaa-0004CK-Do for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 11: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 LAA21147 for ; Mon, 31 Jan 2005 11:39:46 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvesY-00086M-Fe for ipv6@ietf.org; Mon, 31 Jan 2005 11:58:23 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0VGdjVu028517; Mon, 31 Jan 2005 09:39:45 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0VGdjQp007233; Mon, 31 Jan 2005 11:39:45 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j0VGdjU7002408; Mon, 31 Jan 2005 11:39:45 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j0VGdjG7002407; Mon, 31 Jan 2005 11:39:45 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Bob Hinden In-Reply-To: <6.1.2.0.2.20050131053603.0302c938@mailhost.iprg.nokia.com> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <1107177886.27827.80.camel@firenze.zurich.ibm.com> <6.1.2.0.2.20050131053603.0302c938@mailhost.iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107189584.1705.102.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 31 Jan 2005 11:39:45 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Jan 2005 11:54:58 -0500 Cc: IPv6 WG Subject: Re: IPv6 Address Architecture update 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Mon, 2005-01-31 at 08:41, Bob Hinden wrote: > >Removing it, thus would mean that all these applications are broken and > >need to be updated, which actually is true, having that programs should > >use multiple sockets and use getaddrinfo() to figure out the correct > >sockets to bind on. This has some programming overhead though and as > >many people are lazy they did not do it. > > I am not sure they would be broken. They would be doing something in > addition to what is in the new RFC. They should not be removed from a new version of the spec without a mention in the newer version about *why* they were removed. If we do not have consensus in this WG about why we want to remove them, we will cause eternal confusion for OS and application implementors downstream. (And I'm actually aware of at least one feature in the solaris IP stack which is supposedly available for UDP/IPv4 traffic through AF_INET6 sockets which is not conveniently available through AF_INET sockets. Long story ...) - 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 Jan 31 12:06:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23974 for ; Mon, 31 Jan 2005 12:06:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfIP-0000Ih-LF for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 12:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CveqJ-0000FF-Mj; Mon, 31 Jan 2005 11:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvep2-0008EN-Sn for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 11: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 LAA22565 for ; Mon, 31 Jan 2005 11:54:42 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvf70-0008PJ-Vr for ipv6@ietf.org; Mon, 31 Jan 2005 12:13:20 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id D27F32400D for ; Mon, 31 Jan 2005 17:54:32 +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 21157-10 for ; Mon, 31 Jan 2005 17:54:32 +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 4A13E2400C for ; Mon, 31 Jan 2005 17:54:32 +0100 (CET) From: Jeroen Massar To: ipv6@ietf.org Organization: Unfix Date: Mon, 31 Jan 2005 17:54:30 +0100 Message-Id: <1107190470.27827.134.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: f60d0f7806b0c40781eee6b9cd0b2135 Subject: AYIYA link local address 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="===============1593789317==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --===============1593789317== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8szcQnLMyl/+gVPfKpyS" --=-8szcQnLMyl/+gVPfKpyS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Somebody nicely noticed that multicast did not work over AYIYA, because of ... a missing linklocal address, thus causing MLD to fail. This as tun/tap's are not able to form a link local. The fix is of course to simply generate a link local address, eg fe80::1 + fe80::2, but as we want to do it correctly, I thought up the following scheme, which might be useful in other tunneling scenarios that don't have ll's. Global IPv6 =3D 2001:db8:1234:5678:abcd::1/64 The link local =3D fe80::db8:1234:5678:abcd:1/64 To make the EUI-64 we take the global address, which is known and then ignore the first 32bits, which describe the ISP's TLA, there is nothing smaller. We then take the next 32bits (1234:5678:abcd) which together with the first 32bits actually describe the /64. Assuming that the tunnel stays inside the ISP, this should thus not cause any collisions, and should be at least quite unique. We then append the last 16 bits (::1) so that the remote end can use ::2. As it is not unique we clear the unique bit 7, it is a host thus we clear bit 8 too. Anyone has any arguments against doing it like the above or has a better suggestion? I'll include it in the upcoming update of the AYIYA draft. Having a LL also allows RA's to work. Which brings up another question: One can, in some situations, run a RA Daemon on the router side of the tunnel or even DHCP+PD (Prefix Delegation). The RA on the tunnel could be seen as useful, though in our setups we normally expect folks to have ::2 so we can do latency tests, at least ping6'ing ff02::1 is not that useful as that could return multiple answers, yes even on a tunnel. Nevertheless, the question is more with the Prefix Delegation. How does the router know where, on which interfaces, it is allowed to activate IPv6? I was thinking of actually enabling it, then realized that people will get a static allocation /48 routed to the ::2 endpoint anyway, which should not change over time and allowing them to configure their network as they wish it to be configured. Next to that of course, not that many end hosts/routers actually support DHCP-PD, let alone a IPv6 DHCP in the first place. I am thus more wondering if the PD setup is actually a worthwhile deployment system when delegating a complete /48 to an enduser. Especially keeping in mind that the /48 will most likely never change and the /48 prefix itself can easily be retrieved using the TIC protocol. Greets, Jeroen --=-8szcQnLMyl/+gVPfKpyS 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/ iD8DBQBB/mLGKaooUjM+fCMRArZlAJ9ZInk5GLcNUtboCtF7NbJjGRxsXgCgsrF0 yYDrtDPIGy3TQ08YX1Yas2M= =G04V -----END PGP SIGNATURE----- --=-8szcQnLMyl/+gVPfKpyS-- --===============1593789317== 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 -------------------------------------------------------------------- --===============1593789317==-- From ipv6-bounces@ietf.org Mon Jan 31 12:44:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27978 for ; Mon, 31 Jan 2005 12:44:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfpY-0001Ez-4s for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 13:03:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfQd-0001Ui-2N; Mon, 31 Jan 2005 12:33:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfGW-0000C4-5J for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 12:23: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 MAA26020 for ; Mon, 31 Jan 2005 12:23:03 -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 1CvfYQ-0000ox-Do for ipv6@ietf.org; Mon, 31 Jan 2005 12:41:41 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j0VHMwFt011361; Mon, 31 Jan 2005 19:22:58 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j0VHMvd3011358; Mon, 31 Jan 2005 19:22:57 +0200 Date: Mon, 31 Jan 2005 19:22:57 +0200 Message-Id: <200501311722.j0VHMvd3011358@burp.tkv.asdf.org> From: Markku Savela To: sommerfeld@sun.com In-reply-to: <1107189584.1705.102.camel@thunk> (message from Bill Sommerfeld on Mon, 31 Jan 2005 11:39:45 -0500) References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <1107177886.27827.80.camel@firenze.zurich.ibm.com> <6.1.2.0.2.20050131053603.0302c938@mailhost.iprg.nokia.com> <1107189584.1705.102.camel@thunk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org, bob.hinden@nokia.com Subject: Re: IPv6 Address Architecture update 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: 2409bba43e9c8d580670fda8b695204a > From: Bill Sommerfeld > > They should not be removed from a new version of the spec without a > mention in the newer version about *why* they were removed. They should not be removed. Implementations already support it, removing would just create confusion. I don't see any harm in keeping it in. > (And I'm actually aware of at least one feature in the solaris IP > stack which is supposedly available for UDP/IPv4 traffic through > AF_INET6 sockets which is not conveniently available through AF_INET > sockets. Long story ...) Just for information comment: not all IPv6/IPv4 is Unix related. For example, Symbian IPv6/IPv4 implemets only *PROTOCOL FAMILY* PF_INET, with two address families AF_INET ja AF_INET6. All sockets are basicly opened for PF_INET (= AF_INET), and will work just fine with IPv4 or IPv6 without any problems for applications (applications don't need to care!). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 31 12:57:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00160 for ; Mon, 31 Jan 2005 12:57:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvg63-0001rn-9H for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 13:16:25 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Cvfo0-0006lN-I1 for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 12:57:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfbS-0002y0-5Q; Mon, 31 Jan 2005 12:44:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfS3-0001iV-8E for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 12:35: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 MAA27135 for ; Mon, 31 Jan 2005 12:34:59 -0500 (EST) Received: from castlerea.stdlib.net ([80.68.89.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvfjz-00017V-Ba for ipv6@ietf.org; Mon, 31 Jan 2005 12:53:37 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1CvfRp-0003UP-Kb; Mon, 31 Jan 2005 17:34:49 +0000 Date: Mon, 31 Jan 2005 17:34:49 +0000 From: Colm MacCarthaigh To: Jeroen Massar Message-ID: <20050131173449.GA13213@castlerea.stdlib.net.> References: <1107190470.27827.134.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1107190470.27827.134.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA27135 Cc: ipv6@ietf.org Subject: Re: AYIYA link local address X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: colm@stdlib.net 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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 05:54:30PM +0100, Jeroen Massar wrote: > Global IPv6 =3D 2001:db8:1234:5678:abcd::1/64 > The link local =3D fe80::db8:1234:5678:abcd:1/64 >=20 > To make the EUI-64 we take the global address,=20 EUI-64 is different from an interface-token, EUI-64 is an ethernet specific algorithim for deriving 64-bit long interface tokens. > which is known and then > ignore the first 32bits, which describe the ISP's TLA, there is nothing > smaller. We then take the next 32bits (1234:5678:abcd) That's 48 bits, not 32 :) And your description doesn't match up with the example above at all. It seems more like you skip the first 16 bits (2001) and then include the next 64 bits.=20 > which togetherwith the first 32bits actually describe the /64. > Assuming that the tunnel stays inside the ISP, this should thus not > cause any collisions, and should be at least quite unique. We then > append the last 16 bits (::1) so that the remote end can use ::2. As > it is not unique we clear the unique bit 7, it is a host thus we clear > bit 8 too. >=20 > Anyone has any arguments against doing it like the above or has a > better suggestion? I'll include it in the upcoming update of the AYIYA > draft. It seems overly complicated. Global uniqueness is a non-requirement of link-local addresses, I can't see why this would change when using tunnel interfaces. It's not clear from your description whether the IPv6 global unicast=20 addresses you have are the ones you later intend to apply to the tunnel interfaces themselves or are the tunnel endpoints for a 6-in-6 tunnel. For tunnel's, it's common to use the underlying protocol identifier as the interface ID. For example for a protocol 41 6-over-4 tunnel, using the IPv4 address is common: fe80::c101:c33d for example. This kind of approach seems much more inline with the idea behind link-local addresses (at least to me anyway). For 6-over-6 ayiya, I'd just use ::1, ::2 and so on, but that's me. --=20 Colm MacC=E1rthaigh Public Key: colm+pgp@stdlib.ne= t -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 31 13:20:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02739 for ; Mon, 31 Jan 2005 13:20:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvgS8-0002Vs-DP for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 13:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvg8P-0001DV-7r; Mon, 31 Jan 2005 13:18:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvg4G-0000Lx-Mu for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 13:14: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 NAA02066 for ; Mon, 31 Jan 2005 13:14:30 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvgMF-0002MM-G6 for ipv6@ietf.org; Mon, 31 Jan 2005 13:33:08 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id D91892400D; Mon, 31 Jan 2005 19:14:24 +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 26093-05; Mon, 31 Jan 2005 19:14:24 +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 590DB2400C; Mon, 31 Jan 2005 19:14:24 +0100 (CET) From: Jeroen Massar To: colm@stdlib.net In-Reply-To: <20050131173449.GA13213@castlerea.stdlib.net.> References: <1107190470.27827.134.camel@firenze.zurich.ibm.com> <20050131173449.GA13213@castlerea.stdlib.net.> Organization: Unfix Date: Mon, 31 Jan 2005 19:14:22 +0100 Message-Id: <1107195262.27827.153.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: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ipv6@ietf.org Subject: Re: AYIYA link local address 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="===============1038114451==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --===============1038114451== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/iVU4wnjEJUAS+7LVhXn" --=-/iVU4wnjEJUAS+7LVhXn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-31 at 17:34 +0000, Colm MacCarthaigh wrote: > On Mon, Jan 31, 2005 at 05:54:30PM +0100, Jeroen Massar wrote: > > Global IPv6 =3D 2001:db8:1234:5678:abcd::1/64 > > The link local =3D fe80::db8:1234:5678:abcd:1/64 > >=20 > > To make the EUI-64 we take the global address,=20 >=20 > EUI-64 is different from an interface-token, EUI-64 is an ethernet > specific algorithim for deriving 64-bit long interface tokens. s/EUI-64/Interface Identifier/ > > which is known and then > > ignore the first 32bits, which describe the ISP's TLA, there is nothing > > smaller. We then take the next 32bits (1234:5678:abcd) >=20 > That's 48 bits, not 32 :) And your description doesn't match up with the > example above at all. It seems more like you skip the first 16 bits > (2001) and then include the next 64 bits.=20 Oops, cut&paste peepup from the old code, indeed mixed it up the first time, caused by the 48/64 border ;) Retry: global =3D 2001:0db8:1234:5678: : : :0001 / 64 local =3D fe80: : : :0db8:1234:5678:0001 / 64 Skip the first 16 bits, use the next 48bits, use the last 16 bits. > It's not clear from your description whether the IPv6 global unicast=20 > addresses you have are the ones you later intend to apply to the > tunnel interfaces themselves or are the tunnel endpoints for a 6-in-6 > tunnel. The global address is for the inner tunnel, thus this applies for both 6-in-6 and 6-in-4. > For tunnel's, it's common to use the underlying protocol identifier > as the interface ID. For example for a protocol 41 6-over-4 tunnel, > using the IPv4 address is common: >=20 > fe80::c101:c33d Correct, but what if you don't know the IPv4 address? Which I don't know in my case. The global IPv6 address is unique and won't change/is stable, which is mentioned in 2373 to be one of the things one should use. > for example. This kind of approach seems much more inline with the idea > behind link-local addresses (at least to me anyway). For 6-over-6 > ayiya, I'd just use ::1, ::2 and so on, but that's me. That indeed works, but then one has fe80::1, say a hundred times on the same machine, which is for debugging purposes also not very handy. Greets, Jeroen --=-/iVU4wnjEJUAS+7LVhXn 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/ iD8DBQBB/nV+KaooUjM+fCMRAu2VAJ9jxxFjpDxgr4OKN7mQVL2EbH6ntgCfVk96 Ki7H7LWSnKMSuuoA5vqfuiE= =R/l4 -----END PGP SIGNATURE----- --=-/iVU4wnjEJUAS+7LVhXn-- --===============1038114451== 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 -------------------------------------------------------------------- --===============1038114451==-- From ipv6-bounces@ietf.org Mon Jan 31 13:49:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06003 for ; Mon, 31 Jan 2005 13:49:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvgtg-0003Ec-KM for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 14:07:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvga7-0005Qz-4w; Mon, 31 Jan 2005 13:47:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvgVl-0004s0-D4 for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 13:42: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 NAA05257 for ; Mon, 31 Jan 2005 13:42:54 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvgnl-00034z-Cd for ipv6@ietf.org; Mon, 31 Jan 2005 14:01:33 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA28219; Mon, 31 Jan 2005 12:42:25 -0600 (CST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0VIgNg10592; Mon, 31 Jan 2005 10:42:24 -0800 (PST) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jan 2005 13:42:22 -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: Mon, 31 Jan 2005 13:42:21 -0500 Message-ID: Thread-Topic: IPv6 Address Architecture update question Thread-Index: AcUHluAOkNcwNT4wQu2/YqoWWCgVwAALJrDg From: "Manfredi, Albert E" To: "Bob Hinden" , "IPv6 WG" X-OriginalArrivalTime: 31 Jan 2005 18:42:22.0147 (UTC) FILETIME=[99932930:01C507C4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Address Architecture update 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.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable I don't know much serious migration to IPv6 has started yet, but I did = think this embedding IPv4 addresses inside IPv6 addresses could be a = useful technique, possibly. Don't know if it will end up being useful, = with 20/20 hindsight. At first blush, it seems to be a way of avoiding = static configuration when creating tunnels. Is there anything in particular, other than "complexity," that motivated = the motion to dismiss? Thanks. Bert > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com] > Sent: Monday, January 31, 2005 7:49 AM > To: IPv6 WG > Subject: IPv6 Address Architecture update question >=20 >=20 > Hi, >=20 > I am working on an update to the IPv6 address architecture. =20 > In doing this=20 > I am working through the comments on the previous draft. One=20 > comment made=20 > was to remove Section 2.5.5 "IPv6 Addresses with Embedded=20 > IPv4 Addresses"=20 > from the document. This would include removing the special=20 > case in the=20 > textual representation (section 2.2, 3.). >=20 > I would like to solicit the working group's thoughts on this.=20 > I don't have=20 > a strong opinion one way or another. It's not clear it has=20 > ever been that=20 > useful and add a certain degree of complexity. On the other hand, it=20 > appears in several places in the document and requires some careful=20 > editing :-) >=20 > Since I expect this is widely implemented, please be sure to=20 > report any=20 > problem that might occur if this is to be removed from the=20 > specification. This includes would it break other documents=20 > that refer to=20 > the IPv6 address architecture specification. >=20 > The plan is to submit the updated draft for Draft Standard. =20 > In general=20 > removing things that are not found to be useful is OK when=20 > going to Draft=20 > standard. >=20 > Thanks, > Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 31 15:26:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16229 for ; Mon, 31 Jan 2005 15:26:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CviQE-0005H1-2f for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 15:45:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvi45-00026r-8V; Mon, 31 Jan 2005 15:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvi2J-0000Yf-BQ for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 15:20: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 PAA15398 for ; Mon, 31 Jan 2005 15:20:37 -0500 (EST) Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CviKJ-00059A-3m for ipv6@ietf.org; Mon, 31 Jan 2005 15:39:16 -0500 Received: from mercury.eng.emc.com (mercury.eng.emc.com [168.159.100.12]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j0VKKV7g025534; Mon, 31 Jan 2005 15:20:32 -0500 (EST) Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2656.59) id ; Mon, 31 Jan 2005 15:20:34 -0500 Message-ID: <759A0BEC1CF75A43B72C9E94ACB19BEC6B9325@srgriese-bkp.lss.emc.com> From: "sasson, shuki" To: Bob Hinden , IPv6 WG Date: Mon, 31 Jan 2005 15:20:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.31.5 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__C230066_P2 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: RE: IPv6 Address Architecture update 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.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, as mentioned before applications do use binding to any IPv6 address to listen any iPv4 address. I have seen it in Linux Fedora Core 3. This helps with porting applications. I don't know why people are calling it "broken". It is all about semantics and definitions. I believe that dropping this section will create confusion and chaos for the already ported applications. It will be much wiser leaving things as they are and allowing the application to bind to only one socket for both IPv4 and IPv6 if they wish. Thanks, Shuki I -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden Sent: Monday, January 31, 2005 7:49 AM To: IPv6 WG Subject: IPv6 Address Architecture update question Hi, I am working on an update to the IPv6 address architecture. In doing this I am working through the comments on the previous draft. One comment made was to remove Section 2.5.5 "IPv6 Addresses with Embedded IPv4 Addresses" from the document. This would include removing the special case in the textual representation (section 2.2, 3.). I would like to solicit the working group's thoughts on this. I don't have a strong opinion one way or another. It's not clear it has ever been that useful and add a certain degree of complexity. On the other hand, it appears in several places in the document and requires some careful editing :-) Since I expect this is widely implemented, please be sure to report any problem that might occur if this is to be removed from the specification. This includes would it break other documents that refer to the IPv6 address architecture specification. The plan is to submit the updated draft for Draft Standard. In general removing things that are not found to be useful is OK when going to Draft standard. Thanks, 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 Mon Jan 31 17:35:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14687 for ; Mon, 31 Jan 2005 17:35:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkQx-00052N-Kw for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 17:54:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjzF-0005vn-BI; Mon, 31 Jan 2005 17:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjRN-0008J5-3d for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 16:50: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 QAA03429 for ; Mon, 31 Jan 2005 16:50:34 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvjjL-0001kG-FB for ipv6@ietf.org; Mon, 31 Jan 2005 17:09:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0VLnoR26177; Mon, 31 Jan 2005 23:49:50 +0200 Date: Mon, 31 Jan 2005 23:49:50 +0200 (EET) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> Message-ID: References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IPv6 WG Subject: Re: IPv6 Address Architecture update 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: b19722fc8d3865b147c75ae2495625f2 On Mon, 31 Jan 2005, Bob Hinden wrote: > > I am working on an update to the IPv6 address architecture. In doing this I > am working through the comments on the previous draft. One comment made was > to remove Section 2.5.5 "IPv6 Addresses with Embedded IPv4 Addresses" from > the document. This would include removing the special case in the textual > representation (section 2.2, 3.). > > I would like to solicit the working group's thoughts on this. I don't have a > strong opinion one way or another. It's not clear it has ever been that > useful and add a certain degree of complexity. On the other hand, it appears > in several places in the document and requires some careful editing :-) It is clear that the mapped addresses are widely used and useful, and a lot of people have raised their concerns about removing that. However, what I think Bob was referring to was the use of IPv4-compatible IPv6 addresses (::1.2.3.4), and refocusing the section (2.5.5 in rfc3513) to be about the mapped addresses. I suggest just simply removing compatibles. Those who are interested of them can always look back at RFC3513. -- 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 Mon Jan 31 17:36:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14859 for ; Mon, 31 Jan 2005 17:36:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkRm-00055T-Lr for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 17:55:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvjzh-0006I2-CI; Mon, 31 Jan 2005 17:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjVT-00026t-JZ for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 16:54: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 QAA04137 for ; Mon, 31 Jan 2005 16:54:48 -0500 (EST) Received: from castlerea.stdlib.net ([80.68.89.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvjnT-0001yR-FU for ipv6@ietf.org; Mon, 31 Jan 2005 17:13:28 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1CvjVF-0004BP-Fs; Mon, 31 Jan 2005 21:54:37 +0000 Date: Mon, 31 Jan 2005 21:54:37 +0000 From: Colm MacCarthaigh To: Jeroen Massar Message-ID: <20050131215437.GA15925@castlerea.stdlib.net.> References: <1107190470.27827.134.camel@firenze.zurich.ibm.com> <20050131173449.GA13213@castlerea.stdlib.net.> <1107195262.27827.153.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1107195262.27827.153.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA04137 Cc: ipv6@ietf.org Subject: Re: AYIYA link local address X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: colm@stdlib.net 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 Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 07:14:22PM +0100, Jeroen Massar wrote: > Correct, but what if you don't know the IPv4 address? Which I don't kno= w > in my case. The global IPv6 address is unique and won't change/is > stable, which is mentioned in 2373 to be one of the things one should > use. In order to construct a stable tunnel, there has to be *some* kind of stable endpoint identifier ;) In the case of ayiya, this seems to be a complex combination of source address and the optional "identity" field, which varies between 0 and 256 bytes in size :/ > > for example. This kind of approach seems much more inline with the id= ea > > behind link-local addresses (at least to me anyway). For 6-over-6 > > ayiya, I'd just use ::1, ::2 and so on, but that's me. >=20 > That indeed works, but then one has fe80::1, say a hundred times on the > same machine, which is for debugging purposes also not very handy. Maybe in the case of ayiya best practise would be to advise such operators to use identities that can double up as interface identifiers (a 32-bit integer will happily suffice) ? --=20 Colm MacC=E1rthaigh Public Key: colm+pgp@stdlib.ne= t -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 31 19:19:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27667 for ; Mon, 31 Jan 2005 19:19:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvm3I-00089N-US for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 19:37:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvlgh-0005zc-OG; Mon, 31 Jan 2005 19:14:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvlUS-0003eD-US for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 19:02: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 TAA25690 for ; Mon, 31 Jan 2005 19:01:54 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvlmT-0007gx-Si for ipv6@ietf.org; Mon, 31 Jan 2005 19:20:36 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Jan 2005 16:01:22 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Jan 2005 16:01:22 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 31 Jan 2005 16:01:22 -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.1289); Mon, 31 Jan 2005 16:01:21 -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: Mon, 31 Jan 2005 16:00:04 -0800 Message-ID: Thread-Topic: Request to Advance: [RESEND] Thread-Index: AcUCRDP9NT9uWUowTU+WYu8f20sswwFrAbmA From: "Dave Thaler" To: "Erik Nordmark" , "Brian E Carpenter" X-OriginalArrivalTime: 01 Feb 2005 00:01:21.0486 (UTC) FILETIME=[298286E0:01C507F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , Margaret Wasserman , Brian Haberman , IPv6 Subject: RE: Request to Advance: [RESEND] 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Catching up on email... I will go through the rest of last weeks responses over the next day or so. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Erik Nordmark > Sent: Monday, January 24, 2005 9:26 AM > To: Brian E Carpenter > Cc: Thomas Narten; Margaret Wasserman; Brian Haberman; IPv6 > Subject: Re: Request to Advance: [RESEND] >=20 > Brian E Carpenter wrote: > > > First, lets keep in mind that this is an Informational document. > > > > I wonder whether Experimental wouldn't send a clearer signal > > that there is some doubt about the viability of the solution. >=20 > That would be better than informational. I have no objection. > But I still think the document should say "MUST prevent loops; SHOULD > run IEEE 802.1D to prevent loops" and then talk about cases when the > protocol is not needed.=20 I agree. > The one example we have is the case of PPP (e.g. > to a GGSN) where the probability of a loop would be very small, so in > that particular case there is no need for 802.1D (and there might be > other examples, but the 802.11 scenario in the document isn't one of > them). > > > I can see how this could be very useful in certain types of > > network environment, and publishing as Experimental will allow > > people to share experience and try to fix the open questions. >=20 > ok >=20 > > Since the deployment future of SEND is unknown, I don't think > > it's appropriate to block this work because of SEND. Right. As Brian pointed out, proxy ND is already part of RFC 2461, and it's already PS. It's also still in draft-ietf-ipv6-2461bis-01.txt which is targeted for DS. The fact that SEND doesn't yet support proxy ND is not specific to this specification, it's something for SEND to solve. I'll respond to other points in subsequent email. -Dave > Yes, but at least the document should be internally inconsistent and not > claim in section 3 that working with SeND is a requirement, even though > it doesn't work with SeND. >=20 > Erik >=20 > -------------------------------------------------------------------- > 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 Jan 31 20:58:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06487 for ; Mon, 31 Jan 2005 20:58:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvnbe-0001sH-L4 for ipv6-web-archive@ietf.org; Mon, 31 Jan 2005 21:17:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvnD8-00075Z-95; Mon, 31 Jan 2005 20:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvnBd-0006mu-US for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 20:50: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 UAA05890 for ; Mon, 31 Jan 2005 20:50:36 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvnTf-0001ig-QK for ipv6@ietf.org; Mon, 31 Jan 2005 21:09:18 -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 j111oXpv010693; Mon, 31 Jan 2005 17:50:33 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j111oXBB463726; Mon, 31 Jan 2005 17:50:33 -0800 (PST) Message-ID: <41FEE03D.2050003@sun.com> Date: Mon, 31 Jan 2005 17:49:49 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler 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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Margaret Wasserman , Brian Haberman , Brian E Carpenter , IPv6 Subject: Re: Request to Advance: [RESEND] 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 Dave Thaler wrote: > The fact that SEND doesn't yet support proxy ND is not specific to > this specification, it's something for SEND to solve. The general case of proxy ND, which this specification uses, can not provide any security against MiTM because by definition the proxy is a MiTM. Thus it is completely unreasonably to assume that SeND will solve this. There are specific cases of proxy for SeND can be extended, that have the property that there exists a security relationship between the host and the proxy. An example of this is a MIP home agent. In such a case one can extend SeND to allow for the mobile node to delegate its key (somehow) to the home agent. But with ndproxy you both want things to be transparent to the hosts, and you want the ndproxy proxies to rewrite the ND packets. You can't do that and prevent other nodes (aka attackers) from forging ND packets. Thus any secure solution in this space requires at least one of: 1. that the host be modified to have a secure relationship with the proxy 2. that the proxies do not modify the ND packets Note that #2 can be done, but it requires that the proxies be able to receive packets addressed to any MAC address (just like bridges do). This is very much analogous to Ralph's comments about DHCP. So expecting SeND to provide security when by design you need MiTMs in the proxies isn't truth in advertising about this protocol. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------