From ipv6-bounces@ietf.org  Fri Apr  1 00:05:48 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20808
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 00:05:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHEEk-0004BM-Lp; Thu, 31 Mar 2005 23:58:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHEEg-0004BF-7Y
	for ipv6@megatron.ietf.org; Thu, 31 Mar 2005 23:58: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 XAA18311
	for <ipv6@ietf.org>; Thu, 31 Mar 2005 23:58:19 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHELv-0000d3-QM
	for ipv6@ietf.org; Fri, 01 Apr 2005 00:05:52 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 396B989862;
	Fri,  1 Apr 2005 07:58:10 +0300 (EEST)
Message-ID: <424CD4CE.6010104@kolumbus.fi>
Date: Fri, 01 Apr 2005 07:57:50 +0300
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "John Spence, CCSI, CCNA, CISSP" <jspence@native6.com>
References: <200504010058.j310wrpm021834@hestia.native6.com>
In-Reply-To: <200504010058.j310wrpm021834@hestia.native6.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
Subject: Re: Seeking clarity on IPv6 IPsec AH requirement ... pending IPsec
 draft changes AH requirement to "MAY" from "MUST" ...
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

I believe the IPsec specifications take precedence here.
Note that the 2401 and AH are also referenced from
draft-ietf-ipv6-node-requirements (currently in RFC Ed
queue). A "bis" version of that RFC-to-be should also
reference the new specs. (Its too late to change now
because the IPsec specs are, I think, still in the WG process
and it might take some time before they can be normatively
referenced without delays.)

--Jari

John Spence, CCSI, CCNA, CISSP wrote:

>Looking at "draft-ietf-ipsec-rfc2401bis-05.txt" (Security Architecture for
>the Internet Protocol), I noticed the "pending confusion" shown below.  The
>IPv6 Specification suggests that both AH and ESP are requirements for full
>IPsec support, and the draft slated to replace the overarching IPsec
>Specification makes it clear that IPsec AH is optional.
>
>We'll need to clarify somewhere if IPv6 is requiring a higher standard than
>the future IPsec Spec, or if the IPsec Spec takes precedence, and a full
>IPv6 IPsec implementation will also consider AH "optional".
>
>My belief is that the IPsec Spec rules here, and IPv6 should only require
>IPsec "as described in the IPsec Spec of record".  Today there is no
>conflict, but there will be when the IPsec draft goes RFC. 
>
>-------------- start --------------------
>
>3.2 How IPsec Works
>
><snip>
>
> IPsec implementations MUST support ESP and MAY
>   support AH. (Support for AH has been downgraded to MAY because
>   experience has shown that there are very few contexts in which ESP
>   cannot provide the requisite security services. 
>
><snip>
>---------------- end ------------------
>
>Looking at RFC 2460, I see this:
>
>-------------- start --------------------
>
>4.  IPv6 Extension Headers
>
><snip>
>
>   A full implementation of IPv6 includes implementation of the
>   following extension headers:
>
>           Hop-by-Hop Options
>           Routing (Type 0)
>           Fragment
>           Destination Options
>           Authentication
>           Encapsulating Security Payload
>
>   The first four are specified in this document; the last two are
>   specified in [RFC-2402] and [RFC-2406], respectively.
>
><snip>
>---------------- end ------------------
>
>----------------------------------------------------
>John Spence, CCSI, CCNA, CISSP
>Native6, Inc.
>IPv6 Training and Consulting
>jspence@native6.com
>www.native6.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 Apr  1 02:14:27 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12907
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 02:14:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHGJg-0007op-Ho; Fri, 01 Apr 2005 02:11:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGJd-0007oi-LH
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 02:11: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 CAA10170
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 02:11:36 -0500 (EST)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGQu-0005C8-H6
	for ipv6@ietf.org; Fri, 01 Apr 2005 02:19:09 -0500
Received: from ocean.jinmei.org (unknown
	[3ffe:501:100f:1048:181f:1de7:a43b:42d9])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 22D8B15218; Fri,  1 Apr 2005 16:11:36 +0900 (JST)
Date: Fri, 01 Apr 2005 16:12:13 +0900
Message-ID: <y7vacojj7hu.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: Brian Haberman <brian@innovationslab.net>
In-Reply-To: <a4a7301e2b94507c054e57dd2f17882e@innovationslab.net>
References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net>
	<a4a7301e2b94507c054e57dd2f17882e@innovationslab.net>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
	(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: Bob Hinden <bob.hinden@nokia.com>, IPv6 WG <ipv6@ietf.org>
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Tue, 29 Mar 2005 13:32:55 -0500, 
>>>>> Brian Haberman <brian@innovationslab.net> said:

>       The WG Last Call ended almost two months ago with no comments
> received.  There was some in-depth conversation about this document
> during the Washington D.C. meeting.  I need those people who raised
> issues with the -01 version to indicate that those issues were resolved
> in this -02 version.

Sorry for the delayed response.  I've checked the latest draft,
recalling my comments on the previous version:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg03875.html

I'm NOT opposing to submitting the 02 version to the IESG, but I still
have some comments on it (which may be addressed with IESG feedback).

1. Regarding comment 1 in "msg03875.html", I'd also revise the first
   sentence of Section 1.1

   From:
     Addresses generated using Stateless address autoconfiguration
     [ADDRCONF]contain an embedded 64-bit interface identifier, which
     remains constant over time.

  To:
     Addresses generated using Stateless address autoconfiguration
     [ADDRCONF] contain an embedded interface identifier, which
     remains constant over time.

  In this context, the point should be that the interface identifier
  remains constant, and the exact number of ID length (64-bit) is
  rather minor.  Thus, removing the number should be safe, and is
  actually more aligned with the latest sense of rfc2462bis.

2. Comment 3 in "msg03875.html" does not seem to be addressed.
   Perhaps this is too minor, however, and I could live with the
   current text.

3. I'd like to see more clarity for comment 6 in "msg03875.html".  How
   about changing the first paragraph of Section 2.4

From:
   One way to avoid having a static non-changing address is to use
   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could be
   configured to hand out addresses that change over time.  But DHCPv6
   will solve the privacy issue only if it frequently handed out
   constantly changing addresses to the nodes.  Since this does not
   happen automatically, and is difficult to configure manually, DHCPv6
   is not a self contained alternative for solving the privacy issues
   addressed by this document.  However, in the absence of stateless
   address autoconfiguration, DHCPv6 can be used for distributing
   temporary addresses to clients.

To:
   One way to avoid having a static non-changing address is to use
   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could
   be configured to hand out addresses that change over time.  But
   DHCPv6 will solve the privacy issue only if it frequently handed
   out constantly changing addresses to the nodes or if the DHCPv6
   client moves from links to links frequently, being allocated
   independent addresses from different DHCPv6 servers.  However, the
   former does not happen automatically, and is difficult to configure
   manually; the latter cannot be assumed for static (not frequently
   moving) hosts.  Thus, DHCPv6 is not a self contained alternative
   for solving the privacy issues addressed by this document.
   However, in the absence of stateless address autoconfiguration,
   DHCPv6 can be used for distributing temporary addresses to clients.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  1 02:54:32 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23604
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 02:54:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHGrB-0007N4-1o; Fri, 01 Apr 2005 02:46:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGqn-0007Jn-2V
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 02:45: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 CAA22811
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 02:45:51 -0500 (EST)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGy4-0006Ir-I8
	for ipv6@ietf.org; Fri, 01 Apr 2005 02:53:24 -0500
Received: from ocean.jinmei.org (unknown
	[3ffe:501:100f:1048:181f:1de7:a43b:42d9])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 5667315218; Fri,  1 Apr 2005 16:45:52 +0900 (JST)
Date: Fri, 01 Apr 2005 16:46:31 +0900
Message-ID: <y7v8y43j5wo.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: Brian Haberman <brian@innovationslab.net>
In-Reply-To: <y7vacojj7hu.wl@ocean.jinmei.org>
References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net>
	<a4a7301e2b94507c054e57dd2f17882e@innovationslab.net>
	<y7vacojj7hu.wl@ocean.jinmei.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: ea4ac80f790299f943f0a53be7e1a21a
Cc: IPv6 WG <ipv6@ietf.org>, Bob Hinden <bob.hinden@nokia.com>
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Fri, 01 Apr 2005 16:12:13 +0900, 
>>>>> JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> said:

>> The WG Last Call ended almost two months ago with no comments
>> received.  There was some in-depth conversation about this document
>> during the Washington D.C. meeting.  I need those people who raised
>> issues with the -01 version to indicate that those issues were resolved
>> in this -02 version.

> Sorry for the delayed response.  I've checked the latest draft,
> recalling my comments on the previous version:
>   http://www1.ietf.org/mail-archive/web/ipv6/current/msg03875.html

> I'm NOT opposing to submitting the 02 version to the IESG, but I still
> have some comments on it (which may be addressed with IESG feedback).

I forgot to add one more thing.  This is not related to my previous
comments, but will probably be an issue later, so I think it's worth
raising at this point.

4. The normative reference to [ADDR_SELECT] (RFC3484) will cause a
   down-reference problem (privacy-addrs-v2 will become a DS while
   RFC3484 is a PS).  As far as I can see, I think we can safely
   categorize this reference as an informative one, which is the
   easiest resolution to this type of issue.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  1 03:24:19 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01698
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 03:24:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHHPN-00048m-OS; Fri, 01 Apr 2005 03:21:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHOc-0003y6-QG
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 03:20: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 DAA01275
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 03:20:47 -0500 (EST)
From: du.ke@zte.com.cn
Received: from [202.103.147.144] (helo=zte.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHHNA-0007Df-Sd
	for ipv6@ietf.org; Fri, 01 Apr 2005 03:19:28 -0500
Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id
	68829.1320096835; Fri, 1 Apr 2005 16:50:03 +0800 (CST)
To: ipv6@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF6A1FAB4C.C3FD1BB1-ON48256FD6.002D164E-48256FD6.002CFE0E@zte.com.cn>
Date: Fri, 1 Apr 2005 16:14:17 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September
	14, 2004) at 2005-04-01 16:11:20,
	Serialize complete at 2005-04-01 16:11:20
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Subject: a nit in RFC 2460
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0215071609=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

This is a multipart message in MIME format.
--===============0215071609==
Content-Type: multipart/alternative;
	boundary="=_alternative 002CFE0A48256FD6_="

This is a multipart message in MIME format.
--=_alternative 002CFE0A48256FD6_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

c29ycnksIGkgbWlzdGFrZSBpdC4NCg0KDQpSZWdhcmQsDQpEdSBLZQ0KPi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uFiANCj5BZGQ6ICAgTm8uNjggWmlqaW5n
aHVhIFJkLFl1aHVhdGFpIERpc3RyaWN0LCANCj4gICAgICAgIE5hbmppbmcuIFAuUi5DaGluYS4g
DQo+WmlwOiAgIDIxMDAxMiANCj5UZWw6ICAgMDA4Ni0yNS01Mjg3MTE3OSANCj5GYXg6ICAgMDA4
Ni0yNS01Mjg3MTAwMCANCj5NYWlsOiAgZHUua2VAenRlLmNvbS5jbiANCj4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gDQoNCi0tLS0tIOi9rOWPkeS6uiDpg73n
j4IxMTEwNTkvdXNlci96dGVfbHRkIOaXtumXtCAyMDA1LTA0LTAxIDE2OjA5IC0tLS0tDQoNCg0K
6YO954+CMTExMDU5DQrpg73nj4Iv57O757uf6YOoL+eglOeptuaJgC/mlbDmja7kuovkuJrpg6gv
5Lit5YW06YCa6K6vDQoyMDA1LTAzLTMxIDE3OjEwDQogDQogICAgICAgIOaUtuS7tuS6uu+8miAg
ICAgICAgaXB2NkBpZXRmLm9yZw0KICAgICAgICDmioTpgIHvvJogDQogICAgICAgIOS4u+mimO+8
miAgYSBuaXQgaW4gUkZDIDI0NjANCg0KRGVlcmluZywgSGluZGVuLCBhbmQgYWxsLA0KDQpJIHRo
aW5rIGl0J3MgbWF5YmUgYSBuaXQgaW4gUkZDMjQ2MC4NCg0KYXMgZGVzY3JpYmluZyBpbiBzZWN0
aW9uIDQuMiwgdGhlICJPcHQgRGF0YSBMZW4iIGlzICJMZW5ndGggb2YgdGhlIE9wdGlvbiANCkRh
dGEgZmllbGQgb2YgdGhpcyBvcHRpb24sIGluIG9jdGV0cy4iDQoNCmJ1dCwgaW4gc2VjdGlvbiA0
LjMgKEhvcC1ieS1Ib3AgT3B0aW9ucyBIZWFkZXIpLCBwYWdlIDExLCBpdCdzIHNhaWQsDQoNCiIg
ICBIZHIgRXh0IExlbiAgICAgICAgICA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgTGVuZ3RoIG9m
IHRoZSBIb3AtYnktDQogICAgICAgICAgICAgICAgICAgICAgICBIb3AgT3B0aW9ucyBoZWFkZXIg
aW4gOC1vY3RldCB1bml0cywgbm90DQogICAgICAgICAgICAgICAgICAgICAgICBpbmNsdWRpbmcg
dGhlIGZpcnN0IDggb2N0ZXRzLiINCg0Kd2hlcmUsIHRoZSB3b3JkICJpbiA4LW9jdGV0IHVuaXRz
IiBzaG91bGQgYmUgImluIG9jdGV0cyIsIGFuZCAidGhlIGZpcnN0IDggDQpvY3RldHMiIHNob3Vs
ZCBiZSAidGhlIGZpcnN0IG9jdGV0Ii4NCg0KdGhlcmUgYXJlIHRoZSBzYW1lIG5pdHMgaW4gcGFn
ZSAxMiwgMTQsIGFuZCAyMy4NCg0KUmVnYXJkLA0KRHUgS2UNCj4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLhYgDQo+QWRkOiAgIE5vLjY4IFppamluZ2h1YSBS
ZCxZdWh1YXRhaSBEaXN0cmljdCwgDQo+ICAgICAgICBOYW5qaW5nLiBQLlIuQ2hpbmEuIA0KPlpp
cDogICAyMTAwMTIgDQo+VGVsOiAgIDAwODYtMjUtNTI4NzExNzkgDQo+RmF4OiAgIDAwODYtMjUt
NTI4NzEwMDAgDQo+TWFpbDogIGR1LmtlQHp0ZS5jb20uY24gDQo+Li4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIA0KDQoKCgoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKgrQxc+isLLIq8n5w/ejurG+08q8/rD8uqzQxc+iuela
VEXL+dPQo6wKWlRFttS4w9PKvP7TtdPQy/nT0MiowPuho8frvdPK1dXf16LS4gqxo8Pco6zOtL6t
t6K8/sjLyunD5tDtv8mjrLK7tcPP8sjOus612grI/be91+nWr7rNuPbIy824wraxvtPKvP7L+bqs
0MXPorXEyKuyvwq78rK/t9aho9LUyc/J+cP3vfbKytPD09q5pNf308q8/qGjCkluZm9ybWF0aW9u
IFNlY3VyaXR5ICBOb3RpY2WjugpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp
bCBpcwpzb2xlbHkgcHJvcGVydHkgb2YgIFpURSBDb3Jwb3JhdGlvbi4gClRoaXMgbWFpbCBjb21t
dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4KUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js
aWdhdGVkIHRvCm1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvCmRpc2Ns
b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24KdG8gb3RoZXJzLgoqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=
--=_alternative 002CFE0A48256FD6_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNvcnJ5LCBpIG1pc3Rha2UgaXQu
PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5S
ZWdhcmQsPGJyPg0KRHUgS2U8YnI+DQomZ3Q7Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4WIDxicj4NCiZndDtBZGQ6ICZuYnNwOyBOby42OCBaaWppbmdodWEg
UmQsWXVodWF0YWkgRGlzdHJpY3QsIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7TmFuamluZy4gUC5SLkNoaW5hLiA8YnI+DQomZ3Q7WmlwOiAmbmJzcDsgMjEwMDEyIDxicj4N
CiZndDtUZWw6ICZuYnNwOyAwMDg2LTI1LTUyODcxMTc5IDxicj4NCiZndDtGYXg6ICZuYnNwOyAw
MDg2LTI1LTUyODcxMDAwIDxicj4NCiZndDtNYWlsOiAmbmJzcDtkdS5rZUB6dGUuY29tLmNuIDxi
cj4NCiZndDsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gPGJy
Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jODAwMDgwIGZhY2U9InNhbnMtc2Vy
aWYiPi0tLS0tIOi9rOWPkeS6uiDpg73nj4IxMTEwNTkvdXNlci96dGVfbHRkDQrml7bpl7QgMjAw
NS0wNC0wMSAxNjowOSAtLS0tLTwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy
IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi
PumDveePgjExMTA1OTwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPumDveePgi/ns7vnu5/pg6gv56CU56m25omAL+aVsOaNruS6i+S4mumDqC/kuK3lhbTpgJro
rq88L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwNS0wMy0zMSAx
NzoxMDwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi
PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyDmlLbku7bkurrvvJoNCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO2lwdjZAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyDmioTpgIHvvJoNCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IOS4u+mimO+8mg0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7YSBuaXQgaW4gUkZDIDI0NjA8L2ZvbnQ+PC90YWJsZT4NCjxicj4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RGVlcmluZywgSGluZGVuLCBhbmQg
YWxsLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0
aGluayBpdCdzIG1heWJlIGEgbml0IGluIFJGQzI0NjAuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcyBkZXNjcmliaW5nIGluIHNlY3Rpb24gNC4yLCB0
aGUgJnF1b3Q7T3B0DQpEYXRhIExlbiZxdW90OyBpcyAmcXVvdDtMZW5ndGggb2YgdGhlIE9wdGlv
biBEYXRhIGZpZWxkIG9mIHRoaXMgb3B0aW9uLA0KaW4gb2N0ZXRzLiZxdW90OzwvZm9udD4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YnV0LCBpbiBzZWN0aW9uIDQu
MyAoSG9wLWJ5LUhvcCBPcHRpb25zDQpIZWFkZXIpLCBwYWdlIDExLCBpdCdzIHNhaWQsPC9mb250
Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsgJm5ic3A7
IEhkciBFeHQgTGVuICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7OC1iaXQgdW5z
aWduZWQgaW50ZWdlci4gJm5ic3A7TGVuZ3RoIG9mIHRoZSBIb3AtYnktPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
SG9wIE9wdGlvbnMgaGVhZGVyIGluIDgtb2N0ZXQNCnVuaXRzLCBub3Q8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBp
bmNsdWRpbmcgdGhlIGZpcnN0IDggb2N0ZXRzLiZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+d2hlcmUsIHRoZSB3b3JkICZxdW90O2luIDgtb2N0
ZXQgdW5pdHMmcXVvdDsNCnNob3VsZCBiZSAmcXVvdDtpbiBvY3RldHMmcXVvdDssIGFuZCAmcXVv
dDt0aGUgZmlyc3QgOCBvY3RldHMmcXVvdDsgc2hvdWxkDQpiZSAmcXVvdDt0aGUgZmlyc3Qgb2N0
ZXQmcXVvdDsuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij50aGVyZSBhcmUgdGhlIHNhbWUgbml0cyBpbiBwYWdlIDEyLA0KMTQsIGFuZCAyMy48L2ZvbnQ+
DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZCw8YnI+DQpE
dSBLZTxicj4NCiZndDsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLhYgPGJyPg0KJmd0O0FkZDogJm5ic3A7IE5vLjY4IFppamluZ2h1YSBSZCxZdWh1YXRhaSBE
aXN0cmljdCwgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOYW5qaW5nLiBQ
LlIuQ2hpbmEuIDxicj4NCiZndDtaaXA6ICZuYnNwOyAyMTAwMTIgPGJyPg0KJmd0O1RlbDogJm5i
c3A7IDAwODYtMjUtNTI4NzExNzkgPGJyPg0KJmd0O0ZheDogJm5ic3A7IDAwODYtMjUtNTI4NzEw
MDAgPGJyPg0KJmd0O01haWw6ICZuYnNwO2R1LmtlQHp0ZS5jb20uY24gPGJyPg0KJmd0Oy4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiA8YnI+DQo8L2ZvbnQ+DQo8
YnI+PGJyPjxicj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Kio8YnI+CtDFz6KwssiryfnD96O6sb7Tyrz+sPy6rNDFz6K56VpURcv509CjrDxicj4KWlRFttS4
w9PKvP7TtdPQy/nT0MiowPuho8frvdPK1dXf16LS4jxicj4KsaPD3KOszrS+rbeivP7Iy8rpw+bQ
7b/Jo6yyu7XDz/LIzrrOtdo8YnI+Csj9t73X6davus249sjLzbjCtrG+08q8/sv5uqzQxc+itcTI
q7K/PGJyPgq78rK/t9aho9LUyc/J+cP3vfbKytPD09q5pNf308q8/qGjPGJyPgpJbmZvcm1hdGlv
biZuYnNwO1NlY3VyaXR5Jm5ic3A7Jm5ic3A7Tm90aWNlo7o8YnI+ClRoZSZuYnNwO2luZm9ybWF0
aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzPGJy
Pgpzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7Jm5ic3A7WlRFJm5ic3A7Q29ycG9y
YXRpb24uJm5ic3A7PGJyPgpUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp
cyZuYnNwO2NvbmZpZGVudGlhbC48YnI+ClJlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3Zl
Jm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG88YnI+Cm1haW50YWluJm5ic3A7c2VjcmVj
eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvPGJyPgpk
aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t
bXVuaWNhdGlvbjxicj4KdG8mbmJzcDtvdGhlcnMuPGJyPgoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKjxicj4K
--=_alternative 002CFE0A48256FD6_=--


--===============0215071609==
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
--------------------------------------------------------------------

--===============0215071609==--



From ipv6-bounces@ietf.org  Fri Apr  1 08:28:20 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24126
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 08:28:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHLxw-0000ou-97; Fri, 01 Apr 2005 08:13:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLxu-0000op-GD
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 08:13: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 IAA22528
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 08:13:31 -0500 (EST)
Received: from e33.co.us.ibm.com ([32.97.110.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM5E-0001M1-Nt
	for ipv6@ietf.org; Fri, 01 Apr 2005 08:21:09 -0500
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com
	[9.17.195.11])
	by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j31DDO4I273500
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 08:13:24 -0500
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j31DDNxS231772 for <ipv6@ietf.org>; Fri, 1 Apr 2005 06:13:24 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j31DDNEi026135 for <ipv6@ietf.org>; Fri, 1 Apr 2005 06:13:23 -0700
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com
	[9.17.195.144])
	by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j31DDNvR026129 for <ipv6@ietf.org>; Fri, 1 Apr 2005 06:13:23 -0700
In-Reply-To: <y7vr7hvjjnj.wl@ocean.jinmei.org>
To: ipv6@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OF8DDF5407.BE291018-ON87256FD6.0048182D-85256FD6.0048A2C7@us.ibm.com>
From: Kristine Adamson <adamson@us.ibm.com>
Date: Fri, 1 Apr 2005 06:13:22 -0700
X-MIMETrack: S/MIME Sign by Notes Client on Kristine
	Adamson/Raleigh/IBM(Release 6.0.3|September
	26, 2003) at 04/01/2005 08:13:22 AM,
	Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release
	6.0.3|September 26, 2003) at 04/01/2005 08:13:22 AM,
	Serialize complete at 04/01/2005 08:13:22 AM,
	S/MIME Sign failed at 04/01/2005 08:13:22 AM: The cryptographic key was
	not found,
	Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta
	3|January 11, 2005) at 04/01/2005 06:13:23,
	Serialize complete at 04/01/2005 06:13:23
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0269696151=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

This is a multipart message in MIME format.
--===============0269696151==
Content-Type: multipart/alternative;
	boundary="=_alternative 0048A2C085256FD6_="

This is a multipart message in MIME format.
--=_alternative 0048A2C085256FD6_=
Content-Type: text/plain; charset="US-ASCII"

Thanks for the responses.  But if RFC3542 is not updated, won't this 
adversely affect the portability of applications that references these new 
codes?  If implementers define their own constant names for these codes in 
their icmp6.h files, then you may not be able to compile the source of the 
same application on different platforms.  Thanks,

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Internet e-mail:adamson@us.ibm.com


JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM:

> >>>>> On Thu, 31 Mar 2005 06:13:37 -0700,
> >>>>> Kristine Adamson <adamson@us.ibm.com> said:

> >    Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to 
the
> > Destination Unreachable type.  RFC3542, Advanced Sockets Application
> > Program Interface (API) for IPv6, provides the programming definitions 
for
> > the ICMPv6 types/codes.  RFC3542 already defines one of the new codes:
> > #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source 
address
> > */

> > Will RFC3542 be updated to include the definitions for the additional 
2
> > new codes:
> > 5 - source address failed ingress/egress policy
> > 6 - reject route to destination

> Perhaps yes, although I think introducing just two new ICMPv6 types
> doesn't require a revision of RFC3542.  Someday, when we have enough
> possible updates for the API, a new version will include the new
> ICMPv6 types.

> 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
> --------------------------------------------------------------------
--=_alternative 0048A2C085256FD6_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Thanks for the responses. &nbsp;But if RFC3542 is
not updated, won't this adversely affect the portability of applications
that references these new codes? &nbsp;If implementers define their own
constant names for these codes in their icmp6.h files, then you may not
be able to compile the source of the same application on different platforms.
&nbsp;Thanks,</tt></font>
<br><font size=2><tt><br>
Kristine Adamson<br>
IBM z/OS Communications Server: TCP/IP Development<br>
Internet e-mail:adamson@us.ibm.com</tt></font><font size=2 face="sans-serif"><br>
</font>
<br>
<br><font size=2><tt>JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM:<br>
<br>
&gt; &gt;&gt;&gt;&gt;&gt; On Thu, 31 Mar 2005 06:13:37 -0700,<br>
&gt; &gt;&gt;&gt;&gt;&gt; Kristine Adamson &lt;adamson@us.ibm.com&gt; said:<br>
</tt></font>
<br><font size=2><tt>&gt; &gt; &nbsp; &nbsp;Draft draft-ietf-ipngwg-icmp-v3-06.txt
adds 3 new ICMPv6 codes to the<br>
&gt; &gt; Destination Unreachable type. &nbsp;RFC3542, Advanced Sockets
Application<br>
&gt; &gt; Program Interface (API) for IPv6, provides the programming definitions
for<br>
&gt; &gt; the ICMPv6 types/codes. &nbsp;RFC3542 already defines one of
the new codes:<br>
&gt; &gt; #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source
address<br>
&gt; &gt; */<br>
</tt></font>
<br><font size=2><tt>&gt; &gt; Will RFC3542 be updated to include the definitions
for the additional 2<br>
&gt; &gt; new codes:<br>
&gt; &gt; 5 - source address failed ingress/egress policy<br>
&gt; &gt; 6 - reject route to destination<br>
</tt></font>
<br><font size=2><tt>&gt; Perhaps yes, although I think introducing just
two new ICMPv6 types<br>
&gt; doesn't require a revision of RFC3542. &nbsp;Someday, when we have
enough<br>
&gt; possible updates for the API, a new version will include the new<br>
&gt; ICMPv6 types.<br>
</tt></font>
<br><font size=2><tt>&gt; JINMEI, Tatuya<br>
&gt; Communication Platform Lab.<br>
&gt; Corporate R&amp;D Center, Toshiba Corp.<br>
&gt; jinmei@isl.rdc.toshiba.co.jp</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; --------------------------------------------------------------------<br>
&gt; IETF IPv6 working group mailing list<br>
&gt; ipv6@ietf.org<br>
&gt; Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6<br>
&gt; --------------------------------------------------------------------</tt></font>
--=_alternative 0048A2C085256FD6_=--


--===============0269696151==
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
--------------------------------------------------------------------

--===============0269696151==--



From ipv6-bounces@ietf.org  Fri Apr  1 11:38:01 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13118
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 11:38:01 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHP3W-0002wf-I1; Fri, 01 Apr 2005 11: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 1DHP3U-0002wa-UG
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 11:31:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11815
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 11:31:30 -0500 (EST)
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPAq-0000fU-TK
	for ipv6@ietf.org; Fri, 01 Apr 2005 11:39:09 -0500
Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se
	[138.85.133.52])
	by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j31GWuCR028996;
	Fri, 1 Apr 2005 10:32:56 -0600 (CST)
Received: from noah.lmc.ericsson.se ([142.133.1.1]) by
	eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id H7V6Z6G4; Fri, 1 Apr 2005 10:31:22 -0600
Received: from [142.133.72.115] ([142.133.72.115])
	by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j31GVEXq014172; 
	Fri, 1 Apr 2005 11:31:16 -0500 (EST)
Date: Fri, 1 Apr 2005 11:29:06 -0500 (EST)
X-Sybari-Trust: ab7fb335 b10726bd 552e0e9e 00000139
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
X-X-Sender: suresh@localhost.localdomain
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
In-Reply-To: <y7vacojj7hu.wl@ocean.jinmei.org>
Message-ID: <Pine.LNX.4.61.0504011035580.5258@localhost.localdomain>
References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net>
	<a4a7301e2b94507c054e57dd2f17882e@innovationslab.net>
	<y7vacojj7hu.wl@ocean.jinmei.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: IPv6 WG <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Suresh Krishnan <suresh.krishnan@ericsson.com>
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi Jinmei,
   Thanks for taking the time to verify the changes. See comments inline.

Thanks
Suresh

> 1. Regarding comment 1 in "msg03875.html", I'd also revise the first
>   sentence of Section 1.1
>
>   From:
>     Addresses generated using Stateless address autoconfiguration
>     [ADDRCONF]contain an embedded 64-bit interface identifier, which
>     remains constant over time.
>
>  To:
>     Addresses generated using Stateless address autoconfiguration
>     [ADDRCONF] contain an embedded interface identifier, which
>     remains constant over time.
>
>  In this context, the point should be that the interface identifier
>  remains constant, and the exact number of ID length (64-bit) is
>  rather minor.  Thus, removing the number should be safe, and is
>  actually more aligned with the latest sense of rfc2462bis.

I have the following text in the introduction which restricts the scope of 
the document to 64 bit identifiers.

" Note that an IPv6 identifier does not necessarily have to be 64 bits in
   length, but the algorithm specified in this document is targeted towards
   64-bit interface identifiers."

Do you still want me to make this change?

>
> 2. Comment 3 in "msg03875.html" does not seem to be addressed.
>   Perhaps this is too minor, however, and I could live with the
>   current text.

The concerns are described in section 2.3. I did not want to repeat them 
here. However, I can rephrase the sentence
from

" The focus of this document is on addresses derived from IEEE identifiers,
   as the concern being addressed exists only in those cases where the
   interface identifier is globally unique and non-changing"

to

" The focus of this document is on addresses derived from IEEE identifiers,
   because an interface identifier that is globally unique and non-changing
   can facilitate the tracking of individual devices and possibly users
   of those devices."

Is that OK?

>
> 3. I'd like to see more clarity for comment 6 in "msg03875.html".  How
>   about changing the first paragraph of Section 2.4
>
> From:
>   One way to avoid having a static non-changing address is to use
>   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could be
>   configured to hand out addresses that change over time.  But DHCPv6
>   will solve the privacy issue only if it frequently handed out
>   constantly changing addresses to the nodes.  Since this does not
>   happen automatically, and is difficult to configure manually, DHCPv6
>   is not a self contained alternative for solving the privacy issues
>   addressed by this document.  However, in the absence of stateless
>   address autoconfiguration, DHCPv6 can be used for distributing
>   temporary addresses to clients.
>
> To:
>   One way to avoid having a static non-changing address is to use
>   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could
>   be configured to hand out addresses that change over time.  But
>   DHCPv6 will solve the privacy issue only if it frequently handed
>   out constantly changing addresses to the nodes or if the DHCPv6
>   client moves from links to links frequently, being allocated
>   independent addresses from different DHCPv6 servers.  However, the
>   former does not happen automatically, and is difficult to configure
>   manually; the latter cannot be assumed for static (not frequently
>   moving) hosts.  Thus, DHCPv6 is not a self contained alternative
>   for solving the privacy issues addressed by this document.
>   However, in the absence of stateless address autoconfiguration,
>   DHCPv6 can be used for distributing temporary addresses to clients.

Looks good. I will use your suggested text.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  1 12:24:13 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18531
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 12:24:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHPq9-0006G8-7I; Fri, 01 Apr 2005 12:21:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPq7-0006G0-JU
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 12:21: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 MAA18145
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 12:21:45 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPxT-0003BM-Qw
	for ipv6@ietf.org; Fri, 01 Apr 2005 12:29:24 -0500
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-4.cisco.com with ESMTP; 01 Apr 2005 09:21:38 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j31HLX3S022546
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 09:21:34 -0800 (PST)
Received: from anparthaw2k03 (sjc-vpn4-985.cisco.com [10.21.83.216])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AXW18620;
	Fri, 1 Apr 2005 09:21:33 -0800 (PST)
Message-Id: <200504011721.AXW18620@mira-sjc5-e.cisco.com>
From: "Anand Parthasarathy" <anpartha@cisco.com>
To: <ipv6@ietf.org>
Date: Fri, 1 Apr 2005 09:21:33 -0800
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcU230AKTz7SrkoETeqog+ATXIApmw==
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
X-Spam-Score: 0.8 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Subject: Question on VRRP for IPv6
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1228354382=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1228354382==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009D_01C5369C.320ABDD0"

This is a multi-part message in MIME format.

------=_NextPart_000_009D_01C5369C.320ABDD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi, 
 
I had posted this question on the VRRP working group but got no response.
So, I thought I will try it out here.
 
If the link-local IPv6 address of Router R1 (that is the primary owner) is
backed by R2 and R2 is the current master (assume that R1 is down), what
will happen if Router R1 comes up? The expected behaviour is that R1 should
become master as its priority is 255. But, its DAD will fail for the
link-local IPv6 address and so, it will be unable to become master (The
current master which has the lower priority has joined the Solicited Node
Multicast IPv6 Address and will respond to NS for this address). Could
someone comment on this? Is the only solution for this to disable DAD on
such interfaces? 
 
Thanks,
Anand.

------=_NextPart_000_009D_01C5369C.320ABDD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D557001317-01042005><FONT face=3DArial size=3D2>Hi,=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D557001317-01042005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D557001317-01042005><FONT face=3DArial size=3D2>I had =
posted this=20
question on the VRRP working group but got no response. So, I thought I =
will try=20
it out here.</FONT></SPAN></DIV>
<DIV><SPAN class=3D557001317-01042005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D557001317-01042005><FONT face=3DArial =
size=3D2><!--StartFragment --><SPAN class=3D720110318-25032005><FONT =
face=3DArial=20
size=3D2>If the link-local IPv6 address of Router R1 (that is the =
primary owner)=20
is backed by R2 and R2 is the current master (assume that R1 is down), =
what will=20
happen if Router R1 comes up? The expected behaviour is that R1 should =
become=20
master as its priority is 255. But, its DAD will fail for the link-local =
IPv6=20
address&nbsp;and so, it will&nbsp;be unable to&nbsp;become master (The =
current=20
master which has the lower priority has joined the Solicited Node =
Multicast IPv6=20
Address and will respond to NS for this address).&nbsp;Could someone =
comment on=20
this? Is the only solution for this to disable DAD on such interfaces?=20
</FONT></SPAN>
<DIV><SPAN class=3D720110318-25032005></SPAN><SPAN =
class=3D720110318-25032005><FONT=20
face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D720110318-25032005><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D720110318-25032005><FONT face=3DArial=20
size=3D2>Anand.</FONT></SPAN></DIV></FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_009D_01C5369C.320ABDD0--


--===============1228354382==
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
--------------------------------------------------------------------

--===============1228354382==--



From ipv6-bounces@ietf.org  Fri Apr  1 12:24:16 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13117
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 11:38:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHP65-0003tM-R5; Fri, 01 Apr 2005 11:34:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP64-0003tA-3h
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 11:34: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 LAA12506
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 11:34:09 -0500 (EST)
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPDO-0000uw-Tn
	for ipv6@ietf.org; Fri, 01 Apr 2005 11:41:48 -0500
Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se
	[138.85.133.52])
	by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j31GZYCR029884;
	Fri, 1 Apr 2005 10:35:34 -0600 (CST)
Received: from noah.lmc.ericsson.se ([142.133.1.1]) by
	eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id H7V6Z6NW; Fri, 1 Apr 2005 10:34:00 -0600
Received: from [142.133.72.115] ([142.133.72.115])
	by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j31GY0Xq014281; 
	Fri, 1 Apr 2005 11:34:00 -0500 (EST)
Date: Fri, 1 Apr 2005 11:31:52 -0500 (EST)
X-Sybari-Trust: 057df0e5 b10726bd 552e0e9e 00000139
From: Suresh Krishnan <suresh.krishnan@ericsson.ca>
X-X-Sender: suresh@localhost.localdomain
To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
In-Reply-To: <8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se>
Message-ID: <Pine.LNX.4.61.0504011131290.5258@localhost.localdomain>
References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net>
	<a4a7301e2b94507c054e57dd2f17882e@innovationslab.net>
	<y7vacojj7hu.wl@ocean.jinmei.org>
	<8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: IPv6 WG <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>,
        Bob Hinden <bob.hinden@nokia.com>,
        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Suresh Krishnan <suresh.krishnan@ericsson.com>
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi Jinmei,
  Thanks for taking the time to verify the changes. See comments inline.

Thanks
Suresh

> 1. Regarding comment 1 in "msg03875.html", I'd also revise the first
>   sentence of Section 1.1
> 
>   From:
>     Addresses generated using Stateless address autoconfiguration
>     [ADDRCONF]contain an embedded 64-bit interface identifier, which
>     remains constant over time.
> 
>  To:
>     Addresses generated using Stateless address autoconfiguration
>     [ADDRCONF] contain an embedded interface identifier, which
>     remains constant over time.
> 
>  In this context, the point should be that the interface identifier
>  remains constant, and the exact number of ID length (64-bit) is
>  rather minor.  Thus, removing the number should be safe, and is
>  actually more aligned with the latest sense of rfc2462bis.

I have the following text in the introduction which restricts the scope of the
document to 64 bit identifiers.

" Note that an IPv6 identifier does not necessarily have to be 64 bits in
  length, but the algorithm specified in this document is targeted towards
  64-bit interface identifiers."

Do you still want me to make this change?

> 
> 2. Comment 3 in "msg03875.html" does not seem to be addressed.
>   Perhaps this is too minor, however, and I could live with the
>   current text.

The concerns are described in section 2.3. I did not want to repeat them here.
However, I can rephrase the sentence
from

" The focus of this document is on addresses derived from IEEE identifiers,
  as the concern being addressed exists only in those cases where the
  interface identifier is globally unique and non-changing"

to

" The focus of this document is on addresses derived from IEEE identifiers,
  because an interface identifier that is globally unique and non-changing
  can facilitate the tracking of individual devices and possibly users
  of those devices."

Is that OK?

> 
> 3. I'd like to see more clarity for comment 6 in "msg03875.html".  How
>   about changing the first paragraph of Section 2.4
> 
> From:
>   One way to avoid having a static non-changing address is to use
>   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could be
>   configured to hand out addresses that change over time.  But DHCPv6
>   will solve the privacy issue only if it frequently handed out
>   constantly changing addresses to the nodes.  Since this does not
>   happen automatically, and is difficult to configure manually, DHCPv6
>   is not a self contained alternative for solving the privacy issues
>   addressed by this document.  However, in the absence of stateless
>   address autoconfiguration, DHCPv6 can be used for distributing
>   temporary addresses to clients.
> 
> To:
>   One way to avoid having a static non-changing address is to use
>   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could
>   be configured to hand out addresses that change over time.  But
>   DHCPv6 will solve the privacy issue only if it frequently handed
>   out constantly changing addresses to the nodes or if the DHCPv6
>   client moves from links to links frequently, being allocated
>   independent addresses from different DHCPv6 servers.  However, the
>   former does not happen automatically, and is difficult to configure
>   manually; the latter cannot be assumed for static (not frequently
>   moving) hosts.  Thus, DHCPv6 is not a self contained alternative
>   for solving the privacy issues addressed by this document.
>   However, in the absence of stateless address autoconfiguration,
>   DHCPv6 can be used for distributing temporary addresses to clients.

Looks good. I will use your suggested text.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From PattyNavarro@paris49.com  Fri Apr  1 15:19: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 PAA04860;
	Fri, 1 Apr 2005 15:19:02 -0500 (EST)
Received: from [194.63.133.81] (helo=net133-081.forweb.pl)
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DHSj3-0001It-BP; Fri, 01 Apr 2005 15:26:44 -0500
Received: from DNNf@localhost by 9nbH.int (8.11.6/8.11.6); Fri, 01 Apr 2005 14:13:30 -0600
Message-ID: <RtfPJSpiDiFKRaMErVUC7EJ@bridgeportroad.com>
From: "Yvonne Flanagan" <PattyNavarro@paris49.com>
Reply-To: "Yvonne Flanagan" <PattyNavarro@paris49.com>
To: ipngwg-archive@ietf.org, mpowr@ietf.org, ietf-announce-admin@ietf.org,
        policy-admin@ietf.org, ips-bounces@ietf.org, est@ietf.org
Subject: 0nline software, Download Microsoft, MS 2003 & others Instantly
Date: Sat, 02 Apr 2005 00:14:30 +0400
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2
X-Sender: PattyNavarro@paris49.com
Content-Type: multipart/mixed;  boundary="--2S8iqRH8Wpe7NgX6au"
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd

IYU 

----2S8iqRH8Wpe7NgX6au
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3D"Content-Language" content=3D"en-us">
<meta name=3D"zqLk" content=3D"sWzu">
<meta name=3D"ProgId" content=3D"FI8n">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<title>7959912</title>
</head>

<body>

<table border=3D"1" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#003399" width=3D"676" id=3D"AutoNumber1"=
 height=3D"22">
  <tr>
    <td width=3D"118" height=3D"22" align=3D"center" bgcolor=3D"#003399">
    <font face=3D"Arial" size=3D"2" color=3D"#FFFFFF"><b>
    <a style=3D"color: #FFFFFF; text-decoration: none" href=3D"http://expe=
rienceware.net/?x">
    Browse</a></b></font></td>
    <td width=3D"118" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://experienceware.net/?j" style=3D"text-decoration: non=
e">
    <font color=3D"#000000">Search</font></a></b></font></td>
    <td width=3D"119" height=3D"22" align=3D"center"><b><font face=3D"Aria=
l" size=3D"2">
    <a href=3D"http://experienceware.net/?C" style=3D"text-decoration: non=
e">
    <font color=3D"#000000">Shop</font></a></font></b></td>
    <td width=3D"119" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://experienceware.net/?4" style=3D"text-decoration: non=
e">
    <font color=3D"#000000">My eSoft</font></a></b></font></td>
    <td width=3D"151" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://experienceware.net/?r" style=3D"text-decoration: non=
e">
    <font color=3D"#000000">Community</font></a></b></font></td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#111111" width=3D"677" id=3D"AutoNumber2"=
 height=3D"34">
  <tr>
    <td width=3D"194" height=3D"34"><font face=3D"Arial">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/viewitem/backArrow_14x1=
4.gif" width=3D"14" height=3D"14">
    <font size=3D"2"><a href=3D"http://experienceware.net/?t">Back to Soft=
ware Overview</a></font></font></td>
    <td width=3D"439" height=3D"34">
    <p align=3D"center"><font face=3D"Arial"><font size=3D"1">
    <a href=3D"http://experienceware.net/?T">Home</a> &gt;
    <a href=3D"http://experienceware.net/?X">All Categories</a> &gt;
    <a href=3D"http://experienceware.net/?e">Computers</a> &gt;
    <a href=3D"http://experienceware.net/?T">Software</a> &gt;
    <a href=3D"http://experienceware.net/?o">Operating Systems</a> &gt; </=
font><b>
    <font size=3D"1">Windows</font></b></font></p>
    </td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#111111" width=3D"678" id=3D"AutoNumber3"=
 height=3D"1">
  <tr>
    <td height=3D"1" width=3D"6">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_first=
Dark_6x29.gif" width=3D"6" height=3D"25"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"157" bgcolor=3D"#ffc=
c00" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" border=3D"0"=
 summary height=3D"13">
      <tr>
        <td bgcolor=3D"#f7f7f7" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#e6e6e6" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#d6d6d6" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#ffcc00" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#ffe682" height=3D"1"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle" height=3D"13">
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2"><b=
>All Items</b></font></td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"14">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_midDa=
rkOnLight_14x29.gif" width=3D"14" height=3D"25"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"174" bgcolor=3D"#FFE=
682" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" border=3D"0"=
 summary>
      <tr>
        <td bgcolor=3D"#F7F7F7"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#E6E6E6"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#D6D6D6"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFCC00"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFE682"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle">
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2"><b=
>
        <a href=3D"http://experienceware.net/?9">Auctions</a></b></font></=
td>
      </tr>
      <tr>
        <td></td>
      </tr>
      <tr>
        <td valign=3D"bottom">
        <table height=3D"2" cellspacing=3D"0" cellpadding=3D"0" width=3D"1=
00%" border=3D"0" valign=3D"bottom" summary>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#EFD778" height=3D"1"></td>
          </tr>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#D4BF6A" height=3D"1"></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"14">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_midLi=
ghtLight_14x29.gif" width=3D"14" height=3D"23"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"176" bgcolor=3D"#FFE=
682" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"55" border=3D"0" s=
ummary>
      <tr>
        <td bgcolor=3D"#F7F7F7" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#E6E6E6" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#D6D6D6" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFCC00" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFE682" width=3D"175"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle" width=3D"175">
        <a href=3D"http://experienceware.net/?K"><b>
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2">Bu=
y</font></b></a><font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D=
"2"><b><a href=3D"http://experienceware.net/?V"> 
        It Now</a></b></font></td>
      </tr>
      <tr>
        <td width=3D"175"></td>
      </tr>
      <tr>
        <td valign=3D"bottom" width=3D"175">
        <table height=3D"2" cellspacing=3D"0" cellpadding=3D"0" width=3D"1=
00%" border=3D"0" valign=3D"bottom" summary>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#EFD778" height=3D"1"></td>
          </tr>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#D4BF6A" height=3D"1"></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"137">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_endLi=
ghtTab_14x29.gif" width=3D"14" height=3D"23"></td>
  </tr>
</table>
<table width=3D"582" bgcolor=3D"#FFFFFF" border=3D"0" cellpadding=3D"0" ce=
llspacing=3D"0" style=3D"border-collapse: collapse" bordercolor=3D"#111111=
">
  <tr>
    <td bgcolor=3D"#FFCC00" width=3D"1"><font face=3D"Arial" size=3D"2">
    <img height=3D"1" src=3D"http://pics.ebaystatic.com/aw/pics/s.gif" wid=
th=3D"1"></font></td>
    <td width=3D"598">
    <table border=3D"1" bgcolor=3D"#FFFFCC" width=3D"676" cellpadding=3D"0=
" cellspacing=3D"0" style=3D"border-collapse: collapse" bordercolor=3D"#FF=
CC00" height=3D"52">
      <tr>
        <td valign=3D"middle" nowrap width=3D"627" height=3D"52"><font fac=
e=3D"Arial">&nbsp;&nbsp;&nbsp;
        <input type=3D"text" name=3D"satitle" size=3D"43" maxlength=3D"300=
" value><font size=3D"2">
        </font><select name=3D"sacategory">
        <option selected>Windows</option>
        <option>Adobe</option>
        <option>Macromedia</option>
        </select><font size=3D"2"> </font><a href=3D"http://experienceware=
net/?n">
        <input type=3D"button" name=3D"bs" value=3D"Search" onclick></a><f=
ont size=3D"2">
        </font></font><span class=3D"navigation"><font size=3D"2" face=3D"=
Arial">
        <a class href=3D"http://experienceware.net/?b">Refine Search</a></=
font></span></td>
      </tr>
    </table>
    </td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#CCCCCC" width=3D"676" id=3D"AutoNumber4"=
 height=3D"234">
  <tr>
    <td width=3D"134" height=3D"234" rowspan=3D"6">
    <table border=3D"1" cellpadding=3D"2" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#FFCC00" width=3D"100%" id=3D"AutoNum=
ber5" height=3D"423" bgcolor=3D"#FFFFCC">
      <tr>
        <td width=3D"100%" height=3D"10" bgcolor=3D"#FFE682">&nbsp;<b><fon=
t face=3D"Arial" size=3D"2">Top 
        Sellers</font></b></td>
      </tr>
      <tr>
        <td width=3D"100%" height=3D"413" valign=3D"top"><font face=3D"Ari=
al" size=3D"1">1&nbsp;&nbsp;
        <a href=3D"http://experienceware.net/?p" style=3D"text-decoration:=
 none">Windows 
        XP Pro</a><br>
        2&nbsp;&nbsp;
        <a href=3D"http://experienceware.net/?2" style=3D"text-decoration:=
 none">Office 
        XP 2002 Pro</a><br>
        3&nbsp;&nbsp;
        <a href=3D"http://experienceware.net/?0" style=3D"text-decoration:=
 none">Adobe 
        Acrobat<br>
&nbsp;&nbsp;&nbsp;&nbsp; 7.0 Professional</a><br>
        4&nbsp;&nbsp;
        <a href=3D"http://experienceware.net/?D" style=3D"text-decoration:=
 none">Adobe 
        Photoshop<br>
&nbsp;&nbsp;&nbsp;&nbsp; CS 8.0</a><br>
        5<a href=3D"http://experienceware.net/?W" style=3D"text-decoration=
: none">&nbsp;&nbsp; 
        Office 2003 Pro&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </a><br>
        6&nbsp;&nbsp;
        <a style=3D"text-decoration: none" href=3D"http://experienceware.n=
et/?8">Macromedia<br>
&nbsp;&nbsp;&nbsp;&nbsp; Dream Weaver<br>
&nbsp;&nbsp;&nbsp;&nbsp; MX 2004</a><br>
        <a href=3D"http://experienceware.net/?r" style=3D"text-decoration:=
 none">
        <font color=3D"#000000">7</font></a>
        <a href=3D"http://experienceware.net/?U" style=3D"text-decoration:=
 none">
        <font color=3D"#000000">&nbsp;</font></a>
        <a href=3D"http://experienceware.net/?2" style=3D"text-decoration:=
 none">Macromedia 
        Flash<br>
&nbsp;&nbsp;&nbsp;&nbsp; MX 2004 Pro</a><br>
        8&nbsp;&nbsp;
        <a href=3D"http://experienceware.net/?I" style=3D"text-decoration:=
 none">MS 
        2003 Server<br>
&nbsp;&nbsp;&nbsp;&nbsp; (Enterprise Edition)</a><br>
        9&nbsp;&nbsp;
        <a href=3D"http://experienceware.net/?e" style=3D"text-decoration:=
 none">Norton 
        Antivirus 2005</a><br>
        10 <a href=3D"http://experienceware.net/?r" style=3D"text-decorati=
on: none">
        CorelDraw<br>
&nbsp;&nbsp;&nbsp;&nbsp; Graphics Suite 12.0<br>
        </a>11
        <a href=3D"http://experienceware.net/?z" style=3D"text-decoration:=
 none">Adobe 
        Creative Suite<br>
&nbsp;&nbsp;&nbsp;&nbsp; Premium</a><br>
        12 <a href=3D"http://experienceware.net/?E" style=3D"text-decorati=
on: none">
        Alias Wavefront
        <br</a>6.0<br>
        <font color=3D"#000000">13</font>
        <br</a></a>
        <br</a>
        <a href=3D"http://experienceware.net/?k" style=3D"text-decoration:=
 none">Adobe 
        Primer<br>
        </a>14
        <a href=3D"http://experienceware.net/?K" style=3D"text-decoration:=
 none">AutoDesk 
        3d Studio<br>
&nbsp;&nbsp;&nbsp;&nbsp; MAX v6.0</a><br>
        15 <a href=3D"http://experienceware.net/?m" style=3D"text-decorati=
on: none">
        Adobe </a></font>
        <br</a>
        <a href=3D"http://experienceware.net/?5" style=3D"text-decoration:=
 none">
        <font face=3D"Arial" size=3D"1">Encore DVD</font></a><br</a></td>
      </tr>
    </table>
    <p>&nbsp;</p>
    <p>&nbsp;</p>
    </td>
    <td width=3D"542" height=3D"18" bgcolor=3D"#D6D6D6" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber6" bgcolor=3D"#E6E6E6">
      <tr>
        <td width=3D"58%" bgcolor=3D"#E6E6E6" align=3D"center">
        <p align=3D"center"><b><font face=3D"Arial" size=3D"2">Featured It=
em</font></b></p>
        </td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">PRlCE</font></b></td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">Bids</font></b></td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">Time Left</font></b></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"97" height=3D"95">
    <p align=3D"center">
    <img border=3D"0" src=3D"http://www.tails.nl/images/xppro.jpg" width=3D=
"101" height=3D"120" align=3D"left"></p>
    </td>
    <td width=3D"214" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2">
    <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/aw/pi=
cs/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
    <a target=3D"helpwin" href=3D"http://experienceware.net/?A">&nbsp;Micr=
osoft Windows 
    XP PRO<br>
    -Current Edition-</a><br>
    <a target=3D"helpwin" href=3D"http://experienceware.net/?7"><br>
    </a></font><font face=3D"Arial" size=3D"1">
    <a target=3D"helpwin" href=3D"http://experienceware.net/?N">
    <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://pics.=
ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=3D"=
10"></a> 
    from Our eStore</font></p>
    </td>
    <td width=3D"74" height=3D"95">
    <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$49.95</b>
    <font color=3D"#999999">USD</font></font></p>
    </td>
    <td width=3D"79" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2">2<a target=3D"help=
win" href=3D"http://experienceware.net/?h"><br>
    <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://pics.=
ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=3D"=
15"></a></font></p>
    </td>
    <td width=3D"78" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2" color=3D"#660066">=
<nobr>0h 14m</nobr></font></p>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"20" colspan=3D"5" bgcolor=3D"#D6D6D6">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber7" bgcolor=3D"#E6E6E6">
      <tr>
        <td width=3D"80%">
        <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"b=
order-collapse: collapse" bordercolor=3D"#111111" width=3D"100=
%">
          <tr>
            <td width=3D"57%" bgcolor=3D"#E6E6E6" align=3D"center" borderc=
olor=3D"#FFFFFF">
            <p align=3D"center"><b><font face=3D"Arial" size=3D"2">Nevv It=
ems</font></b></p>
            </td>
            <td width=3D"15%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">PRlCE</font></b></td>
            <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">Bids</font></b></td>
            <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">Time Left</font></b></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"45" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber8" height=3D"97">
      <tr>
        <td width=3D"12%" height=3D"97">
        <p align=3D"center">
        <img border=3D"0" src=3D"http://www.imj.co.jp/g-coop/syohin/img/Of=
fice2003.gif" align=3D"left" width=3D"102" height=3D"129"></p>
        </td>
        <td width=3D"25%" height=3D"97">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://experienceware.net/?h">&nbsp;=
Microsoft 
        Office 2003 PRO or<br>
        Microsoft Office XP PRO</a><br>
        <a target=3D"helpwin" href=3D"http://experienceware.net/?k"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://experienceware.net/?L">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"9%" height=3D"97" align=3D"center">
        <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$49.95</b>
        <font color=3D"#999999">USD</font></font></p>
        </td>
        <td width=3D"9%" height=3D"97">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">8<a target=3D"=
helpwin" href=3D"http://experienceware.net/?J"><br>
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></p>
        </td>
        <td width=3D"9%" height=3D"97" align=3D"center"><font face=3D"Aria=
l" size=3D"2">0h 13m</font></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"70" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber9" height=3D"99">
      <tr>
        <td width=3D"15%" height=3D"99">
        <img border=3D"0" src=3D"http://www.re-solution.de/img/photoshopcs=
gif" width=3D"103" height=3D"106" align=3D"left"></td>
        <td width=3D"29%" height=3D"99">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://experienceware.net/?f">&nbsp;=
Adobe Photoshop 
        CS 8.0 or Adobe Acrobat PRO 7.0</a><br>
        <a target=3D"helpwin" href=3D"http://experienceware.net/?L"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://experienceware.net/?A">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"11%" height=3D"99" align=3D"center">
        <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$59.95</b>
        <font color=3D"#999999">USD</font></font></p>
        </td>
        <td width=3D"11%" height=3D"99" align=3D"center"><font face=3D"Ari=
al" size=3D"2">5<a target=3D"helpwin" href=3D"http://experienceware.net/?Z=
"><br>
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></td>
        <td width=3D"10%" height=3D"99" align=3D"center"><font face=3D"Ari=
al" size=3D"2">
        0h 15m</font></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"32" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber10" height=3D"70">
      <tr>
        <td width=3D"15%" height=3D"70">
        <img border=3D"0" src=3D"http://www.hyperpc.co.jp/shozai/soft/flas=
hmxpro2004.jpg" width=3D"113" height=3D"95"></td>
        <td width=3D"30%" height=3D"70">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://experienceware.net/?F">&nbsp;=
Macromedia 
        FlashMX Pro 2004 or Macromedia Dreamweaver MX Pro 2004</a><br>
        <a target=3D"helpwin" href=3D"http://experienceware.net/?T"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://experienceware.net/?z">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"11%" height=3D"70" align=3D"center"><font size=3D"2" =
face=3D"Arial">
        <b>$39.95</b> <font color=3D"#999999">USD</font></font></td>
        <td width=3D"11%" height=3D"70" align=3D"center"><font face=3D"Ari=
al" size=3D"2">1<a target=3D"helpwin" href=3D"http://experienceware.net/?N=
"><br>
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></td>
        <td width=3D"10%" height=3D"70" align=3D"center"><font face=3D"Ari=
al" size=3D"2">
        0h 13m</font></td>
      </tr>
    </table>
    </td>
  </tr>
</table>

</body>

</html>

----2S8iqRH8Wpe7NgX6au--


From ipv6-bounces@ietf.org  Fri Apr  1 16:19:55 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22146
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 16:19:55 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHTWy-0004Ur-Us; Fri, 01 Apr 2005 16:18:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTWw-0004U3-UN
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 16:18: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 QAA22045
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 16:18:12 -0500 (EST)
Received: from 209-162-215-52.dq1sn.easystreet.com ([209.162.215.52]
	helo=mailhost.m5p.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DHTeK-0007mw-9t
	for ipv6@ietf.org; Fri, 01 Apr 2005 16:25:53 -0500
Received: from m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb])
	by mailhost.m5p.com (8.13.2/8.13.2) with ESMTP id j31LI1do091367
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK)
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 13:18:01 -0800 (PST)
Received: (from george@localhost)
	by m5p.com (8.13.2/8.13.2/Submit) id j31LI1co008374;
	Fri, 1 Apr 2005 13:18:01 -0800 (PST)
Date: Fri, 1 Apr 2005 13:18:01 -0800 (PST)
Message-Id: <200504012118.j31LI1co008374@m5p.com>
From: george+ipng@m5p.com
To: ipv6@ietf.org
X-Scanned-By: MIMEDefang 2.49 on IPv6:2001:418:3fd::f7
X-Spam-Score: 0.3 (/)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4
Subject: oof
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  1 16:21:15 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22413
	for <ipngwg-archive@lists.ietf.org>; Fri, 1 Apr 2005 16:21:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHTXL-0004ea-2h; Fri, 01 Apr 2005 16:18:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTXJ-0004eS-Gs
	for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 16:18: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 QAA22064
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 16:18:35 -0500 (EST)
Received: from 209-162-215-52.dq1sn.easystreet.com ([209.162.215.52]
	helo=mailhost.m5p.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DHTei-0007nR-7x
	for ipv6@ietf.org; Fri, 01 Apr 2005 16:26:16 -0500
Received: from m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb])
	by mailhost.m5p.com (8.13.2/8.13.2) with ESMTP id j31LIR0h091371
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK)
	for <ipv6@ietf.org>; Fri, 1 Apr 2005 13:18:27 -0800 (PST)
Received: (from george@localhost)
	by m5p.com (8.13.2/8.13.2/Submit) id j31LIRkW008381;
	Fri, 1 Apr 2005 13:18:27 -0800 (PST)
Date: Fri, 1 Apr 2005 13:18:27 -0800 (PST)
Message-Id: <200504012118.j31LIRkW008381@m5p.com>
From: george+ipng@m5p.com
To: ipv6@ietf.org
X-Scanned-By: MIMEDefang 2.49 on IPv6:2001:418:3fd::f7
X-Spam-Score: 0.3 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: Annual Report
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

After getting off to an abysmal start three years ago, my campaign to
become the Benevolent Dictator of the internet has gloriously plummetted
even lower in the past twelve months.  Still, you can join the tens of
your colleagues who have obtained a free random number, not to be used
as a unique local address, at http://www.f-iw.org/random.cgi.  When I
looked at the number of hits, I had thought there might be hundreds of
you getting random numbers, but, upon closer examination, I found that
over 80% of the hits were from inktomisearch.com.  Oh, well.

Happy April Fools day!                             -- George Mitchell


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Sat Apr  2 05:22:34 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11670
	for <ipngwg-archive@lists.ietf.org>; Sat, 2 Apr 2005 05:22:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHfir-0003T6-Kf; Sat, 02 Apr 2005 05:19:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHfik-0003Qp-S1
	for ipv6@megatron.ietf.org; Sat, 02 Apr 2005 05:19: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 FAA11373
	for <ipv6@ietf.org>; Sat, 2 Apr 2005 05:19: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 1DHfqF-0000iB-38
	for ipv6@ietf.org; Sat, 02 Apr 2005 05:27:00 -0500
Received: from ocean.jinmei.org (PPP434.air-4x8x.dti.ne.jp [210.170.213.220])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id B3E0E15210; Sat,  2 Apr 2005 19:19:00 +0900 (JST)
Date: Sat, 02 Apr 2005 19:19:32 +0900
Message-ID: <y7vr7htiiq3.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
In-Reply-To: <Pine.LNX.4.61.0504011131290.5258@localhost.localdomain>
References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net>
	<a4a7301e2b94507c054e57dd2f17882e@innovationslab.net>
	<y7vacojj7hu.wl@ocean.jinmei.org>
	<8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se>
	<Pine.LNX.4.61.0504011131290.5258@localhost.localdomain>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
	(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: Suresh Krishnan <suresh.krishnan@ericsson.ca>,
        Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Fri, 1 Apr 2005 11:31:52 -0500 (EST), 
>>>>> Suresh Krishnan <suresh.krishnan@ericsson.ca> said:

> Hi Jinmei,
>   Thanks for taking the time to verify the changes. See comments inline.

>> 1. Regarding comment 1 in "msg03875.html", I'd also revise the first
>> sentence of Section 1.1
>> 
>> From:
>> Addresses generated using Stateless address autoconfiguration
>> [ADDRCONF]contain an embedded 64-bit interface identifier, which
>> remains constant over time.
>> 
>> To:
>> Addresses generated using Stateless address autoconfiguration
>> [ADDRCONF] contain an embedded interface identifier, which
>> remains constant over time.
>> 
>> In this context, the point should be that the interface identifier
>> remains constant, and the exact number of ID length (64-bit) is
>> rather minor.  Thus, removing the number should be safe, and is
>> actually more aligned with the latest sense of rfc2462bis.

> I have the following text in the introduction which restricts the scope of the
> document to 64 bit identifiers.

Yes, I noticed this, but I wanted to make the proposed change in
addition to this one for the reason I mentioned above.

> " Note that an IPv6 identifier does not necessarily have to be 64 bits in
>   length, but the algorithm specified in this document is targeted towards
>   64-bit interface identifiers."

> Do you still want me to make this change?

>> 
>> 2. Comment 3 in "msg03875.html" does not seem to be addressed.
>> Perhaps this is too minor, however, and I could live with the
>> current text.

> The concerns are described in section 2.3. I did not want to repeat them here.
> However, I can rephrase the sentence
> from

> " The focus of this document is on addresses derived from IEEE identifiers,
>   as the concern being addressed exists only in those cases where the
>   interface identifier is globally unique and non-changing"

> to

> " The focus of this document is on addresses derived from IEEE identifiers,
>   because an interface identifier that is globally unique and non-changing
>   can facilitate the tracking of individual devices and possibly users
>   of those devices."

> Is that OK?

This is better than the original text, but I'd rephrase it a bit:

   The focus of this document is on addresses derived from IEEE
   identifiers, because tracking of individual devices, the concern
   being addressed here, is possible only in those cases where the
   interface identifier is globally unique and non-changing.

But it's completely up to you whether to make a change at all or which
text to use.

					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 Apr  3 00:03:16 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23781
	for <ipngwg-archive@lists.ietf.org>; Sun, 3 Apr 2005 00:03:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHxET-0001oL-Q7; Sun, 03 Apr 2005 00:01:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHxE3-0001bj-Cn
	for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 00:00: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 AAA23651
	for <ipv6@ietf.org>; Sun, 3 Apr 2005 00:00:40 -0500 (EST)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHxLi-0005iZ-Tq
	for ipv6@ietf.org; Sun, 03 Apr 2005 00:08:39 -0500
Received: from hactrn.net (localhost [127.0.0.1])
	by cyteen.hactrn.net (Postfix) with ESMTP id 6C09F77E
	for <ipv6@ietf.org>; Sun,  3 Apr 2005 00:00:27 -0500 (EST)
To: ipv6@ietf.org
From: Rob Austein <sra+ipng@hactrn.net>
Date: Sun, 03 Apr 2005 00:00:27 -0500
Message-Id: <20050403050027.6C09F77E@cyteen.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 21.28% |   10 | 21.31% |    49393 | jinmei@isl.rdc.toshiba.co.jp
 10.64% |    5 |  8.51% |    19722 | fenner@research.att.com
  6.38% |    3 |  5.12% |    11860 | j.schoenwaelder@iu-bremen.de
  4.26% |    2 |  6.72% |    15586 | brian@innovationslab.net
  4.26% |    2 |  6.65% |    15412 | adamson@us.ibm.com
  4.26% |    2 |  5.46% |    12666 | mukesh.k.gupta@nokia.com
  4.26% |    2 |  4.71% |    10914 | suresh.krishnan@ericsson.ca
  4.26% |    2 |  2.83% |     6562 | itojun@itojun.org
  4.26% |    2 |  2.67% |     6197 | george+ipng@m5p.com
  2.13% |    1 |  3.84% |     8909 | francis.dupont@enst-bretagne.fr
  2.13% |    1 |  3.09% |     7166 | suresh.krishnan@ericsson.com
  2.13% |    1 |  2.85% |     6603 | anpartha@cisco.com
  2.13% |    1 |  2.52% |     5833 | eric.gray@marconi.com
  2.13% |    1 |  2.47% |     5714 | internet-drafts@ietf.org
  2.13% |    1 |  2.39% |     5549 | jari.arkko@kolumbus.fi
  2.13% |    1 |  2.32% |     5385 | brc@zurich.ibm.com
  2.13% |    1 |  2.09% |     4837 | greg.daley@eng.monash.edu.au
  2.13% |    1 |  2.04% |     4731 | jspence@native6.com
  2.13% |    1 |  1.92% |     4444 | sra+ipng@hactrn.net
  2.13% |    1 |  1.63% |     3786 | qing.li@bluecoat.com
  2.13% |    1 |  1.56% |     3607 | peter.grubmair@siemens.com
  2.13% |    1 |  1.55% |     3604 | yoshfuji@linux-ipv6.org
  2.13% |    1 |  1.53% |     3542 | soohong.park@samsung.com
  2.13% |    1 |  1.47% |     3407 | ericlklein@softhome.net
  2.13% |    1 |  1.45% |     3362 | zefram@fysh.org
  2.13% |    1 |  1.30% |     3010 | dwmalone@maths.tcd.ie
--------+------+--------+----------+------------------------
100.00% |   47 |100.00% |   231801 | 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 Apr  3 14:25:13 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16345
	for <ipngwg-archive@lists.ietf.org>; Sun, 3 Apr 2005 14:25:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DI9fD-0007G8-U4; Sun, 03 Apr 2005 14:17:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DI9fC-0007G1-Fb
	for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 14:17:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15835
	for <ipv6@ietf.org>; Sun, 3 Apr 2005 14:17:28 -0400 (EDT)
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 1DI9mv-0006YW-U7
	for ipv6@ietf.org; Sun, 03 Apr 2005 14:25:35 -0400
Received: from bright.research.att.com (bright.research.att.com
	[135.207.20.189])
	by mail-blue.research.att.com (Postfix) with ESMTP id 9F523197354;
	Sun,  3 Apr 2005 13:57:05 -0400 (EDT)
Received: (from fenner@localhost)
	by bright.research.att.com (8.12.11/8.12.10/Submit) id j33IHHBS028317; 
	Sun, 3 Apr 2005 11:17:17 -0700
Message-Id: <200504031817.j33IHHBS028317@bright.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: jinmei@isl.rdc.toshiba.co.jp
References: <200503290220.j2T2KJ8u007856@bright.research.att.com>
	<y7vd5tjorww.wl@ocean.jinmei.org>
	<200503291546.j2TFk1RO028654@bright.research.att.com>
	<y7vvf79opb3.wl@ocean.jinmei.org>
	<200503301456.j2UEuGUC009042@bright.research.att.com>
	<y7vpsxhkr61.wl@ocean.jinmei.org>
	<200503301718.j2UHIFeX013740@bright.research.att.com>
	<y7vll85kmaq.wl@ocean.jinmei.org>
Date: Sun, 3 Apr 2005 11:17:17 -0800
From: Bill Fenner <fenner@research.att.com>
Versions: dmail (linux) 2.6d/makemail 2.10
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


>The essential point is, at least to me, is that we did not want to
>force applications (like URI/URL parsers) to be aware of scope zones
>and/or the dedicated syntax for scoped addresses.

My reading was that we don't want applications to have to examine an
arbitrary address and decide whether or not they have to deal with
it specially.  Since this format is unique and is only used for scoped
addresses, the application doesn't have to decide based on the address -
it's already been told based on the URI format.

>-in my understanding, one major reason [that people were enthusiastic
>about killing site-local] was they did not want to force applications
>to know details about scopes and/or zones for behaving correctly.

This was at least partly about having to derive the information from
the address; I think that communicating the fact that a zone is
present seperately from the address at least partly alleviates these
concerns.

  Bill

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Sun Apr  3 22:43:18 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18025
	for <ipngwg-archive@lists.ietf.org>; Sun, 3 Apr 2005 22:43:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIHRF-0001O8-Uu; Sun, 03 Apr 2005 22:35:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHRD-0001O3-QI
	for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:35:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17437
	for <ipv6@ietf.org>; Sun, 3 Apr 2005 22:35:37 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHZ2-0000oQ-2v
	for ipv6@ietf.org; Sun, 03 Apr 2005 22:43:46 -0400
Received: from ocean.jinmei.org (unknown
	[3ffe:501:100f:1048:adf7:96f6:f7ff:6d5d])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 88A9215210; Mon,  4 Apr 2005 11:35:21 +0900 (JST)
Date: Mon, 04 Apr 2005 11:36:00 +0900
Message-ID: <y7vmzsfi7zj.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: Bill Fenner <fenner@research.att.com>
In-Reply-To: <200504031817.j33IHHBS028317@bright.research.att.com>
References: <200503290220.j2T2KJ8u007856@bright.research.att.com>
	<y7vd5tjorww.wl@ocean.jinmei.org>
	<200503291546.j2TFk1RO028654@bright.research.att.com>
	<y7vvf79opb3.wl@ocean.jinmei.org>
	<200503301456.j2UEuGUC009042@bright.research.att.com>
	<y7vpsxhkr61.wl@ocean.jinmei.org>
	<200503301718.j2UHIFeX013740@bright.research.att.com>
	<y7vll85kmaq.wl@ocean.jinmei.org>
	<200504031817.j33IHHBS028317@bright.research.att.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
	(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Sun, 3 Apr 2005 11:17:17 -0800, 
>>>>> Bill Fenner <fenner@research.att.com> said:

>> The essential point is, at least to me, is that we did not want to
>> force applications (like URI/URL parsers) to be aware of scope zones
>> and/or the dedicated syntax for scoped addresses.

> My reading was that we don't want applications to have to examine an
> arbitrary address and decide whether or not they have to deal with
> it specially.  Since this format is unique and is only used for scoped
> addresses, the application doesn't have to decide based on the address -
> it's already been told based on the URI format.

I guess I don't understand the latter sentence...

- what is "this format"? (perhaps it's "fe80::1(some delimiter)de0"
  for URI)
- what do you mean by unique?
- what do you mean by "it's already been told based on the URI format"?

>> -in my understanding, one major reason [that people were enthusiastic
>> about killing site-local] was they did not want to force applications
>> to know details about scopes and/or zones for behaving correctly.

> This was at least partly about having to derive the information from
> the address; I think that communicating the fact that a zone is
> present seperately from the address at least partly alleviates these
> concerns.

I also seem to fail to understand this sentence...what do you mean by
"the fact that a zone is present separately from the address"?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Sun Apr  3 22:55:14 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18934
	for <ipngwg-archive@lists.ietf.org>; Sun, 3 Apr 2005 22:55:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIHh7-0003PH-Db; Sun, 03 Apr 2005 22:52:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHh6-0003OF-45
	for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:52:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18778
	for <ipv6@ietf.org>; Sun, 3 Apr 2005 22:52:01 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHox-0001WR-8f
	for ipv6@ietf.org; Sun, 03 Apr 2005 23:00:11 -0400
Received: from ocean.jinmei.org (unknown
	[3ffe:501:100f:1048:adf7:96f6:f7ff:6d5d])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id CDC2A15210; Mon,  4 Apr 2005 11:52:03 +0900 (JST)
Date: Mon, 04 Apr 2005 11:52:43 +0900
Message-ID: <y7vfyy7i77o.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: Kristine Adamson <adamson@us.ibm.com>
In-Reply-To: <OF8DDF5407.BE291018-ON87256FD6.0048182D-85256FD6.0048A2C7@us.ibm.com>
References: <y7vr7hvjjnj.wl@ocean.jinmei.org>
	<OF8DDF5407.BE291018-ON87256FD6.0048182D-85256FD6.0048A2C7@us.ibm.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
	(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: ipv6@ietf.org
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Fri, 1 Apr 2005 06:13:22 -0700, 
>>>>> Kristine Adamson <adamson@us.ibm.com> said:

> Thanks for the responses.  But if RFC3542 is not updated, won't this 
> adversely affect the portability of applications that references these new 
> codes?

Yes, it will.  However, the point is whether the portability issue is
serious enough to require a revision of RFC3542.  Different people may
have different opinions on this, and I personally don't think it's big
enough.

As someone else in this thread pointed out, this type of issue can
always happen when the IETF standardizes any new ICMP types/codes,
extension header identifier (the number of the "next header" field"),
whatever.  Clearly, we cannot update the API specification every time
we see this type of event, so we need to make a consensus on how
serious the related portability issue is.  If others agree on the
severity, I won't oppose to the conclusion.

					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 Apr  3 22:58:34 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19175
	for <ipngwg-archive@lists.ietf.org>; Sun, 3 Apr 2005 22:58:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIHjs-0003gE-I9; Sun, 03 Apr 2005 22:54:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHjr-0003g8-Cj
	for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:54:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18924
	for <ipv6@ietf.org>; Sun, 3 Apr 2005 22:54:53 -0400 (EDT)
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHrh-0001lK-GK
	for ipv6@ietf.org; Sun, 03 Apr 2005 23:03:02 -0400
Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se
	[138.85.133.52])
	by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j342uJCR026908;
	Sun, 3 Apr 2005 21:56:19 -0500 (CDT)
Received: from noah.lmc.ericsson.se ([142.133.1.1]) by
	eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id H7V683T0; Sun, 3 Apr 2005 21:54:44 -0500
Received: from [142.133.72.115] ([142.133.72.115])
	by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j342sWXq027072; 
	Sun, 3 Apr 2005 22:54:32 -0400 (EDT)
Date: Sun, 3 Apr 2005 22:52:22 -0400 (EDT)
X-Sybari-Trust: 01201803 b10726bd 1974725b 00000139
From: Suresh Krishnan <suresh.krishnan@ericsson.ca>
X-X-Sender: suresh@localhost.localdomain
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
In-Reply-To: <y7vr7htiiq3.wl@ocean.jinmei.org>
Message-ID: <Pine.LNX.4.61.0504032249020.11099@localhost.localdomain>
References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> 
	<a4a7301e2b94507c054e57dd2f17882e@innovationslab.net>
	<y7vacojj7hu.wl@ocean.jinmei.org>
	<8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se>
	<Pine.LNX.4.61.0504011131290.5258@localhost.localdomain>
	<y7vr7htiiq3.wl@ocean.jinmei.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: Bob Hinden <bob.hinden@nokia.com>,
        Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>,
        Suresh Krishnan <suresh.krishnan@ericsson.com>
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi Jinmei,
   I will make the changes you suggested. I will also change the address 
selection reference (RFC3484) to informative to avoid the downref.

Brian & Bob,
   Should I submit another version of the draft immediately or wait for the 
IESG to come back with more comments to make these changes?

Thanks
Suresh


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Sun Apr  3 23:00:40 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19444
	for <ipngwg-archive@lists.ietf.org>; Sun, 3 Apr 2005 23:00:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIHlG-0003qb-SH; Sun, 03 Apr 2005 22:56:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHlF-0003qV-Bu
	for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:56:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19020
	for <ipv6@ietf.org>; Sun, 3 Apr 2005 22:56:19 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHt5-0001ss-Jr
	for ipv6@ietf.org; Sun, 03 Apr 2005 23:04:28 -0400
Received: from ocean.jinmei.org (unknown
	[3ffe:501:100f:1048:adf7:96f6:f7ff:6d5d])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 27C7B1521D; Mon,  4 Apr 2005 11:56:20 +0900 (JST)
Date: Mon, 04 Apr 2005 11:56:59 +0900
Message-ID: <y7vekdri70k.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: Grubmair Peter <peter.grubmair@siemens.com>
In-Reply-To: <4D50D5110555D5119F270800062B41650532AD21@viee10pa.erd.siemens.at>
References: <4D50D5110555D5119F270800062B41650532AD21@viee10pa.erd.siemens.at>
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: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: "IPV6 IETF \(ipv6@ietf.org\)" <ipv6@ietf.org>
Subject: Re: possible Duplicate addresses in case of healing network
	partition s
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Tue, 29 Mar 2005 14:31:39 +0200, 
>>>>> Grubmair Peter <peter.grubmair@siemens.com> said:

> To my mind this also will apply to IPv6, allthough the probility that
> 2 hosts will use the same address will be much smaller than in IPv4.
> But in contrast to <draft-ietf-zeroconf-ipv4-linklocal-17.txt>
> IPv6 ND provides no means to dedect the situation and handle it in any way.
> Is this correct ?

That's correct.  RFC2462 clearly notes the point in Section 5.4:

   Note that the method for detecting duplicates
   is not completely reliable, and it is possible that duplicate
   addresses will still exist (e.g., if the link was partitioned while
   Duplicate Address Detection was performed).

(rfc2462bis does not change this part, for that matter)

					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 Apr  3 23:29:46 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18026
	for <ipngwg-archive@lists.ietf.org>; Sun, 3 Apr 2005 22:43:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIHWB-0001hg-CB; Sun, 03 Apr 2005 22:40:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHW9-0001hZ-UP
	for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:40:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17716
	for <ipv6@ietf.org>; Sun, 3 Apr 2005 22:40:43 -0400 (EDT)
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 1DIHe1-0000zP-7O
	for ipv6@ietf.org; Sun, 03 Apr 2005 22:48:53 -0400
Received: from bright.research.att.com (bright.research.att.com
	[135.207.20.189])
	by mail-blue.research.att.com (Postfix) with ESMTP id 5A7C7197354;
	Sun,  3 Apr 2005 22:20:23 -0400 (EDT)
Received: (from fenner@localhost)
	by bright.research.att.com (8.12.11/8.12.10/Submit) id j342ebvl008179; 
	Sun, 3 Apr 2005 19:40:37 -0700
Message-Id: <200504040240.j342ebvl008179@bright.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: jinmei@isl.rdc.toshiba.co.jp
References: <200503290220.j2T2KJ8u007856@bright.research.att.com>
	<y7vd5tjorww.wl@ocean.jinmei.org>
	<200503291546.j2TFk1RO028654@bright.research.att.com>
	<y7vvf79opb3.wl@ocean.jinmei.org>
	<200503301456.j2UEuGUC009042@bright.research.att.com>
	<y7vpsxhkr61.wl@ocean.jinmei.org>
	<200503301718.j2UHIFeX013740@bright.research.att.com>
	<y7vll85kmaq.wl@ocean.jinmei.org>
	<200504031817.j33IHHBS028317@bright.research.att.com>
	<y7vmzsfi7zj.wl@ocean.jinmei.org>
Date: Sun, 3 Apr 2005 19:40:36 -0800
From: Bill Fenner <fenner@research.att.com>
Versions: dmail (linux) 2.6d/makemail 2.10
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


>>>>>> On Sun, 3 Apr 2005 11:17:17 -0800, 
>>>>>> Bill Fenner <fenner@research.att.com> said:
>> Since this format is unique and is only used for scoped
>> addresses, the application doesn't have to decide based on the address -
>> it's already been told based on the URI format.
>
>I guess I don't understand the latter sentence...
>
>- what is "this format"? (perhaps it's "fe80::1(some delimiter)de0"
>  for URI)

It's [v6.fe800:1(some delimiter)de0].

>- what do you mean by unique?

I mean the [v6. ... ] part is different from any other URI format.

>- what do you mean by "it's already been told based on the URI format"?

I mean that the application knows based on the fact that the
URI that it's parsing has [v6. (something) ] - it knows that
the (something) is an address with a scope zone.

>I also seem to fail to understand this sentence...what do you mean by
>"the fact that a zone is present separately from the address"?

It's the communication that is separate from the address; the same
point as above.

  Bill

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr  4 03:36:51 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01800
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 03:36:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIM4P-0005Hb-RI; Mon, 04 Apr 2005 03:32:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIM4M-0005HT-UO
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 03:32:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01390
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 03:32:21 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIMCF-0006g2-LB
	for ipv6@ietf.org; Mon, 04 Apr 2005 03:40:33 -0400
Received: from ocean.jinmei.org (unknown
	[3ffe:501:100f:1048:b59a:a0c1:107f:64c7])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id CB82815210; Mon,  4 Apr 2005 16:32:20 +0900 (JST)
Date: Mon, 04 Apr 2005 16:33:00 +0900
Message-ID: <y7vy8bzgfo3.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: Bill Fenner <fenner@research.att.com>
In-Reply-To: <200504040240.j342ebvl008179@bright.research.att.com>
References: <200503290220.j2T2KJ8u007856@bright.research.att.com>
	<y7vd5tjorww.wl@ocean.jinmei.org>
	<200503291546.j2TFk1RO028654@bright.research.att.com>
	<y7vvf79opb3.wl@ocean.jinmei.org>
	<200503301456.j2UEuGUC009042@bright.research.att.com>
	<y7vpsxhkr61.wl@ocean.jinmei.org>
	<200503301718.j2UHIFeX013740@bright.research.att.com>
	<y7vll85kmaq.wl@ocean.jinmei.org>
	<200504031817.j33IHHBS028317@bright.research.att.com>
	<y7vmzsfi7zj.wl@ocean.jinmei.org>
	<200504040240.j342ebvl008179@bright.research.att.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
	(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Sun, 3 Apr 2005 19:40:36 -0800, 
>>>>> Bill Fenner <fenner@research.att.com> said:

>> I guess I don't understand the latter sentence...
>> 
>> - what is "this format"? (perhaps it's "fe80::1(some delimiter)de0"
>> for URI)

> It's [v6.fe800:1(some delimiter)de0].

Ah, I see.  Then I've been misunderstanding the point from the
beginning, sorry about that.

Let me confirm my understanding once again...

(assuming "some delimiter" is "_" for simplicity)

- for IPv6 addresses without scope zones, we'll type
  http://[2001:db8::1234]/
  as specified in RFC3986.

- for IPv6 addresses with scope zones, we'd type
  http://[v6.fe80::1234_de0]/

  ("v6." is attached deliberately to indicate it's an IPv6 "scoped"
   address with zone, not an ordinary IPv6 address.  RFC3986 prohibits
   the use of "v6." (or any other "vX.") before an IPv6 literal
   address, but it doesn't matter since "fe80::1234_de0" is not a
   standard IPv6 literal address.)

And, going back to the concrete example I showed:

1. assume we type "http://[v6.fe80::1_de0]/" in "the URL bar" of the
   browser.
2. then the browser parser parses the entire URL and extracts
   "v6.fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]"
   as delimiters.
3. the parser then recognizes it is a representation of an IPv6 scoped
   address with a zone ID from the "v6." part, and extracts
   "fe80::1_de0".
4. the parser replaces "_" in "fe80::1_de0" with "%", and passes the
   result (fe80::1%de0) to getaddrinfo(), getting a sockaddr_in6
   structure (whose sin6_addr member is "fe80::1" and sin6_scope_id
   member is the link ID corresponding to interface "de0").  The
   browser uses the sockaddr_in6 structure with connect(2) to connect
   to the remote web server.
5. the parser also extracts "fe80::1" from "fe80::1_de0" in parallel
   with step 4, and sets "Host:" to it when sending an HTML request to
   the server.

The rationale behind the proposal is that the extra work for the
application in step 3 should justify the other extra work in step 5
(and step 4).

Is my understanding now correct?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr  4 07:51:50 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21850
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 07:51:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIQ44-000238-Tz; Mon, 04 Apr 2005 07:48:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQ42-00022v-7d
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 07:48:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21596
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 07:48:14 -0400 (EDT)
Received: from loadbalancer1.orcon.net.nz ([219.88.242.3]
	helo=dbmail-mx3.orcon.net.nz)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQBr-0007ol-Ue
	for ipv6@ietf.org; Mon, 04 Apr 2005 07:56:27 -0400
Received: from elmer.coders.tla (port-60-234-192-116.jet.net.nz
	[60.234.192.116] (may be forged))
	by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id
	j34BmrdK009981; Mon, 4 Apr 2005 23:48:53 +1200
Received: from breeze.dah.crc.net.nz ([10.1.20.9])
	by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian))
	id 1DIQ3f-0004tE-00; Mon, 04 Apr 2005 23:47:55 +1200
Message-ID: <4251296B.1020900@coders.net>
Date: Mon, 04 Apr 2005 23:47:55 +1200
From: Perry Lorier <perry@coders.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050327
X-Accept-Language: en-nz, en
MIME-Version: 1.0
To: Bill Fenner <fenner@research.att.com>
References: <200503290220.j2T2KJ8u007856@bright.research.att.com>	<y7vd5tjorww.wl@ocean.jinmei.org>
	<200503291546.j2TFk1RO028654@bright.research.att.com>
In-Reply-To: <200503291546.j2TFk1RO028654@bright.research.att.com>
X-Enigmail-Version: 0.90.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.83,
	clamav-milter version 0.83 on dbmail-mx3.orcon.net.nz
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Bill Fenner wrote:
> I usually think of the small home router configuration problem -
> buy a box, plug it in, it wants you to configure it using a web
> page, and it's probably fe80::1.  I don't have any systems in my
> house that have fewer than two non-loopback interfaces.  Since
> this is presumably a one-off, I guess the default interface
> configuration is an option, if a little clumsy.

I don't understand this use case.  Assuming I have a router and it's
manual says type in http://<some-link-local-address><some-delimiter>de0/
it's going to fail on my Linux machine that uses eth0, and if it says
use "eth0" it's going to fail on the other Linux machine that has eth1
on that network.  Link local addresses (that include an interface
identifier) don't make sense outside of the local machine, including in
printed documentation.

I don't think that URI's that don't make sense off a single machine are
a good idea in general, but assuming that we do want this, are we
expecting users to transcribe these addresses?  how about just using
(fe80::1,de0) as http://de0.1.0.0.0.0.0.0.0.fe80.fin6.arpa/ no special
delimiters are needed, and it "looks" like a normal IP, normal software
doesn't need to be upgraded to handle this format, libraries can be
easily upgraded to support this format easily and shortcut the round
trip to a DNS server, the fin6.arpa (forward in6) tree can be
automatically populated with AAAA's on the fly for software that doesn't
work, it can be easily cut and pasted between url's and applications
that expect a "hostname".  the only downside I see is that it's a pain
to take an address (not a hostname) and make a hostname out of it (as
you have to reverse it).

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr  4 08:40:58 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26625
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 08:40:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIQnh-0006pI-MG; Mon, 04 Apr 2005 08:35:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQng-0006pD-4G
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 08:35:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25965
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 08:35:26 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQva-0001Jd-T7
	for ipv6@ietf.org; Mon, 04 Apr 2005 08:43:40 -0400
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id j34CZ5g28504;
	Mon, 4 Apr 2005 15:35:06 +0300
Date: Mon, 4 Apr 2005 15:35:05 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Joe Abley <jabley@isc.org>
In-Reply-To: <e881939938c2c4c6d84496d9ef296c46@isc.org>
Message-ID: <Pine.LNX.4.61.0504041532270.27464@netcore.fi>
References: <e881939938c2c4c6d84496d9ef296c46@isc.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: grow@lists.uoregon.edu, ipv6@ietf.org
Subject: Re: grow: ipv6 anycast
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Joe,

This is a timely topic, because IPv6 WG just less than week ago 
forwarded the revision of the addressing architecture to be published 
as Draft Standard. (IPv6 WG is Cc:ed.)

That draft, 
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.txt 
still has the problematic wording wrt anycast addresses.

On Fri, 1 Apr 2005, Joe Abley wrote:
> Following comments at the meeting in Minneapolis regarding the conflict 
> between draft-ietf-grow-anycast and the v6 addressing spec (which imposes a 
> prohibition on v6 anycast) I wrote up the following:
>
>  http://www.ietf.org/internet-drafts/draft-jabley-v6-anycast-clarify-00.txt
>
> This document might be seen as a companion to a revised 
> draft-ietf-grow-anycast, removing the v6 anycast prohibition such that the 
> anycast document is no longer at odds with the current v6 spec.
>
> Comments on this approach (and the draft) would be most welcome.
>
>
> Joe
>
> _________________________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
> web archive:        http://darkwing.uoregon.edu/~llynch/grow/
>

-- 
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 Apr  4 09:57:40 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08840
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 09:57:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIRzL-0005gO-5J; Mon, 04 Apr 2005 09:51:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIRzJ-0005gJ-1x
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 09:51:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08123
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 09:51:31 -0400 (EDT)
Received: from astro.systems.pipex.net ([62.241.163.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIS7F-0005x9-Fp
	for ipv6@ietf.org; Mon, 04 Apr 2005 09:59:45 -0400
Received: from pc6 (1Cust117.tnt15.lnd4.gbr.da.uu.net [62.188.144.117])
	by astro.systems.pipex.net (Postfix) with SMTP id A8BCAE000175;
	Mon,  4 Apr 2005 14:51:19 +0100 (BST)
Message-ID: <001101c53914$8ce871a0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <ipv6@ietf.org>, "Kristine Adamson" <adamson@us.ibm.com>
References: <OF8DDF5407.BE291018-ON87256FD6.0048182D-85256FD6.0048A2C7@us.ibm.com>
Date: Mon, 4 Apr 2005 14:46:21 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Another way to define name-number mappings is as enumerations in a MIB module,
which can be placed under IANA control and be updated by whatever action seems
appropriate, as is defined in the RFC that first creates it.  (Other IANA
registrations tend to
record the number without giving a specific name to go with it). The ICMPv6 MIB,
RFC 2466, does not define such mappings.

Thinking laterally, IANA could also be a registry for the kind of HLL
name-number mappings which appear in RFC3542.

Tom Petch

----- Original Message -----
From: "Kristine Adamson" <adamson@us.ibm.com>
To: <ipv6@ietf.org>
Sent: Friday, April 01, 2005 3:13 PM
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542


> Thanks for the responses.  But if RFC3542 is not updated, won't this
> adversely affect the portability of applications that references these new
> codes?  If implementers define their own constant names for these codes in
> their icmp6.h files, then you may not be able to compile the source of the
> same application on different platforms.  Thanks,
>
> Kristine Adamson
> IBM z/OS Communications Server: TCP/IP Development
> Internet e-mail:adamson@us.ibm.com
>
>
> JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM:
>
> > >>>>> On Thu, 31 Mar 2005 06:13:37 -0700,
> > >>>>> Kristine Adamson <adamson@us.ibm.com> said:
>
> > >    Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to
> the
> > > Destination Unreachable type.  RFC3542, Advanced Sockets Application
> > > Program Interface (API) for IPv6, provides the programming definitions
> for
> > > the ICMPv6 types/codes.  RFC3542 already defines one of the new codes:
> > > #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source
> address
> > > */
>
> > > Will RFC3542 be updated to include the definitions for the additional
> 2
> > > new codes:
> > > 5 - source address failed ingress/egress policy
> > > 6 - reject route to destination
>
> > Perhaps yes, although I think introducing just two new ICMPv6 types
> > doesn't require a revision of RFC3542.  Someday, when we have enough
> > possible updates for the API, a new version will include the new
> > ICMPv6 types.
>
> > 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
> --------------------------------------------------------------------
>


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr  4 10:41:52 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14156
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 10:41:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DISiH-0001zg-Ju; Mon, 04 Apr 2005 10:38:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DISiF-0001zP-DJ
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 10:37:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13850
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 10:37:57 -0400 (EDT)
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 1DISqB-0008Rg-Tc
	for ipv6@ietf.org; Mon, 04 Apr 2005 10:46:13 -0400
Received: from bright.research.att.com (bright.research.att.com
	[135.207.20.189])
	by mail-blue.research.att.com (Postfix) with ESMTP id 4CFA8197354;
	Mon,  4 Apr 2005 10:17:29 -0400 (EDT)
Received: (from fenner@localhost)
	by bright.research.att.com (8.12.11/8.12.10/Submit) id j34EbjkS026424; 
	Mon, 4 Apr 2005 07:37:45 -0700
Message-Id: <200504041437.j34EbjkS026424@bright.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: jinmei@isl.rdc.toshiba.co.jp
References: <200503290220.j2T2KJ8u007856@bright.research.att.com>
	<y7vd5tjorww.wl@ocean.jinmei.org>
	<200503291546.j2TFk1RO028654@bright.research.att.com>
	<y7vvf79opb3.wl@ocean.jinmei.org>
	<200503301456.j2UEuGUC009042@bright.research.att.com>
	<y7vpsxhkr61.wl@ocean.jinmei.org>
	<200503301718.j2UHIFeX013740@bright.research.att.com>
	<y7vll85kmaq.wl@ocean.jinmei.org>
	<200504031817.j33IHHBS028317@bright.research.att.com>
	<y7vmzsfi7zj.wl@ocean.jinmei.org>
	<200504040240.j342ebvl008179@bright.research.att.com>
	<y7vy8bzgfo3.wl@ocean.jinmei.org>
Date: Mon, 4 Apr 2005 07:37:45 -0800
From: Bill Fenner <fenner@research.att.com>
Versions: dmail (linux) 2.6d/makemail 2.10
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


On Mon, 04 Apr 2005 16:33:00 +0900,
JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> said:
>Is my understanding now correct?

Yes, that looks right.  And even if getaddrinfo took whatever
form directly (either the separator is '%' or getaddrinfo is
modified to accept the URI character as well), I think it's
reasonable to expect step 5 to occur even if step 4 doesn't
have to.

  Bill

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr  4 11:01:41 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15816
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 11:01:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIT2q-0003mI-2S; Mon, 04 Apr 2005 10:59:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIT2n-0003mA-Nd
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 10:59:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15597
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 10:59:10 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITAi-00011Z-BL
	for ipv6@ietf.org; Mon, 04 Apr 2005 11:07:25 -0400
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id j34EwiQ31540;
	Mon, 4 Apr 2005 17:58:44 +0300
Date: Mon, 4 Apr 2005 17:58:44 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
In-Reply-To: <y7vfyy7i77o.wl@ocean.jinmei.org>
Message-ID: <Pine.LNX.4.61.0504041757410.31462@netcore.fi>
References: <y7vr7hvjjnj.wl@ocean.jinmei.org>
	<OF8DDF5407.BE291018-ON87256FD6.0048182D-85256FD6.0048A2C7@us.ibm.com>
	<y7vfyy7i77o.wl@ocean.jinmei.org>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
	BOUNDARY="1589707168-1583352436-1112626724=:31462"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: Kristine Adamson <adamson@us.ibm.com>, ipv6@ietf.org
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-1583352436-1112626724=:31462
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id
	j34EwiQ31540
Content-Transfer-Encoding: quoted-printable

On Mon, 4 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8=
 wrote:
> As someone else in this thread pointed out, this type of issue can
> always happen when the IETF standardizes any new ICMP types/codes,
> extension header identifier (the number of the "next header" field"),
> whatever.  Clearly, we cannot update the API specification every time
> we see this type of event, so we need to make a consensus on how
> serious the related portability issue is.  If others agree on the
> severity, I won't oppose to the conclusion.

The new values could also be defined at the appendix of icmp-v3, but=20
then we'd have to agree on the proper names now, and there could be=20
confusion between the revision of the advanced api and icmp-v3...

--=20
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--1589707168-1583352436-1112626724=:31462
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--1589707168-1583352436-1112626724=:31462--



From ipv6-bounces@ietf.org  Mon Apr  4 11:06:39 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16399
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 11:06:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIT3w-0003pm-IS; Mon, 04 Apr 2005 11:00:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIT3u-0003ph-05
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 11:00:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15656
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 11:00:19 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITBp-00012n-PX
	for ipv6@ietf.org; Mon, 04 Apr 2005 11:08:34 -0400
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id j34F03S31574;
	Mon, 4 Apr 2005 18:00:03 +0300
Date: Mon, 4 Apr 2005 18:00:03 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
In-Reply-To: <y7vy8bzgfo3.wl@ocean.jinmei.org>
Message-ID: <Pine.LNX.4.61.0504041759020.31462@netcore.fi>
References: <200503290220.j2T2KJ8u007856@bright.research.att.com>
	<y7vd5tjorww.wl@ocean.jinmei.org>
	<200503291546.j2TFk1RO028654@bright.research.att.com>
	<y7vvf79opb3.wl@ocean.jinmei.org>
	<200503301456.j2UEuGUC009042@bright.research.att.com>
	<y7vpsxhkr61.wl@ocean.jinmei.org>
	<200503301718.j2UHIFeX013740@bright.research.att.com>
	<y7vll85kmaq.wl@ocean.jinmei.org>
	<200504031817.j33IHHBS028317@bright.research.att.com>
	<y7vmzsfi7zj.wl@ocean.jinmei.org>
	<200504040240.j342ebvl008179@bright.research.att.com>
	<y7vy8bzgfo3.wl@ocean.jinmei.org>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
	BOUNDARY="1589707168-299079281-1112626803=:31462"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: Bill Fenner <fenner@research.att.com>, ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-299079281-1112626803=:31462
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id
	j34F03S31574
Content-Transfer-Encoding: quoted-printable

On Mon, 4 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8=
 wrote:
> 1. assume we type "http://[v6.fe80::1_de0]/" in "the URL bar" of the
>   browser.

I doubt hardly any parsers accept this "v6." notation, and I'd rather=20
they even wouldn't.

Best just to forget about the whole thing? :)

--=20
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--1589707168-299079281-1112626803=:31462
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--1589707168-299079281-1112626803=:31462--



From NorahGraham@addisonwitt.com  Mon Apr  4 11:52: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 LAA20571;
	Mon, 4 Apr 2005 11:52:20 -0400 (EDT)
Received: from cpe-69-76-198-10.kc.res.rr.com ([69.76.198.10])
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DIU0B-0003pt-Ud; Mon, 04 Apr 2005 12:00:37 -0400
Received: from Lrw@localhost by fubo.int (8.11.6/8.11.6); Mon, 04 Apr 2005 12:47:34 -0400
Message-ID: <YtquNQPsLTm4BA0PX2Vg@freedonwloadscenter.com>
From: "Brenda Roper" <NorahGraham@addisonwitt.com>
Reply-To: "Brenda Roper" <NorahGraham@addisonwitt.com>
To: ing-admin@ietf.org
Subject: Over 80% Savings on ALL best-selling XP Pro titles
Date: Mon, 04 Apr 2005 10:45:34 -0600
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2
X-Sender: NorahGraham@addisonwitt.com
Content-Type: multipart/mixed;  boundary="--MoZdDkqoFGTjwKmHhxcy"
X-Spam-Score: 12.1 (++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06

BLw 

----MoZdDkqoFGTjwKmHhxcy
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3D"Content-Language" content=3D"en-us">
<meta name=3D"7g4Z" content=3D"phzj">
<meta name=3D"ProgId" content=3D"I0Pe">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<title>4615254</title>
</head>

<body>

<table border=3D"1" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#003399" width=3D"676" id=3D"AutoNumber1"=
 height=3D"22">
  <tr>
    <td width=3D"118" height=3D"22" align=3D"center" bgcolor=3D"#003399">
    <font face=3D"Arial" size=3D"2" color=3D"#FFFFFF"><b>
    <a style=3D"color: #FFFFFF; text-decoration: none" href=3D"http://wwwg=
lobz.com/?e">
    Browse</a></b></font></td>
    <td width=3D"118" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://wwwglobz.com/?r" style=3D"text-decoration: none">
    <font color=3D"#000000">Search</font></a></b></font></td>
    <td width=3D"119" height=3D"22" align=3D"center"><b><font face=3D"Aria=
l" size=3D"2">
    <a href=3D"http://wwwglobz.com/?B" style=3D"text-decoration: none">
    <font color=3D"#000000">Shop</font></a></font></b></td>
    <td width=3D"119" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://wwwglobz.com/?a" style=3D"text-decoration: none">
    <font color=3D"#000000">My eSoft</font></a></b></font></td>
    <td width=3D"151" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://wwwglobz.com/?E" style=3D"text-decoration: none">
    <font color=3D"#000000">Community</font></a></b></font></td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#111111" width=3D"677" id=3D"AutoNumber2"=
 height=3D"34">
  <tr>
    <td width=3D"194" height=3D"34"><font face=3D"Arial">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/viewitem/backArrow_14x1=
4.gif" width=3D"14" height=3D"14">
    <font size=3D"2"><a href=3D"http://wwwglobz.com/?j">Back to Software O=
verview</a></font></font></td>
    <td width=3D"439" height=3D"34">
    <p align=3D"center"><font face=3D"Arial"><font size=3D"1">
    <a href=3D"http://wwwglobz.com/?b">Home</a> &gt;
    <a href=3D"http://wwwglobz.com/?Q">All Categories</a> &gt;
    <a href=3D"http://wwwglobz.com/?8">Computers</a> &gt;
    <a href=3D"http://wwwglobz.com/?u">Software</a> &gt;
    <a href=3D"http://wwwglobz.com/?p">Operating Systems</a> &gt; </font><=
b>
    <font size=3D"1">Windows</font></b></font></p>
    </td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#111111" width=3D"678" id=3D"AutoNumber3"=
 height=3D"1">
  <tr>
    <td height=3D"1" width=3D"6">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_first=
Dark_6x29.gif" width=3D"6" height=3D"25"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"157" bgcolor=3D"#ffc=
c00" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" border=3D"0"=
 summary height=3D"13">
      <tr>
        <td bgcolor=3D"#f7f7f7" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#e6e6e6" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#d6d6d6" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#ffcc00" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#ffe682" height=3D"1"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle" height=3D"13">
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2"><b=
>All Items</b></font></td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"14">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_midDa=
rkOnLight_14x29.gif" width=3D"14" height=3D"25"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"174" bgcolor=3D"#FFE=
682" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" border=3D"0"=
 summary>
      <tr>
        <td bgcolor=3D"#F7F7F7"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#E6E6E6"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#D6D6D6"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFCC00"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFE682"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle">
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2"><b=
>
        <a href=3D"http://wwwglobz.com/?L">Auctions</a></b></font></td>
      </tr>
      <tr>
        <td></td>
      </tr>
      <tr>
        <td valign=3D"bottom">
        <table height=3D"2" cellspacing=3D"0" cellpadding=3D"0" width=3D"1=
00%" border=3D"0" valign=3D"bottom" summary>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#EFD778" height=3D"1"></td>
          </tr>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#D4BF6A" height=3D"1"></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"14">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_midLi=
ghtLight_14x29.gif" width=3D"14" height=3D"23"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"176" bgcolor=3D"#FFE=
682" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"55" border=3D"0" s=
ummary>
      <tr>
        <td bgcolor=3D"#F7F7F7" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#E6E6E6" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#D6D6D6" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFCC00" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFE682" width=3D"175"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle" width=3D"175">
        <a href=3D"http://wwwglobz.com/?L"><b>
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2">Bu=
y</font></b></a><font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D=
"2"><b><a href=3D"http://wwwglobz.com/?7"> 
        It Now</a></b></font></td>
      </tr>
      <tr>
        <td width=3D"175"></td>
      </tr>
      <tr>
        <td valign=3D"bottom" width=3D"175">
        <table height=3D"2" cellspacing=3D"0" cellpadding=3D"0" width=3D"1=
00%" border=3D"0" valign=3D"bottom" summary>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#EFD778" height=3D"1"></td>
          </tr>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#D4BF6A" height=3D"1"></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"137">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_endLi=
ghtTab_14x29.gif" width=3D"14" height=3D"23"></td>
  </tr>
</table>
<table width=3D"582" bgcolor=3D"#FFFFFF" border=3D"0" cellpadding=3D"0" ce=
llspacing=3D"0" style=3D"border-collapse: collapse" bordercolor=3D"#111111=
">
  <tr>
    <td bgcolor=3D"#FFCC00" width=3D"1"><font face=3D"Arial" size=3D"2">
    <img height=3D"1" src=3D"http://pics.ebaystatic.com/aw/pics/s.gif" wid=
th=3D"1"></font></td>
    <td width=3D"598">
    <table border=3D"1" bgcolor=3D"#FFFFCC" width=3D"676" cellpadding=3D"0=
" cellspacing=3D"0" style=3D"border-collapse: collapse" bordercolor=3D"#FF=
CC00" height=3D"52">
      <tr>
        <td valign=3D"middle" nowrap width=3D"627" height=3D"52"><font fac=
e=3D"Arial">&nbsp;&nbsp;&nbsp;
        <input type=3D"text" name=3D"satitle" size=3D"43" maxlength=3D"300=
" value><font size=3D"2">
        </font><select name=3D"sacategory">
        <option selected>Windows</option>
        <option>Adobe</option>
        <option>Macromedia</option>
        </select><font size=3D"2"> </font><a href=3D"http://wwwglobz.com/?=
6">
        <input type=3D"button" name=3D"bs" value=3D"Search" onclick></a><f=
ont size=3D"2">
        </font></font><span class=3D"navigation"><font size=3D"2" face=3D"=
Arial">
        <a class href=3D"http://wwwglobz.com/?H">Refine Search</a></font><=
/span></td>
      </tr>
    </table>
    </td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#CCCCCC" width=3D"676" id=3D"AutoNumber4"=
 height=3D"234">
  <tr>
    <td width=3D"134" height=3D"234" rowspan=3D"6">
    <table border=3D"1" cellpadding=3D"2" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#FFCC00" width=3D"100%" id=3D"AutoNum=
ber5" height=3D"423" bgcolor=3D"#FFFFCC">
      <tr>
        <td width=3D"100%" height=3D"10" bgcolor=3D"#FFE682">&nbsp;<b><fon=
t face=3D"Arial" size=3D"2">Top 
        Sellers</font></b></td>
      </tr>
      <tr>
        <td width=3D"100%" height=3D"413" valign=3D"top"><font face=3D"Ari=
al" size=3D"1">1&nbsp;&nbsp;
        <a href=3D"http://wwwglobz.com/?h" style=3D"text-decoration: none"=
>Windows 
        XP Pro</a><br>
        2&nbsp;&nbsp;
        <a href=3D"http://wwwglobz.com/?7" style=3D"text-decoration: none"=
>Office 
        XP 2002 Pro</a><br>
        3&nbsp;&nbsp;
        <a href=3D"http://wwwglobz.com/?v" style=3D"text-decoration: none"=
>Adobe 
        Acrobat<br>
&nbsp;&nbsp;&nbsp;&nbsp; 7.0 Professional</a><br>
        4&nbsp;&nbsp;
        <a href=3D"http://wwwglobz.com/?Y" style=3D"text-decoration: none"=
>Adobe 
        Photoshop<br>
&nbsp;&nbsp;&nbsp;&nbsp; CS 8.0</a><br>
        5<a href=3D"http://wwwglobz.com/?y" style=3D"text-decoration: none=
">&nbsp;&nbsp; 
        Office 2003 Pro&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </a><br>
        6&nbsp;&nbsp;
        <a style=3D"text-decoration: none" href=3D"http://wwwglobz.com/?N"=
>Macromedia<br>
&nbsp;&nbsp;&nbsp;&nbsp; Dream Weaver<br>
&nbsp;&nbsp;&nbsp;&nbsp; MX 2004</a><br>
        <a href=3D"http://wwwglobz.com/?w" style=3D"text-decoration: none"=
>
        <font color=3D"#000000">7</font></a>
        <a href=3D"http://wwwglobz.com/?e" style=3D"text-decoration: none"=
>
        <font color=3D"#000000">&nbsp;</font></a>
        <a href=3D"http://wwwglobz.com/?J" style=3D"text-decoration: none"=
>Macromedia 
        Flash<br>
&nbsp;&nbsp;&nbsp;&nbsp; MX 2004 Pro</a><br>
        8&nbsp;&nbsp;
        <a href=3D"http://wwwglobz.com/?d" style=3D"text-decoration: none"=
>MS 
        2003 Server<br>
&nbsp;&nbsp;&nbsp;&nbsp; (Enterprise Edition)</a><br>
        9&nbsp;&nbsp;
        <a href=3D"http://wwwglobz.com/?E" style=3D"text-decoration: none"=
>Norton 
        Antivirus 2005</a><br>
        10 <a href=3D"http://wwwglobz.com/?2" style=3D"text-decoration: no=
ne">
        CorelDraw<br>
&nbsp;&nbsp;&nbsp;&nbsp; Graphics Suite 12.0<br>
        </a>11
        <a href=3D"http://wwwglobz.com/?E" style=3D"text-decoration: none"=
>Adobe 
        Creative Suite<br>
&nbsp;&nbsp;&nbsp;&nbsp; Premium</a><br>
        12 <a href=3D"http://wwwglobz.com/?Z" style=3D"text-decoration: no=
ne">
        Alias Wavefront
        <br</a>6.0<br>
        <font color=3D"#000000">13</font>
        <br</a></a>
        <br</a>
        <a href=3D"http://wwwglobz.com/?U" style=3D"text-decoration: none"=
>Adobe 
        Primer<br>
        </a>14
        <a href=3D"http://wwwglobz.com/?Y" style=3D"text-decoration: none"=
>AutoDesk 
        3d Studio<br>
&nbsp;&nbsp;&nbsp;&nbsp; MAX v6.0</a><br>
        15 <a href=3D"http://wwwglobz.com/?l" style=3D"text-decoration: no=
ne">
        Adobe </a></font>
        <br</a>
        <a href=3D"http://wwwglobz.com/?G" style=3D"text-decoration: none"=
>
        <font face=3D"Arial" size=3D"1">Encore DVD</font></a><br</a></td>
      </tr>
    </table>
    <p>&nbsp;</p>
    <p>&nbsp;</p>
    </td>
    <td width=3D"542" height=3D"18" bgcolor=3D"#D6D6D6" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber6" bgcolor=3D"#E6E6E6">
      <tr>
        <td width=3D"58%" bgcolor=3D"#E6E6E6" align=3D"center">
        <p align=3D"center"><b><font face=3D"Arial" size=3D"2">Featured It=
em</font></b></p>
        </td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">PRlCE</font></b></td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">Bids</font></b></td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">Time Left</font></b></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"97" height=3D"95">
    <p align=3D"center">
    <img border=3D"0" src=3D"http://www.tails.nl/images/xppro.jpg" width=3D=
"101" height=3D"120" align=3D"left"></p>
    </td>
    <td width=3D"214" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2">
    <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/aw/pi=
cs/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
    <a target=3D"helpwin" href=3D"http://wwwglobz.com/?T">&nbsp;Microsoft =
Windows 
    XP PRO<br>
    -Current Edition-</a><br>
    <a target=3D"helpwin" href=3D"http://wwwglobz.com/?K"><br>
    </a></font><font face=3D"Arial" size=3D"1">
    <a target=3D"helpwin" href=3D"http://wwwglobz.com/?z">
    <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://pics.=
ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=3D"=
10"></a> 
    from Our eStore</font></p>
    </td>
    <td width=3D"74" height=3D"95">
    <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$49.95</b>
    <font color=3D"#999999">USD</font></font></p>
    </td>
    <td width=3D"79" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2">1<a target=3D"help=
win" href=3D"http://wwwglobz.com/?7"><br>
    <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://pics.=
ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=3D"=
15"></a></font></p>
    </td>
    <td width=3D"78" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2" color=3D"#660066">=
<nobr>0h 19m</nobr></font></p>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"20" colspan=3D"5" bgcolor=3D"#D6D6D6">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber7" bgcolor=3D"#E6E6E6">
      <tr>
        <td width=3D"80%">
        <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"b=
order-collapse: collapse" bordercolor=3D"#111111" width=3D"100=
%">
          <tr>
            <td width=3D"57%" bgcolor=3D"#E6E6E6" align=3D"center" borderc=
olor=3D"#FFFFFF">
            <p align=3D"center"><b><font face=3D"Arial" size=3D"2">Nevv It=
ems</font></b></p>
            </td>
            <td width=3D"15%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">PRlCE</font></b></td>
            <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">Bids</font></b></td>
            <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">Time Left</font></b></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"45" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber8" height=3D"97">
      <tr>
        <td width=3D"12%" height=3D"97">
        <p align=3D"center">
        <img border=3D"0" src=3D"http://www.imj.co.jp/g-coop/syohin/img/Of=
fice2003.gif" align=3D"left" width=3D"102" height=3D"129"></p>
        </td>
        <td width=3D"25%" height=3D"97">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?d">&nbsp;Micros=
oft 
        Office 2003 PRO or<br>
        Microsoft Office XP PRO</a><br>
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?B"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?I">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"9%" height=3D"97" align=3D"center">
        <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$49.95</b>
        <font color=3D"#999999">USD</font></font></p>
        </td>
        <td width=3D"9%" height=3D"97">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">3<a target=3D"=
helpwin" href=3D"http://wwwglobz.com/?n"><br>
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></p>
        </td>
        <td width=3D"9%" height=3D"97" align=3D"center"><font face=3D"Aria=
l" size=3D"2">0h 15m</font></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"70" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber9" height=3D"99">
      <tr>
        <td width=3D"15%" height=3D"99">
        <img border=3D"0" src=3D"http://www.re-solution.de/img/photoshopcs=
gif" width=3D"103" height=3D"106" align=3D"left"></td>
        <td width=3D"29%" height=3D"99">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?U">&nbsp;Adobe =
Photoshop 
        CS 8.0 or Adobe Acrobat PRO 7.0</a><br>
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?q"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?K">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"11%" height=3D"99" align=3D"center">
        <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$59.95</b>
        <font color=3D"#999999">USD</font></font></p>
        </td>
        <td width=3D"11%" height=3D"99" align=3D"center"><font face=3D"Ari=
al" size=3D"2">8<a target=3D"helpwin" href=3D"http://wwwglobz.com/?c"><br>=

        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></td>
        <td width=3D"10%" height=3D"99" align=3D"center"><font face=3D"Ari=
al" size=3D"2">
        0h 16m</font></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"32" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber10" height=3D"70">
      <tr>
        <td width=3D"15%" height=3D"70">
        <img border=3D"0" src=3D"http://www.hyperpc.co.jp/shozai/soft/flas=
hmxpro2004.jpg" width=3D"113" height=3D"95"></td>
        <td width=3D"30%" height=3D"70">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?F">&nbsp;Macrom=
edia 
        FlashMX Pro 2004 or Macromedia Dreamweaver MX Pro 2004</a><br>
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?9"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://wwwglobz.com/?x">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"11%" height=3D"70" align=3D"center"><font size=3D"2" =
face=3D"Arial">
        <b>$39.95</b> <font color=3D"#999999">USD</font></font></td>
        <td width=3D"11%" height=3D"70" align=3D"center"><font face=3D"Ari=
al" size=3D"2">7<a target=3D"helpwin" href=3D"http://wwwglobz.com/?y"><br>=

        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></td>
        <td width=3D"10%" height=3D"70" align=3D"center"><font face=3D"Ari=
al" size=3D"2">
        0h 14m</font></td>
      </tr>
    </table>
    </td>
  </tr>
</table>

</body>

</html>

----MoZdDkqoFGTjwKmHhxcy--


From ipv6-bounces@ietf.org  Mon Apr  4 14:09:54 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06968
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 14:09:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIW05-0001mw-Fp; Mon, 04 Apr 2005 14:08:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIW03-0001jc-3N
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 14:08:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06579
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 14:08:29 -0400 (EDT)
From: kck@netcom.com
Received: from smtp10.atl.mindspring.net ([207.69.200.246])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIW7x-0003UX-0P
	for ipv6@ietf.org; Mon, 04 Apr 2005 14:16:46 -0400
Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net)
	by smtp10.atl.mindspring.net with esmtp (Exim 3.36 #1)
	id 1DIVzq-0000sB-00
	for ipv6@ietf.org; Mon, 04 Apr 2005 14:08:22 -0400
Message-ID: <28578867.1112638103073.JavaMail.root@wamui04.slb.atl.earthlink.net>
Date: Mon, 4 Apr 2005 11:08:23 -0700 (GMT-07:00)
To: ipv6@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Earthlink Zoo Mail 1.0
X-Spam-Score: 0.3 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Subject: Re: Move forward with scoped literal URI format?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: kck@netcom.com
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

If the browers recognizes and parses the [] I still do no understand why we just do not use % instead of _ and be done with it. Are we saying that escapable characters can make up part of the zone? If not then there does not appear to be a problem and if so, then don't allow.

--kc

-----Original Message-----
From: 
	JINMEI Tatuya / ???? <jinmei@isl.rdc.toshiba.co.jp>
Sent: Apr 4, 2005 12:33 AM
To: Bill Fenner <fenner@research.att.com>
Cc: ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format?

2. then the browser parser parses the entire URL and extracts
   "v6.fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]"
   as delimiters.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr  4 22:14:02 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06809
	for <ipngwg-archive@lists.ietf.org>; Mon, 4 Apr 2005 22:14:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIdYd-0004mn-MR; Mon, 04 Apr 2005 22:12:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIdYa-0004lw-Sz
	for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 22:12:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06682
	for <ipv6@ietf.org>; Mon, 4 Apr 2005 22:12:43 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIdgc-0002zz-BJ
	for ipv6@ietf.org; Mon, 04 Apr 2005 22:21:04 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DIdYQ-000Ok9-Vg; Tue, 05 Apr 2005 02:12:35 +0000
In-Reply-To: <Pine.LNX.4.61.0504041532270.27464@netcore.fi>
References: <e881939938c2c4c6d84496d9ef296c46@isc.org>
	<Pine.LNX.4.61.0504041532270.27464@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9586cbecf7e3c931aec2cec835eda5a3@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Mon, 4 Apr 2005 22:12:02 -0400
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: grow@lists.uoregon.edu, ipv6@ietf.org
Subject: Re: grow: ipv6 anycast
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 4 Apr 2005, at 08:35, Pekka Savola wrote:

> This is a timely topic, because IPv6 WG just less than week ago  
> forwarded the revision of the addressing architecture to be published  
> as Draft Standard. (IPv6 WG is Cc:ed.)
>
> That draft,  
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4 
> -02.txt still has the problematic wording wrt anycast addresses.

Yes, I noticed that. I sent mail to the authors of that draft asking  
them for their thoughts on the anycast issue, but I haven't heard  
anything back, yet.

Assuming there is consensus that v6 anycast for host-based services is  
a fait accompli, and that further prohibition is unnecessary, it would  
seem that adjusting the relevant paragraph in the revised (v4) v6  
addressing spec would be the cleanest way of proceeding.

However, although I think we had some kind of consensus to that effect  
in the grow meeting in Minneapolis, I haven't heard any opinion from  
those ipv6-wg folks who don't also participate in grow. Seems like some  
kind of hum from the ipv6 floor would be useful to hear (or, if no hum,  
active throwing of furniture).


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From JacklynOwen@aalmh.org  Tue Apr  5 01:11: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 BAA18772;
	Tue, 5 Apr 2005 01:11:56 -0400 (EDT)
Received: from user-12l2t64.cable.mindspring.com ([69.81.116.196])
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DIgU2-0000Py-FZ; Tue, 05 Apr 2005 01:20:18 -0400
Received: from Ukj@localhost by 09w.int (8.11.6/8.11.6); Tue, 05 Apr 2005 12:29:08 +0600
Message-ID: <JI60toUeuqBJkwqcP8z2q@nashim.org>
From: "Stacy Reed" <JacklynOwen@aalmh.org>
Reply-To: "Stacy Reed" <JacklynOwen@aalmh.org>
To: ietf-announce-bounces@ietf.org, ipngwg-archive@ietf.org,
        avt-admin@ietf.org, amyk@ietf.org
Subject: Wanted: High Rollers & Fearless Gamblers ID:WyP0
Date: Tue, 05 Apr 2005 12:23:08 +0600
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2
X-Sender: JacklynOwen@aalmh.org
Content-Type: multipart/mixed;  boundary="--3SSwh20FfkTXhfE"
X-Spam-Score: 4.3 (++++)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

kKc7 

----3SSwh20FfkTXhfE
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta name=3D"GENERATOR" content=3D"8QRDAWnIq">
<meta name=3D"ProgId" content=3D"3dnvfnBbLFDzNWd3">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<title>FV92OUPciFGURNKp</title>
</head>

<body>

<p><font face=3D"Arial" size=3D"2">Welcome to MS@Casino - a REVOLUTION in =
Online Gambling!<br>
MS@Casino establishes a turning point in casino history by<br>
uniquely allowing players worldwide to play as dealer thus<br>
receiving some of the most favorable odds normally reserved for<br>
the casino.<br>
<br>
MS@Casino offers popular games, including Blackjack, Roulette,<br>
Slot Machines and Video Poker all featuring unmatched graphics and sounds.=
<br>
<br>
You may play with REAL Money or just play for Fun (no bank details needed)=
<br>
<br>
Questions and Answers<br>
--------------------<br>
<br>
Q: MS@Casino offers matchless credibility and it's easy to check. How ?<br=
>
A: Robert as Player and Graham as Dealer enter one of the games. Once the =
game<br>
is over, they verify that one's losing sum is the other's winning sum.<br>=

<br>
Q: MS@Casino offers the highest payouts available. How is that possible?<b=
r>
A: Payouts are constant in games like Blackjack and Roulette (and for all<=
br>
games with the same rules). MS@Casino 's unique concept allows players to<=
br>
become the Dealer, which improves their winning odds, thus increasing<br>
their payout rates.<br>
<br>
The top daily player (determined at 23:59) gets $200 bonus!<br>
<br>
Winnings generated from playing as Dealer are also accumulated.<br>
<br>
The scoreboard will be updated every hour.<br>
<br>
Visit our site 4highrollers.net - try your luck &amp; no deposit required =
! ! !<br>
<br>
Best regards,<br>
<br>
Benjamin Stein <br>
Casino Manager</font></p>

</body>

</html>

----3SSwh20FfkTXhfE--


From ipv6-bounces@ietf.org  Tue Apr  5 07:08:59 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06713
	for <ipngwg-archive@lists.ietf.org>; Tue, 5 Apr 2005 07:08:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIlnH-0000rJ-LZ; Tue, 05 Apr 2005 07:00:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlnF-0000rE-PI
	for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 07:00:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06051
	for <ipv6@ietf.org>; Tue, 5 Apr 2005 07:00:22 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlvN-0003yV-5s
	for ipv6@ietf.org; Tue, 05 Apr 2005 07:08:50 -0400
Received: from ([128.244.124.185])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10131903;
	Tue, 05 Apr 2005 06:59:45 -0400
In-Reply-To: <9586cbecf7e3c931aec2cec835eda5a3@isc.org>
References: <e881939938c2c4c6d84496d9ef296c46@isc.org>
	<Pine.LNX.4.61.0504041532270.27464@netcore.fi>
	<9586cbecf7e3c931aec2cec835eda5a3@isc.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Message-Id: <a8df34789f5d5bc7942fc863806c465e@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Tue, 5 Apr 2005 06:59:45 -0400
To: Joe Abley <jabley@isc.org>
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: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: grow@lists.uoregon.edu, ipv6@ietf.org, Pekka Savola <pekkas@netcore.fi>
Subject: Re: grow: ipv6 anycast
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1979559579=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============1979559579==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--899883679;
	protocol="application/pkcs7-signature"


--Apple-Mail-2--899883679
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi Joe,

On Apr 4, 2005, at 22:12, Joe Abley wrote:

>
> On 4 Apr 2005, at 08:35, Pekka Savola wrote:
>
>> This is a timely topic, because IPv6 WG just less than week ago  
>> forwarded the revision of the addressing architecture to be published  
>> as Draft Standard. (IPv6 WG is Cc:ed.)
>>
>> That draft,  
>> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4 
>> -02.txt still has the problematic wording wrt anycast addresses.
>
> Yes, I noticed that. I sent mail to the authors of that draft asking  
> them for their thoughts on the anycast issue, but I haven't heard  
> anything back, yet.

As a note, the current editor is only intermittently reachable due to  
personal travel.

>
> Assuming there is consensus that v6 anycast for host-based services is  
> a fait accompli, and that further prohibition is unnecessary, it would  
> seem that adjusting the relevant paragraph in the revised (v4) v6  
> addressing spec would be the cleanest way of proceeding.

My personal opinion is that the restriction should be lifted.

>
> However, although I think we had some kind of consensus to that effect  
> in the grow meeting in Minneapolis, I haven't heard any opinion from  
> those ipv6-wg folks who don't also participate in grow. Seems like  
> some kind of hum from the ipv6 floor would be useful to hear (or, if  
> no hum, active throwing of furniture).
>

I will pose that question to the group and report back.

Regards,
Brian


--Apple-Mail-2--899883679
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA1MTA1OTQ2WjAjBgkqhkiG9w0B
CQQxFgQUD5z4v56LM8d3seQZ2PeajvSKRvEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEAPdlG5TDtHiXWQmHiBqydip6R5znH/sB/SYvssjadhcaWWJUb945R7u5j8T7R0FBrG05E
0HE3pgaQCM7Hmw004vCCaPXmSMskHFnhtBpsxE+opmCAwQYFqSxAjdoJCI46ve9zhAbQUHXR1Ved
H7wZ87fkiU6Ji8KqT7ICPUBi2bXLD9smGlro1EGokKvc2LDFgM7MB4tTsDq4ecqhB2UfVZTqibkN
UnfXOxK483S7kyi1qDAOxbnfZ9JU9akH17mK4GjiVO2iltEq08YQdXZd4DqSJFtKPSM2HWf9gAZy
MFjVxTyr6deBwd4sRmbIpLY8eqnh3dqUoNMlYm4zspWPEQAAAAAAAA==

--Apple-Mail-2--899883679--



--===============1979559579==
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
--------------------------------------------------------------------

--===============1979559579==--




From ipv6-bounces@ietf.org  Tue Apr  5 15:57:32 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03513
	for <ipngwg-archive@lists.ietf.org>; Tue, 5 Apr 2005 15:57:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DItoK-0005Pe-Mk; Tue, 05 Apr 2005 15:34:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DItoG-0005OF-Pg; Tue, 05 Apr 2005 15:34:00 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24520;
	Tue, 5 Apr 2005 15:33:58 -0400 (EDT)
Message-Id: <200504051933.PAA24520@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, 05 Apr 2005 15:33:58 -0400
Cc: ipv6@ietf.org
Subject: I-D ACTION:draft-ietf-ipv6-privacy-addrs-v2-03.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: Privacy Extensions for Stateless Address Autoconfiguration in IPv6
	Author(s)	: T. Narten, et al.
	Filename	: draft-ietf-ipv6-privacy-addrs-v2-03.txt
	Pages		: 32
	Date		: 2005-4-5
	
Nodes use IPv6 stateless address autoconfiguration to generate
   addresses without the necessity of a Dynamic Host Configuration
   Protocol (DHCP) server.  Addresses are formed by combining network
   prefixes with an interface identifier.  On interfaces that contain
   embedded IEEE Identifiers, the interface identifier is typically
   derived from it.  On other interface types, the interface identifier
   is generated through other means, for example, via random number
   generation.  This document describes an extension to IPv6 stateless
   address autoconfiguration for interfaces whose interface identifier
   is derived from an IEEE identifier.  Use of the extension causes
   nodes to generate global scope addresses from interface identifiers
   that change over time, even in cases where the interface contains an
   embedded IEEE identifier.  Changing the interface identifier (and the
   global scope addresses generated from it) over time makes it more
   difficult for eavesdroppers and other information collectors to
   identify when different addresses used in different transactions
   actually correspond to the same node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipv6-privacy-addrs-v2-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-4-5160209.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipv6-privacy-addrs-v2-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-4-5160209.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 milord@emailaccount.com  Tue Apr  5 21:05:08 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07395;
	Tue, 5 Apr 2005 21:05:08 -0400 (EDT)
Received: from [211.109.220.152] (helo=132.151.6.1)
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DIz6y-0006Yz-Mv; Tue, 05 Apr 2005 21:13:42 -0400
Received: from eleazar.finessed-upstand.com (HELO alvarez.com 66.4.188.47)
  by barbados.com with EMQP; Wed, 06 Apr 2005 04:00:54 +0200
Date: Wed, 06 Apr 2005 00:59:54 -0100
From: "Susie Orr" <milord@emailaccount.com>
Message-Id: <CFE5.AA79.9A11milord@emailaccount.com>
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org
Subject: Notification: We offer low rates
X-Mailer: CompuServe 7.0
X-Spam-Score: 9.7 (+++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.3-m-n.net/sign.asp



 Best Regards,

 Fannie Palmer
 
 to be remov(ed:	http://www.3-m-n.net/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Tue Apr  5 21:08:02 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07766
	for <ipngwg-archive@lists.ietf.org>; Tue, 5 Apr 2005 21:08:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIyyX-0000CH-Km; Tue, 05 Apr 2005 21:04:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyyU-0000C9-RF
	for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 21:04:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07342
	for <ipv6@ietf.org>; Tue, 5 Apr 2005 21:04:52 -0400 (EDT)
Received: from e32.co.us.ibm.com ([32.97.110.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIz6i-0006Yi-AD
	for ipv6@ietf.org; Tue, 05 Apr 2005 21:13:26 -0400
Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com
	[9.17.195.107])
	by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3614g5j660560
	for <ipv6@ietf.org>; Tue, 5 Apr 2005 21:04:42 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169])
	by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j3614grg192714 for <ipv6@ietf.org>; Tue, 5 Apr 2005 19:04:42 -0600
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1])
	by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j3614gIM028821 for <ipv6@ietf.org>; Tue, 5 Apr 2005 19:04:42 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-49-158-172.mts.ibm.com
	[9.49.158.172])
	by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j3614fHg028804; Tue, 5 Apr 2005 19:04:42 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j3614Bau005456;
	Tue, 5 Apr 2005 21:04:12 -0400
Message-Id: <200504060104.j3614Bau005456@cichlid.raleigh.ibm.com>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
In-Reply-To: Message from JINMEI Tatuya /
	=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp> 
	of "Mon, 04 Apr 2005 11:52:43 +0900." <y7vfyy7i77o.wl@ocean.jinmei.org> 
Date: Tue, 05 Apr 2005 21:04:11 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Kristine Adamson <adamson@us.ibm.com>, ipv6@ietf.org
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp> writes:

> >>>>> On Fri, 1 Apr 2005 06:13:22 -0700, 
> >>>>> Kristine Adamson <adamson@us.ibm.com> said:

> > Thanks for the responses.  But if RFC3542 is not updated, won't this 
> > adversely affect the portability of applications that references these new 
> > codes?

> Yes, it will.  However, the point is whether the portability issue is
> serious enough to require a revision of RFC3542.  Different people may
> have different opinions on this, and I personally don't think it's big
> enough.

Suggestion:

1) Set up an issue tracker for this (and perhaps every IPv6 RFC for
   which there are some known errors/omissions?) that keeps track of
   these sorts of things. That way folk will be able to more easily
   find the list of outstanding issues (and their likely resolution),
   and we (the IETF community) won't lose track of them.

2) Although it may be overkill in this case, one could easily publish
   a (very!) short RFC just listing the additional code points, so
   that they are documened in the RFC series, and folk looking at the
   older RFC can find the new RFC via the "updated by" tag.

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Tue Apr  5 21:52:46 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11603
	for <ipngwg-archive@lists.ietf.org>; Tue, 5 Apr 2005 21:52:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIzdY-0001wn-OD; Tue, 05 Apr 2005 21:47:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIzdS-0001wc-CG
	for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 21:47:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11161
	for <ipv6@ietf.org>; Tue, 5 Apr 2005 21:47:11 -0400 (EDT)
Received: from e33.co.us.ibm.com ([32.97.110.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIzli-0007wv-2v
	for ipv6@ietf.org; Tue, 05 Apr 2005 21:55:46 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com
	[9.17.195.11])
	by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j361l44I541080
	for <ipv6@ietf.org>; Tue, 5 Apr 2005 21:47:04 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j361l3Ws232254 for <ipv6@ietf.org>; Tue, 5 Apr 2005 19:47:03 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1])
	by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j361l3Bl011695 for <ipv6@ietf.org>; Tue, 5 Apr 2005 19:47:03 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-49-158-172.mts.ibm.com
	[9.49.158.172])
	by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j361l26i011685; Tue, 5 Apr 2005 19:47:03 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j361kQR1005635;
	Tue, 5 Apr 2005 21:46:30 -0400
Message-Id: <200504060146.j361kQR1005635@cichlid.raleigh.ibm.com>
To: Perry Lorier <perry@coders.net>
In-Reply-To: Message from Perry Lorier <perry@coders.net> 
	of "Mon, 04 Apr 2005 23:47:55 +1200." <4251296B.1020900@coders.net> 
Date: Tue, 05 Apr 2005 21:46:26 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: Bill Fenner <fenner@research.att.com>, ipv6@ietf.org
Subject: Re: Move forward with scoped literal URI format? 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Perry Lorier <perry@coders.net> writes:

> Bill Fenner wrote:
> > I usually think of the small home router configuration problem -
> > buy a box, plug it in, it wants you to configure it using a web
> > page, and it's probably fe80::1.  I don't have any systems in my
> > house that have fewer than two non-loopback interfaces.  Since
> > this is presumably a one-off, I guess the default interface
> > configuration is an option, if a little clumsy.

> I don't understand this use case.  Assuming I have a router and it's
> manual says type in http://<some-link-local-address><some-delimiter>de0/
> it's going to fail on my Linux machine that uses eth0, and if it says
> use "eth0" it's going to fail on the other Linux machine that has eth1
> on that network.  Link local addresses (that include an interface
> identifier) don't make sense outside of the local machine, including in
> printed documentation.

Right. It's important to remember that zone ids are a local name space
-- one doesn't know what the zone names are on someone else's machine
or at a different site. Thus, anyone shipping a product that says
"configure me by typing in the following address into your browser"
can't include a zone id.

A very sophisticated user might know about scopes and be able to add
an appropriate zone id in some cases, but for the general user, this
is well beyond what can be reasonably expected.

So I don't see how literals with zone ids play a useful part of
simplifying config, as in the home router config case.

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 02:42:23 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06225
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 02:42:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJ4CH-0007Dy-UJ; Wed, 06 Apr 2005 02:39:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqwV-0002t3-MR
	for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 12:30:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06594
	for <ipv6@ietf.org>; Tue, 5 Apr 2005 12:30:16 -0400 (EDT)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIr4g-00087X-OV
	for ipv6@ietf.org; Tue, 05 Apr 2005 12:38:47 -0400
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.2/8.13.2) with ESMTP id j35GUA2o012222;
	Tue, 5 Apr 2005 09:30:10 -0700
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.2/8.12.11/Submit) id j35GU8OE012221;
	Tue, 5 Apr 2005 09:30:08 -0700
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Tue, 5 Apr 2005 09:30:08 -0700
From: David Meyer <dmm@1-4-5.net>
To: Brian Haberman <brian@innovationslab.net>
Message-ID: <20050405163008.GA12200@1-4-5.net>
References: <e881939938c2c4c6d84496d9ef296c46@isc.org>
	<Pine.LNX.4.61.0504041532270.27464@netcore.fi>
	<9586cbecf7e3c931aec2cec835eda5a3@isc.org>
	<a8df34789f5d5bc7942fc863806c465e@innovationslab.net>
Mime-Version: 1.0
In-Reply-To: <a8df34789f5d5bc7942fc863806c465e@innovationslab.net>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
X-Mailman-Approved-At: Wed, 06 Apr 2005 02:39:27 -0400
Cc: grow@lists.uoregon.edu, ipv6@ietf.org, Pekka Savola <pekkas@netcore.fi>
Subject: Re: grow: ipv6 anycast
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0672969107=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============0672969107==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7"
Content-Disposition: inline


--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 05, 2005 at 06:59:45AM -0400, Brian Haberman wrote:
> Hi Joe,
>=20
> On Apr 4, 2005, at 22:12, Joe Abley wrote:
>=20
> >
> >On 4 Apr 2005, at 08:35, Pekka Savola wrote:
> >
> >>This is a timely topic, because IPv6 WG just less than week ago =20
> >>forwarded the revision of the addressing architecture to be published =
=20
> >>as Draft Standard. (IPv6 WG is Cc:ed.)
> >>
> >>That draft, =20
> >>http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4=20
> >>-02.txt still has the problematic wording wrt anycast addresses.
> >
> >Yes, I noticed that. I sent mail to the authors of that draft asking =20
> >them for their thoughts on the anycast issue, but I haven't heard =20
> >anything back, yet.
>=20
> As a note, the current editor is only intermittently reachable due to =20
> personal travel.
>=20
> >
> >Assuming there is consensus that v6 anycast for host-based services is =
=20
> >a fait accompli, and that further prohibition is unnecessary, it would =
=20
> >seem that adjusting the relevant paragraph in the revised (v4) v6 =20
> >addressing spec would be the cleanest way of proceeding.
>=20
> My personal opinion is that the restriction should be lifted.

	Likewise.

> >However, although I think we had some kind of consensus to that effect =
=20
> >in the grow meeting in Minneapolis, I haven't heard any opinion from =20
> >those ipv6-wg folks who don't also participate in grow. Seems like =20
> >some kind of hum from the ipv6 floor would be useful to hear (or, if =20
> >no hum, active throwing of furniture).
> >
>=20
> I will pose that question to the group and report back.

	Thanks Brian.

	Dave


--1yeeQ81UyVL57Vl7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCUr0QORgD1qCZ2KcRAij9AJ9ygXxWKSpvC4n4HCHZtAPIMqzFnwCcDMsh
urXdLrxm+ZStiw2hGHxez5I=
=VtBJ
-----END PGP SIGNATURE-----

--1yeeQ81UyVL57Vl7--


--===============0672969107==
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
--------------------------------------------------------------------

--===============0672969107==--



From ipv6-bounces@ietf.org  Wed Apr  6 10:10:32 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15210
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 10:10:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJBDo-000078-M2; Wed, 06 Apr 2005 10:09:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBDm-0008W1-5Z
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 10:09:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14969
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 10:09:28 -0400 (EDT)
Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBM8-0000AW-NB
	for ipv6@ietf.org; Wed, 06 Apr 2005 10:18:09 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Wed, 6 Apr 2005 10:09:22 -0400
Message-ID: <BBC4EAA361F44F45AB1EC1915D0CF5244D4CE2@rvnj-mail.radvision.com>
Thread-Topic: Ordering of % and / in  RFC 4007
Thread-Index: AcU5z9jaa70gG3xPRq2FfqB5wm7V2wAHGWzA
From: "Steve Cipolli" <SCipolli@radvision.com>
To: <ipv6@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: quoted-printable
Subject: Ordering of % and / in  RFC 4007
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable


Can someone explain the rational for why RFC 4007 mandates the scope
zone index before the prefix in the textual representation? =20

It appears to be the reverse of what I would expect.  A prefix is
assocaited with the IP address itself (in6_addr), while the scope zone
index is associated with the socket address (sockaddr_in6), therefore it
would appear to make more sense if the prefix were bound more closely to
the IP address than the scope zone index.

To illustrate:

Suppose we have a function in6_addr_pton which converts a textual
representation of an IP address to an in6_addr.  I would expect such a
function to accept prefix notation, but not scope zone index notation
(since scope_id is stored in a sockaddr_in6 and not in an in6_addr). =20

Likewise, assuming a function, sockaddr_in6_pton, which converts a
textual representation of a transport address (i.e. IP + port), I would
expect it to accept both prefix (passed with IP address to
in6_addr_pton) and scope zone index (as well as port) notation.=20

/* Convert text in the form "ip6 ['/' prefix]" to in6_addr */
int in6_addr_pton(const char* str, in6_addr* addr) {}

/* Convert text in the form "'[' ip6 ['/' prefix] ['%' scope] ']' ':'
port" to sockaddr_in6 */
int sockaddr_in6_pton(const char* str, socketaddr_in6* sa) {
	call in6_addr_pton() with substring "ip6 ['/' prefix]" to
extract IP address to sa.sin6_addr
	extract scope ID (if present) to sa.sin6_scope_id
	extract port to sa.sin6_port
}

Section 11.7 says its important to put the scope zone index first for
parsing by name-to-address functions and references a document that I
was unable to find.  I understand the "name-to-address functions" to
mean getaddrinfo.  However I'm not clear why getaddrinfo should care
that scope zone index appeared first assuming the substring "ip6 ['/'
prefix]" were handled by a function similar in6_addr_pton above.

--Stephen

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Brian Haberman
Sent: Tuesday, April 05, 2005 7:00 AM
To: Joe Abley
Cc: grow@lists.uoregon.edu; ipv6@ietf.org; Pekka Savola
Subject: Re: grow: ipv6 anycast


Hi Joe,

On Apr 4, 2005, at 22:12, Joe Abley wrote:

>
> On 4 Apr 2005, at 08:35, Pekka Savola wrote:
>
>> This is a timely topic, because IPv6 WG just less than week ago
>> forwarded the revision of the addressing architecture to be published

>> as Draft Standard. (IPv6 WG is Cc:ed.)
>>
>> That draft,
>> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4=20
>> -02.txt still has the problematic wording wrt anycast addresses.
>
> Yes, I noticed that. I sent mail to the authors of that draft asking
> them for their thoughts on the anycast issue, but I haven't heard =20
> anything back, yet.

As a note, the current editor is only intermittently reachable due to =20
personal travel.

>
> Assuming there is consensus that v6 anycast for host-based services is
> a fait accompli, and that further prohibition is unnecessary, it would

> seem that adjusting the relevant paragraph in the revised (v4) v6 =20
> addressing spec would be the cleanest way of proceeding.

My personal opinion is that the restriction should be lifted.

>
> However, although I think we had some kind of consensus to that effect
> in the grow meeting in Minneapolis, I haven't heard any opinion from =20
> those ipv6-wg folks who don't also participate in grow. Seems like =20
> some kind of hum from the ipv6 floor would be useful to hear (or, if =20
> no hum, active throwing of furniture).
>

I will pose that question to the group and report back.

Regards,
Brian


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 11:17:25 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23666
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 11:17:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJC6C-0005Eh-0h; Wed, 06 Apr 2005 11:05:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJC66-0005EH-9b; Wed, 06 Apr 2005 11:05:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21002;
	Wed, 6 Apr 2005 11:05:35 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DJCET-00029u-L8; Wed, 06 Apr 2005 11:14:17 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1DJC65-00079W-LC; Wed, 06 Apr 2005 11:05:37 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1DJC65-00079W-LC@newodin.ietf.org>
Date: Wed, 06 Apr 2005 11:05:37 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: ipv6@ietf.org
Subject: Last Call: 'IP Version 6 Addressing Architecture' to Draft Standard
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

The IESG has received a request from the IP Version 6 Working Group WG to 
consider the following document:

- 'IP Version 6 Addressing Architecture'
   <draft-ietf-ipv6-addr-arch-v4-02.txt> as a Draft Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-20.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.txt

Implementation Report can be accessed at
http://www.ietf.org/IESG/implementation.html


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 13:08:03 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06091
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 13:08:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJDze-0004VE-O8; Wed, 06 Apr 2005 13:07:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJDzc-0004R8-Bc; Wed, 06 Apr 2005 13:07:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05869;
	Wed, 6 Apr 2005 13:07:01 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DJE7y-0006W6-AO; Wed, 06 Apr 2005 13:15:44 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DJDzT-0005Ck-Aw; Wed, 06 Apr 2005 17:06:55 +0000
In-Reply-To: <E1DJC65-00079W-LC@newodin.ietf.org>
References: <E1DJC65-00079W-LC@newodin.ietf.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2acad42b941e3e04dcc125df10bb6d7f@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Wed, 6 Apr 2005 13:06:22 -0400
To: iesg@ietf.org
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Cc: grow@lists.uoregon.edu, ipv6@ietf.org
Subject: Re: Last Call: 'IP Version 6 Addressing Architecture' to Draft
	Standard
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

I would like to propose that the restriction on the use of anycast for 
host-based services be lifted in conjunction with the revision to the 
v6 addressing specification. Specifically, that the following text in 
section 2.6 be removed:

>    There is little experience with widespread, arbitrary use of 
> Internet
>    anycast addresses, and some known complications and hazards when
>    using them in their full generality [ANYCST].  Until more experience
>    has been gained and solutions are specified, the following
>    restrictions are imposed on IPv6 anycast addresses:
>
>       o An anycast address must not be used as the source address of an
>         IPv6 packet.
>
>       o An anycast address must not be assigned to an IPv6 host, that
>         is, it may be assigned to an IPv6 router only.

An alternative approach (updating the addressing spec using a separate 
document) can be found in draft-jabley-v6-anycast-clarify-00. To 
paraphrase that draft, there is increasing production experience with 
the use of anycast to distribute services with both IPv4 and IPv6, and 
I believe we have reached a suitable point in our experience with 
anycast that the restrictions quoted above can be lifted.

There is community support for this position, most recently expressed 
at the grow meeting Minneapolis (and in subsequent messages to the grow 
list). I have also received  private mail in support of this proposal; 
I have not yet heard anybody speak in support of retaining the text 
above. Brian Haberman tells me he will shortly raise the question on 
the ipv6 list, to gauge opinion there.

[There are many caveats for the deployment of anycast services, and the 
technique is certainly not universally applicable to all routing 
systems and all services. A treatment of the applicability and 
potential pitfalls in anycast deployment (for both v4 and v6) is in 
progress in draft-ietf-grow-anycast-00. This draft is at least another 
rev away from wglc, but such a rev could probably be made to happen 
fairly quickly if the v6 anycast position was to be clarified (e.g. in 
the interests of providing a stable normative reference for 
draft-ietf-ipv6-addr-arch-v4).]

Regards,


Joe

On 6 Apr 2005, at 11:05, The IESG wrote:

> The IESG has received a request from the IP Version 6 Working Group WG 
> to
> consider the following document:
>
> - 'IP Version 6 Addressing Architecture'
>    <draft-ietf-ipv6-addr-arch-v4-02.txt> as a Draft Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-20.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.txt
>
> Implementation Report can be accessed at
> http://www.ietf.org/IESG/implementation.html
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 13:26:39 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08071
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 13:26:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJEFm-00032E-2w; Wed, 06 Apr 2005 13:23:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEFj-000329-P0
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 13:23:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07747
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 13:23:40 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEO7-000746-7A
	for ipv6@ietf.org; Wed, 06 Apr 2005 13:32:24 -0400
Received: from ([128.244.96.122])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10195871;
	Wed, 06 Apr 2005 13:23:00 -0400
Mime-Version: 1.0 (Apple Message framework v619.2)
To: IPv6 WG <ipv6@ietf.org>
Message-Id: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Wed, 6 Apr 2005 13:22:58 -0400
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: 32b73d73e8047ed17386f9799119ce43
Cc: Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1379372943=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============1379372943==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--790490975;
	protocol="application/pkcs7-signature"


--Apple-Mail-2--790490975
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

All,
      I am soliciting input on a proposal to modify the rules defined
in the current addressing architecture draft with respect to anycast.
There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change
the following text in the addressing architecture:

       o An anycast address must not be used as the source address of an
          IPv6 packet.

       o An anycast address must not be assigned to an IPv6 host, that
          is, it may be assigned to an IPv6 router only.

to

    o  An anycast address MAY be used as the source address of an IPv6
        packet.
    o  An anycast address MAY be assigned to an IPv6 host.

This change will allow users to operate IPv6 anycast services in the 
same
manner in which they do today with IPv4 anycast.

I would like people to chime in before April 15, 2005 with their 
opinion on
making this change.

It should be noted that the addressing architecture is currently in 
IETF Last
Call.

Regards,
Brian
--Apple-Mail-2--790490975
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA2MTcyMjU5WjAjBgkqhkiG9w0B
CQQxFgQUvtDhYdbJSD8kpSkG7Ga+CrA36GQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEAcvUbjeqYlsI1zXaO82LHrLChKRmL2l3lZYMC+hKhsCgKpR+G6fJb/x3ikWV0vt3PViNy
OnNQzgOTtdv7mV92n/VtRehciad6AMhu3L3JUd1InQlyLvzqaWhlbfrilDDMsB5i4y3JCDecEa1V
SBwJZsB0WWdwU9ZaIVo6SGduxbG119C6k/RMu0W38m6mxfrEX8iDMmOJufMQ9qfATTIgNLNa9f5Q
GaHXBDzEYMI5l4rTuNeGrEnNj+h0+GWeaHYlzqjEvWVi+CbBNTBcq3yfNuPV6eUDegEICVg6vPyS
H4srwRHD4/rs/3+YuDX05YlTq5vGb01YpIZBsoBqOpdfBQAAAAAAAA==

--Apple-Mail-2--790490975--



--===============1379372943==
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
--------------------------------------------------------------------

--===============1379372943==--




From ipv6-bounces@ietf.org  Wed Apr  6 14:56:59 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15576
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 14:56:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJFbn-000807-EP; Wed, 06 Apr 2005 14:50:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFbl-000802-Cw
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 14:50:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14977
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 14:50:31 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFkA-0000ry-IT
	for ipv6@ietf.org; Wed, 06 Apr 2005 14:59:14 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 06 Apr 2005 11:50:24 -0700
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j36IoLgT010670;
	Wed, 6 Apr 2005 11:50:21 -0700 (PDT)
In-Reply-To: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Wed, 6 Apr 2005 11:50:19 -0700
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Define "anycast address" in this question?

An IPv6 anycast address is indistinguishable from an IPv6 unicast  
address. As such, any rule prohibiting the use of an anycast address in  
any location is unenforceable - I have no way to identify an anycast  
address to apply the rule.

I didn't see the draft, but I was talking with Eric Nordmark about a  
notion I have that IP Mobility would be very useful in anycast  
services, and he told me that he had actually described it a year  
earlier. OK, so it's his proposal... Anycast works pretty well with  
DNS, and presumably with similar services that do not set up long tem  
associations. But with anything that routinely opens a TCP session, the  
use of anycast exposes the user to a problem when routing changes  
sufficiently to change servers. All of a sudden he's talking to someone  
who has no idea what he's talking about. The simple solution is to use  
Optimized Routing - connect to the AnyCast address, obtain the fixed  
address of the server as a Care-of Address, and then talk with the  
care-of address. You get the "nearest" server, a benefit of anycast,  
and then get to talk with it reliably even if routing changes. The big  
problem with this is that one has to open an IPSEC association with the  
anycast address, which this rule precludes.

I think that there is a good operational reason to allow for that  
model, which means that one really does need to be able to use the  
anycast address a a source just long enough to obtain the care-of  
address. I think it would be good for the document to describe the  
scenario and impose appropriate limits (you don't talk all day to the  
anycast address, you only use it to find the peer and get a better  
address for him), but it should allow for the scenario.

On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote:

> All,
>      I am soliciting input on a proposal to modify the rules defined
> in the current addressing architecture draft with respect to anycast.
> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change
> the following text in the addressing architecture:
>
>       o An anycast address must not be used as the source address of an
>          IPv6 packet.
>
>       o An anycast address must not be assigned to an IPv6 host, that
>          is, it may be assigned to an IPv6 router only.
>
> to
>
>    o  An anycast address MAY be used as the source address of an IPv6
>        packet.
>    o  An anycast address MAY be assigned to an IPv6 host.
>
> This change will allow users to operate IPv6 anycast services in the  
> same
> manner in which they do today with IPv4 anycast.
>
> I would like people to chime in before April 15, 2005 with their  
> opinion on
> making this change.
>
> It should be noted that the addressing architecture is currently in  
> IETF Last
> Call.
>
> Regards,
> Brian------------------------------------------------------------------ 
> --
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 15:22:57 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19227
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 15:22:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJFxY-0001u6-87; Wed, 06 Apr 2005 15:13:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFxW-0001u1-0B
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 15:13:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17984
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 15:13:00 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJG5v-0001fg-7d
	for ipv6@ietf.org; Wed, 06 Apr 2005 15:21:43 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DJFxJ-0005Tx-0D; Wed, 06 Apr 2005 19:12:49 +0000
In-Reply-To: <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <53d287f38cdaf4d20dda471b03eb4e1e@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Wed, 6 Apr 2005 15:12:16 -0400
To: Fred Baker <fred@cisco.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Brian Haberman <brian@innovationslab.net>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 6 Apr 2005, at 14:50, Fred Baker wrote:

> Define "anycast address" in this question?

A single unicast address bound to multiple interfaces.

> An IPv6 anycast address is indistinguishable from an IPv6 unicast 
> address. As such, any rule prohibiting the use of an anycast address 
> in any location is unenforceable - I have no way to identify an 
> anycast address to apply the rule.

Correct. However, the v6 addressing spec prohibits the use of an 
anycast address from being used as the source address in a datagram, or 
being bound to an interface on a host. These two restrictions 
effectively prohibit the use of anycast as a service distribution 
mechanism.

I would note that the rule is indeed problematic to enforce, as is 
reflected in the various v6 services that are currently provided in 
violation of these restrictions.

> I didn't see the draft, but I was talking with Eric Nordmark about a 
> notion I have that IP Mobility would be very useful in anycast 
> services, and he told me that he had actually described it a year 
> earlier. OK, so it's his proposal... Anycast works pretty well with 
> DNS, and presumably with similar services that do not set up long tem 
> associations. But with anything that routinely opens a TCP session, 
> the use of anycast exposes the user to a problem when routing changes 
> sufficiently to change servers.

Absolutely. Anycast is not inherently unsuitable for use in 
distributing services over TCP, but there are certainly dangers 
involved in doing so. These are discussed at some length in 
draft-ietf-grow-anycast-00.

> [...]
>
> I think that there is a good operational reason to allow for that 
> model, which means that one really does need to be able to use the 
> anycast address a a source just long enough to obtain the care-of 
> address. I think it would be good for the document to describe the 
> scenario and impose appropriate limits (you don't talk all day to the 
> anycast address, you only use it to find the peer and get a better 
> address for him), but it should allow for the scenario.

I believe that use of anycast (as a brief locator service, so that 
subsequent long-held TCP services can be provided using unicast 
addresses) is in draft-ietf-grow-anycast-00. If it's not, it has been 
suggested by others and is in my list of things to incorporate into 
-01.


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 16:15:45 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29984
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 16:15:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJGqQ-0000QX-9V; Wed, 06 Apr 2005 16:09:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJGqO-0000QS-I5
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:09:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29265
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 16:09:42 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com ([130.76.32.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGym-0005Ht-Hr
	for ipv6@ietf.org; Wed, 06 Apr 2005 16:18:26 -0400
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
	NAA14214; Wed, 6 Apr 2005 13:09:26 -0700 (PDT)
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
	j36K9PL03813; Wed, 6 Apr 2005 13:09:25 -0700 (PDT)
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); 
	Wed, 6 Apr 2005 16:09:24 -0400
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: Wed, 6 Apr 2005 16:09:24 -0400
Message-ID: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
Thread-Topic: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
thread-index: AcU64weUttcPwKc1Q/CtdAQmaZucagAAGKGA
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: "Joe Abley" <jabley@isc.org>
X-OriginalArrivalTime: 06 Apr 2005 20:09:24.0859 (UTC)
	FILETIME=[876784B0:01C53AE4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 WG <ipv6@ietf.org>
Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

From: Joe Abley [mailto:jabley@isc.org]

> Correct. However, the v6 addressing spec prohibits the use of an=20
> anycast address from being used as the source address in a=20
> datagram, or=20
> being bound to an interface on a host. These two restrictions=20
> effectively prohibit the use of anycast as a service distribution=20
> mechanism.

Any reason why the same rules that apply to multicast addresses wouldn't =
also work here?

The destination address is anycast, to find the service. But the source =
address in the reply is the unicast address of the first server to =
respond, which presumably is the closest one at the time.

This may circumvent the authentication issues, by making any subsequent =
TCP session start as a regular unicast?

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 16:51:09 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03101
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 16:51:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJHNi-0002PQ-Fm; Wed, 06 Apr 2005 16:44:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHNf-0002P8-BU
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:44:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02509
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 16:44:04 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHW4-0006JL-J4
	for ipv6@ietf.org; Wed, 06 Apr 2005 16:52:49 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net
	[IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net",
	Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id 627321BC;
	Wed,  6 Apr 2005 16:43:48 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id B28B741EA;
	Wed,  6 Apr 2005 16:43:47 -0400 (EDT)
Date: Wed, 06 Apr 2005 16:43:47 -0400
From: Rob Austein <sra@isc.org>
To: IPv6 WG <ipv6@ietf.org>
In-Reply-To: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050406204347.B28B741EA@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Wed, 6 Apr 2005 13:22:58 -0400, Brian Haberman wrote:
> 
> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change
> the following text in the addressing architecture:
> 
>        o An anycast address must not be used as the source address of an
>           IPv6 packet.
> 
>        o An anycast address must not be assigned to an IPv6 host, that
>           is, it may be assigned to an IPv6 router only.
> 
> to
> 
>     o  An anycast address MAY be used as the source address of an IPv6
>         packet.
>     o  An anycast address MAY be assigned to an IPv6 host.
> 
> This change will allow users to operate IPv6 anycast services in the
> same manner in which they do today with IPv4 anycast.

I support making this change.  As far as I can tell, the current
restrictions on IPv6 anycast, while written with the best of
intentions, serve no purpose other than to forbid every real current
use of anycast addresses, and are honored entirely in the breach.
Removing these restrictions is just recognizing that we have learned
something from experience since the restrictions were written.

Use of anycast with TCP (or any protocol in which state crosses packet
boundaries) is a very tricky subject in which black and white answers
are suspect and everything is some shade of grey.  However, I believe
that the GROW WG is already addressing this, in the correct way, by
attempting to detail the considerations for use of such protocols with
anycast.  As far as I can tell, the issues are identical for IPv4 and
IPv6, and informed discussion of them depends heavily on operational
experience with routing protocols, so I think that the GROW WG is the
right place for that work.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 16:55:45 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03604
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 16:55:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJHVi-0005th-DL; Wed, 06 Apr 2005 16:52:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHVd-0005tU-7Z
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:52:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03178
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 16:52:18 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHe2-0006Xt-26
	for ipv6@ietf.org; Wed, 06 Apr 2005 17:01:03 -0400
Received: from ([128.244.96.106])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10205709;
	Wed, 06 Apr 2005 16:51:39 -0400
In-Reply-To: <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Message-Id: <f5c02220537193967a4f66b06b1c94d1@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Wed, 6 Apr 2005 16:51:38 -0400
To: Fred Baker <fred@cisco.com>
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: 789c141a303c09204b537a4078e2a63f
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0735194157=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============0735194157==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--777970894;
	protocol="application/pkcs7-signature"


--Apple-Mail-1--777970894
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

Fred,

On Apr 6, 2005, at 14:50, Fred Baker wrote:

> Define "anycast address" in this question?
>
> An IPv6 anycast address is indistinguishable from an IPv6 unicast  
> address. As such, any rule prohibiting the use of an anycast address  
> in any location is unenforceable - I have no way to identify an  
> anycast address to apply the rule.
>
> I didn't see the draft, but I was talking with Eric Nordmark about a  
> notion I have that IP Mobility would be very useful in anycast  
> services, and he told me that he had actually described it a year  
> earlier. OK,

      This is what Erik and I wrote up on anycast and IP Mobility.
http://anycast.anarg.jp/drafts/draft-haberman-ipv6-anycast-rr-00.txt

> so it's his proposal... Anycast works pretty well with DNS, and  
> presumably with similar services that do not set up long tem  
> associations. But with anything that routinely opens a TCP session,  
> the use of anycast exposes the user to a problem when routing changes  
> sufficiently to change servers. All of a sudden he's talking to  
> someone who has no idea what he's talking about. The simple solution  
> is to use Optimized Routing - connect to the AnyCast address, obtain  
> the fixed address of the server as a Care-of Address, and then talk  
> with the care-of address. You get the "nearest" server, a benefit of  
> anycast, and then get to talk with it reliably even if routing  
> changes. The big problem with this is that one has to open an IPSEC  
> association with the anycast address, which this rule precludes.
>
> I think that there is a good operational reason to allow for that  
> model, which means that one really does need to be able to use the  
> anycast address a a source just long enough to obtain the care-of  
> address. I think it would be good for the document to describe the  
> scenario and impose appropriate limits (you don't talk all day to the  
> anycast address, you only use it to find the peer and get a better  
> address for him), but it should allow for the scenario.

I agree.

Regards,
Brian

>
> On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote:
>
>> All,
>>      I am soliciting input on a proposal to modify the rules defined
>> in the current addressing architecture draft with respect to anycast.
>> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to  
>> change
>> the following text in the addressing architecture:
>>
>>       o An anycast address must not be used as the source address of  
>> an
>>          IPv6 packet.
>>
>>       o An anycast address must not be assigned to an IPv6 host, that
>>          is, it may be assigned to an IPv6 router only.
>>
>> to
>>
>>    o  An anycast address MAY be used as the source address of an IPv6
>>        packet.
>>    o  An anycast address MAY be assigned to an IPv6 host.
>>
>> This change will allow users to operate IPv6 anycast services in the  
>> same
>> manner in which they do today with IPv4 anycast.
>>
>> I would like people to chime in before April 15, 2005 with their  
>> opinion on
>> making this change.
>>
>> It should be noted that the addressing architecture is currently in  
>> IETF Last
>> Call.
>>
>> Regards,
>> Brian----------------------------------------------------------------- 
>> ---
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

--Apple-Mail-1--777970894
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA2MjA1MTM5WjAjBgkqhkiG9w0B
CQQxFgQUo9LJsK+rpmHAgWrD8IZGo+VBILYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEAEwrcCSSRy/xw0p79m2chzXcYYcl+aH2Z1/Tb5+DmP/vrzGkV2+z5wGElGx0k63Xl5B2K
P3nSRnZ+7OHNY40K+oYqv67vnY9axQrHpIqE4fQm15E/BsfEEJ1EMXfCSbwAjUX2jBKLVno4u2yS
GkF0XDPAA/EuJ5Emzo2hv8iUKi8RnG+3PVaCAMHFuHRu0RjV1BELSwMQRjLcxHwGNogbOn5PZ/bz
rX5C3oLYGgUllUDPv1sbyJ/tb97qziEctpNAFhdSiKePRiqEjWkTMUlXrdn+wj1GMrckarmaZST6
c9MqW14t8tiaa7xH8NO7/XRk7JwVwjmx3JEcf91EpXcaigAAAAAAAA==

--Apple-Mail-1--777970894--



--===============0735194157==
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
--------------------------------------------------------------------

--===============0735194157==--




From ipv6-bounces@ietf.org  Wed Apr  6 16:55:48 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03634
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 16:55:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJHY1-0006OO-OK; Wed, 06 Apr 2005 16:54:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHXx-0006KR-Mo
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:54:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03421
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 16:54:43 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHgN-0006cr-Qv
	for ipv6@ietf.org; Wed, 06 Apr 2005 17:03:28 -0400
Received: from ([128.244.96.106])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10205805;
	Wed, 06 Apr 2005 16:54:02 -0400
In-Reply-To: <53d287f38cdaf4d20dda471b03eb4e1e@isc.org>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
	<53d287f38cdaf4d20dda471b03eb4e1e@isc.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Message-Id: <17a1b293fc35b2f40fcf4d0905e59771@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Wed, 6 Apr 2005 16:54:01 -0400
To: Joe Abley <jabley@isc.org>
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: 22bbb45ef41b733eb2d03ee71ece8243
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Bob Hinden <bob.hinden@nokia.com>, Fred Baker <fred@cisco.com>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1712958725=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============1712958725==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--777828095;
	protocol="application/pkcs7-signature"


--Apple-Mail-2--777828095
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit


On Apr 6, 2005, at 15:12, Joe Abley wrote:

>
> On 6 Apr 2005, at 14:50, Fred Baker wrote:
>
>> Define "anycast address" in this question?
>
> A single unicast address bound to multiple interfaces.
>
>> An IPv6 anycast address is indistinguishable from an IPv6 unicast 
>> address. As such, any rule prohibiting the use of an anycast address 
>> in any location is unenforceable - I have no way to identify an 
>> anycast address to apply the rule.
>
> Correct. However, the v6 addressing spec prohibits the use of an 
> anycast address from being used as the source address in a datagram, 
> or being bound to an interface on a host. These two restrictions 
> effectively prohibit the use of anycast as a service distribution 
> mechanism.
>
> I would note that the rule is indeed problematic to enforce, as is 
> reflected in the various v6 services that are currently provided in 
> violation of these restrictions.

The only place where you know it is an anycast address is at the
node where it is configured.  Section 2.6 of the addressing arch says:

    Anycast addresses are allocated from the unicast address space, using
    any of the defined unicast address formats.  Thus, anycast addresses
    are syntactically indistinguishable from unicast addresses.  When a
    unicast address is assigned to more than one interface, thus turning
    it into an anycast address, the nodes to which the address is
    assigned must be explicitly configured to know that it is an anycast
    address.

>
>> I didn't see the draft, but I was talking with Eric Nordmark about a 
>> notion I have that IP Mobility would be very useful in anycast 
>> services, and he told me that he had actually described it a year 
>> earlier. OK, so it's his proposal... Anycast works pretty well with 
>> DNS, and presumably with similar services that do not set up long tem 
>> associations. But with anything that routinely opens a TCP session, 
>> the use of anycast exposes the user to a problem when routing changes 
>> sufficiently to change servers.
>
> Absolutely. Anycast is not inherently unsuitable for use in 
> distributing services over TCP, but there are certainly dangers 
> involved in doing so. These are discussed at some length in 
> draft-ietf-grow-anycast-00.
>
>> [...]
>>
>> I think that there is a good operational reason to allow for that 
>> model, which means that one really does need to be able to use the 
>> anycast address a a source just long enough to obtain the care-of 
>> address. I think it would be good for the document to describe the 
>> scenario and impose appropriate limits (you don't talk all day to the 
>> anycast address, you only use it to find the peer and get a better 
>> address for him), but it should allow for the scenario.
>
> I believe that use of anycast (as a brief locator service, so that 
> subsequent long-held TCP services can be provided using unicast 
> addresses) is in draft-ietf-grow-anycast-00. If it's not, it has been 
> suggested by others and is in my list of things to incorporate into 
> -01.
>
>
> Joe

--Apple-Mail-2--777828095
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA2MjA1NDAyWjAjBgkqhkiG9w0B
CQQxFgQUylbFIJ7fAGZ6Ca6S1v4iO3j3JVAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEApyph9KMK8vkMmsTljIk2s9AofOZTgm861SCnNi8Onet6djWHCsQstFq4JF81AsTiTmY9
RR0siFzObVPdtMJjSll+BR4oqtp2ER7Ho8Q45njpbK4s915gu7epJinzSgRlPOghFWO5vMwrLs71
MFnGDDeXlsB2mneokH+STqhswAY4FgvziU+ES4jDU81oXVEmP41Zzd+wblme5h5/R836mFmIW9si
m7GhyLKDpnS4WqYGS/3HfFl3e7+5sCI9aKd/GOLRhktEYpLHpCj4yT6xuIGlmGzMn/mXgAYfZyy8
cEw450lmgybsYam/w4IUvuTsqs4o36L/F0wWEVe/0ASB7wAAAAAAAA==

--Apple-Mail-2--777828095--



--===============1712958725==
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
--------------------------------------------------------------------

--===============1712958725==--




From ipv6-bounces@ietf.org  Wed Apr  6 16:59:45 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04046
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 16:59:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJHau-0007ge-VF; Wed, 06 Apr 2005 16:57:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHas-0007gN-IH
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:57:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03825
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 16:57:44 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHjH-0006m6-SU
	for ipv6@ietf.org; Wed, 06 Apr 2005 17:06:29 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DJHap-0005k6-C4; Wed, 06 Apr 2005 20:57:43 +0000
In-Reply-To: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
References: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <d40b46a2abd813f32dc7beb69ff2a075@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Wed, 6 Apr 2005 16:57:10 -0400
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 6 Apr 2005, at 16:09, Manfredi, Albert E wrote:

> Any reason why the same rules that apply to multicast addresses 
> wouldn't also work here?

Actually, yes.

Anycast is being used to deploy services which, to clients, appear 
identical to normal unicast services. The protocols used are varied, 
and widely deployed (e.g. DNS, HTTP).

Clients source datagrams with a destination address set to the service 
address, which in the cases we are discussing are deployed as anycast 
addresses (i.e. they are present on more than one interface, usually on 
different hosts). The clients have no way of knowing in advance whether 
the destination addresses they are using are deployed on just one 
interface (in which case we are talking about unicast) or more than one 
(anycast).

> The destination address is anycast, to find the service. But the 
> source address in the reply is the unicast address of the first server 
> to respond, which presumably is the closest one at the time.

That might be a reasonable way to design a new protocol to be deployed 
using anycast (although I think the security implications might bear 
close scrutiny), but it's not a reasonable way to distribute services 
which use existing protocols.

To use DNS as an example, a DNS resolver sends a request to a 
nameserver using a particular destination address, and expects the 
reply to be sourced from the same address. If the reply was sourced 
from a different address, the client (resolver) would not accept it as 
an answer to the original request.


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 17:41:38 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03603
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 16:55:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJHVj-0005tp-Fc; Wed, 06 Apr 2005 16:52:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHVg-0005tc-NE
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:52:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03189
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 16:52:22 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHe5-0006Xu-QU
	for ipv6@ietf.org; Wed, 06 Apr 2005 17:01:07 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 06 Apr 2005 13:52:14 -0700
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j36KqBgT022839;
	Wed, 6 Apr 2005 13:52:11 -0700 (PDT)
In-Reply-To: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
References: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <38eddbd55b0134c3497b8e4c09b41e2a@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Wed, 6 Apr 2005 13:52:09 -0700
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

doesn't work. When TCP sends a SYN to the anycast address, it can only 
identify the SYN-ACK by having the source address of the SYN-ACK be the 
anycast address.

The mobility model that Joe and I discussed requires a security 
association to be set up with the anycast address (IPSEC management 
protocols reply with the anycast address as a source), supply a COA, 
and then TCP is set up to the COA.

But we still have to get a message from the anycast server that somehow 
says "I am a valid responder to that anycast address, but use this 
other address instead during this session."


On Apr 6, 2005, at 1:09 PM, Manfredi, Albert E wrote:

> From: Joe Abley [mailto:jabley@isc.org]
>
>> Correct. However, the v6 addressing spec prohibits the use of an
>> anycast address from being used as the source address in a
>> datagram, or
>> being bound to an interface on a host. These two restrictions
>> effectively prohibit the use of anycast as a service distribution
>> mechanism.
>
> Any reason why the same rules that apply to multicast addresses 
> wouldn't also work here?
>
> The destination address is anycast, to find the service. But the 
> source address in the reply is the unicast address of the first server 
> to respond, which presumably is the closest one at the time.
>
> This may circumvent the authentication issues, by making any 
> subsequent TCP session start as a regular unicast?
>
> Bert
>
> --------------------------------------------------------------------
> 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 Apr  6 18:18:51 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11724
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 18:18:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJIhb-0005IB-0z; Wed, 06 Apr 2005 18:08:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIhY-0005I5-Oj
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 18:08:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10370
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 18:08:41 -0400 (EDT)
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 1DJIpy-0000AE-6e
	for ipv6@ietf.org; Wed, 06 Apr 2005 18:17:27 -0400
Message-ID: <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Joe Abley" <jabley@isc.org>, "Fred Baker" <fred@cisco.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net><8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
	<53d287f38cdaf4d20dda471b03eb4e1e@isc.org>
Date: Wed, 6 Apr 2005 15:09:40 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>,
        Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

> > An IPv6 anycast address is indistinguishable from an IPv6 unicast 
> > address. As such, any rule prohibiting the use of an anycast address 
> > in any location is unenforceable - I have no way to identify an 
> > anycast address to apply the rule.
> 
> Correct. However, the v6 addressing spec prohibits the use of an 
> anycast address from being used as the source address in a datagram, or 
> being bound to an interface on a host. These two restrictions 
> effectively prohibit the use of anycast as a service distribution 
> mechanism.
> 

Why was this prohibition was put into the specification? 

            jak


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 19:52:46 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23306
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 19:52:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJKIP-0001DH-Ho; Wed, 06 Apr 2005 19:50:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKIM-0001Ay-Vb
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 19:50:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23180
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 19:50:47 -0400 (EDT)
Received: from farside.isc.org ([204.152.187.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKQn-0002cQ-GZ
	for ipv6@ietf.org; Wed, 06 Apr 2005 19:59:34 -0400
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 74D12677EF
	for <ipv6@ietf.org>; Wed,  6 Apr 2005 23:49:30 +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 j36NoGVH034068;
	Thu, 7 Apr 2005 09:50:18 +1000 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200504062350.j36NoGVH034068@drugs.dv.isc.org>
To: "James Kempf" <kempf@docomolabs-usa.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Wed, 06 Apr 2005 15:09:40 MST."
	<06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> 
Date: Thu, 07 Apr 2005 09:50:16 +1000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: Brian Haberman <brian@innovationslab.net>,
        Bob Hinden <bob.hinden@nokia.com>, Fred Baker <fred@cisco.com>,
        Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


> > > An IPv6 anycast address is indistinguishable from an IPv6 unicast 
> > > address. As such, any rule prohibiting the use of an anycast address 
> > > in any location is unenforceable - I have no way to identify an 
> > > anycast address to apply the rule.
> > 
> > Correct. However, the v6 addressing spec prohibits the use of an 
> > anycast address from being used as the source address in a datagram, or 
> > being bound to an interface on a host. These two restrictions 
> > effectively prohibit the use of anycast as a service distribution 
> > mechanism.
> > 
> 
> Why was this prohibition was put into the specification? 
> 
>             jak

	The prohibition was put in as we didn't know how to do anycast
	correctly for all cases.  How to do the route injection etc.

	For single packet transactions (one packet each way) as long as
	you don't source the first packet from a anycast address there
	is no problems with sending the reply from the anycast address.
	DNS/UDP falls into this space.

	For sessions bigger than this there are going to be issues that
	need to be examined and maybe addressed.

	e.g.
	* per pack load balancing which causes traffic to go to different
	anycast nodes.
	* routing table changes which change the anycast node.
 
	DNS/TCP w/ anycast assumes the first of these to be almost
	non-exisitant and the second to be a non-issue as the
	sessions have short life times.  Again this is with the
	server on the anycast address and the client on the unicast
	address.

	Note the important thing here is that the session (not
	packet) originated from a unicast address.  Replying with
	unicast source address is reasonable in some/all cirumstances.

	I suspect that the one of the bigger issues will be PPLB
	which may require routing protocols to be able to tag
	prefixes as containing anycast addresses to turn off
	non-parrallel path PPLB. This tag may or may not need to
	be exported across AS boundaries.

	Mark

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 20:14:48 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24855
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 20:14:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJKbl-0007xE-MV; Wed, 06 Apr 2005 20:10:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKbj-0007wk-IB
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 20:10:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24374
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 20:10:46 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKkA-00030r-88
	for ipv6@ietf.org; Wed, 06 Apr 2005 20:19:34 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-4.cisco.com with ESMTP; 06 Apr 2005 17:10:41 -0700
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id j370AZ3T021981;
	Wed, 6 Apr 2005 17:10:36 -0700 (PDT)
In-Reply-To: <200504062350.j36NoGVH034068@drugs.dv.isc.org>
References: <200504062350.j36NoGVH034068@drugs.dv.isc.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b11c1f1920d331e9e8e4c4a73e8cc8c9@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Wed, 6 Apr 2005 17:10:34 -0700
To: Mark Andrews <Mark_Andrews@isc.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: Brian Haberman <brian@innovationslab.net>,
        James Kempf <kempf@docomolabs-usa.com>,
        Bob Hinden <bob.hinden@nokia.com>,
        Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

To be honest, I can't imagine a routing protocol that does anything 
similar to prefix aggregation carrying tags around for individual /32 
or /128 addresses. And while it is conceptually possible to do 
per-packet load balancing, very few routers are actually configured 
that way, because the end station guys complain about the extra packet 
copy load it introduces in TCP. Generally speaking, the source and 
destination addresses in a packet are hashed, the hash reduced using a 
modulus or similar function, and the result used as an index into the 
next hop list in the multipath route. This is done explicitly to limit 
the TCP packet copy issues by reducing the amount of reordering that 
happens in the network. It's legal, but "legal" doesn't make it a good 
thing.

The real issue is temporal. "What is the probability that routing could 
change during the time this address is in use".

Note that none of this about packets going from the anycast server to 
the session originator, which would be the concern that would lead one 
to look hard at packets that had an anycast address as a source. It has 
to do with packets going from the session originator to two different 
nodes offering the anycast service - routing to the anycast address, 
routing changing, choice of server by the network...

What you're cautioning against is the use of an anycast service by an 
originator, not the use of an anycast address as a source.

Do you have any concerns that relate to using an anycast address as the 
*source*?


On Apr 6, 2005, at 4:50 PM, Mark Andrews wrote:

> 	The prohibition was put in as we didn't know how to do anycast
> 	correctly for all cases.  How to do the route injection etc.
>
> 	For single packet transactions (one packet each way) as long as
> 	you don't source the first packet from a anycast address there
> 	is no problems with sending the reply from the anycast address.
> 	DNS/UDP falls into this space.
>
> 	For sessions bigger than this there are going to be issues that
> 	need to be examined and maybe addressed.
>
> 	e.g.
> 	* per pack load balancing which causes traffic to go to different
> 	anycast nodes.
> 	* routing table changes which change the anycast node.
>
> 	DNS/TCP w/ anycast assumes the first of these to be almost
> 	non-exisitant and the second to be a non-issue as the
> 	sessions have short life times.  Again this is with the
> 	server on the anycast address and the client on the unicast
> 	address.
>
> 	Note the important thing here is that the session (not
> 	packet) originated from a unicast address.  Replying with
> 	unicast source address is reasonable in some/all cirumstances.
>
> 	I suspect that the one of the bigger issues will be PPLB
> 	which may require routing protocols to be able to tag
> 	prefixes as containing anycast addresses to turn off
> 	non-parrallel path PPLB. This tag may or may not need to
> 	be exported across AS boundaries.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 21:38:19 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01808
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 21:38:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJLx2-00060C-0Z; Wed, 06 Apr 2005 21:36:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJLwz-0005qN-8i
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 21:36:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01644
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 21:36:51 -0400 (EDT)
Received: from farside.isc.org ([204.152.187.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJM5R-0004t7-RC
	for ipv6@ietf.org; Wed, 06 Apr 2005 21:45:38 -0400
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 DD7EF677EF
	for <ipv6@ietf.org>; Thu,  7 Apr 2005 01:35:41 +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 j371aSjI034478;
	Thu, 7 Apr 2005 11:36:28 +1000 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200504070136.j371aSjI034478@drugs.dv.isc.org>
To: Fred Baker <fred@cisco.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Wed, 06 Apr 2005 17:10:34 MST."
	<b11c1f1920d331e9e8e4c4a73e8cc8c9@cisco.com> 
Date: Thu, 07 Apr 2005 11:36:28 +1000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: Brian Haberman <brian@innovationslab.net>,
        James Kempf <kempf@docomolabs-usa.com>, IPv6 WG <ipv6@ietf.org>,
        Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>, Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


> To be honest, I can't imagine a routing protocol that does anything 
> similar to prefix aggregation carrying tags around for individual /32 
> or /128 addresses.

	It wouldn't have to be for a /32.  Take the root servers for
	example.  Tagging the /24 they each live in would be sufficient.
	Similarly for IPv6.

> And while it is conceptually possible to do 
> per-packet load balancing, very few routers are actually configured 
> that way, because the end station guys complain about the extra packet 
> copy load it introduces in TCP.  Generally speaking, the source and 
> destination addresses in a packet are hashed, the hash reduced using a 
> modulus or similar function, and the result used as an index into the 
> next hop list in the multipath route. This is done explicitly to limit 
> the TCP packet copy issues by reducing the amount of reordering that 
> happens in the network. It's legal, but "legal" doesn't make it a good 
> thing.

	We've pointed this out everytime someone complains about F being
	anycast.  The problem is that they still argue that this is a
	issue.  It would be nice to have a come back other that "no one
	does this in practice except to demonstrate that it can be done."
 
> The real issue is temporal. "What is the probability that routing could 
> change during the time this address is in use".
> 
> Note that none of this about packets going from the anycast server to 
> the session originator, which would be the concern that would lead one 
> to look hard at packets that had an anycast address as a source. It has 
> to do with packets going from the session originator to two different 
> nodes offering the anycast service - routing to the anycast address, 
> routing changing, choice of server by the network...
> 
> What you're cautioning against is the use of an anycast service by an 
> originator, not the use of an anycast address as a source.

	Yes.

> Do you have any concerns that relate to using an anycast address as the 
> *source*?

	The classic session problem is when you have a DNS server
	cluster (behind a single router) and it is a slave and the
	masters are only configured to accept transfer requests
	from the anycast address.  Lets say that it gets interesting
	to say the least especially when the router adds the transport
	and / or ports into the mix.

	The UDP refresh query will only work for one instance.  The
	AXFR (over TCP) may only work for another instance (depends
	upon how the router identifies a flow).	The the NOTIFY message
	goes to a instance for which the refresh and/AXFR fails.

	Wide area anycast makes this even more interesting.

	No, I am not talking about F here.  F uses a unicast address
	and TSIG for zone transfers / refresh queries.

	Getting back to unicast initiated sessions I would still
	like to see some mechanism (as low in the stack as possible)
	which would allow long running session to survive routing
	changes.  But if we can't just removing the restrictions
	and documenting the problems would be sufficient.  Lots of
	protocols can cope or can be made to cope as long as short
	term sessions work.

	e.g.
	* HTTP can redirect.
	* DNS could return a unicast address as a EDNS option to queries
	  to the anycast address.
	
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 22:42:19 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05413
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 22:42:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJMxP-0006GU-9H; Wed, 06 Apr 2005 22:41:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJMxO-0006FN-4x
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 22:41:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05356
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 22:41:19 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJN5q-00064C-H6
	for ipv6@ietf.org; Wed, 06 Apr 2005 22:50:07 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-4.cisco.com with ESMTP; 06 Apr 2005 19:41:17 -0700
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id j372fD3T017584;
	Wed, 6 Apr 2005 19:41:14 -0700 (PDT)
In-Reply-To: <200504070136.j371aSjI034478@drugs.dv.isc.org>
References: <200504070136.j371aSjI034478@drugs.dv.isc.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1adbfc1e7867fa3edd169745ac02d795@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Wed, 6 Apr 2005 19:37:34 -0700
To: Mark Andrews <Mark_Andrews@isc.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: Brian Haberman <brian@innovationslab.net>,
        James Kempf <kempf@docomolabs-usa.com>, IPv6 WG <ipv6@ietf.org>,
        Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>, Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:

> 	Getting back to unicast initiated sessions I would still
> 	like to see some mechanism (as low in the stack as possible)
> 	which would allow long running session to survive routing
> 	changes.

You're speaking in this thread. Did you take a look at the proposal 
that Eric Nordmark, I, and the grow folks have discussed about a 
care-of-address that would give a long term fixed address to the server 
in question? Answering that question is where we started out.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr  6 23:22:29 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08112
	for <ipngwg-archive@lists.ietf.org>; Wed, 6 Apr 2005 23:22:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJNZ6-0008QH-Hb; Wed, 06 Apr 2005 23:20:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNZ4-0008Q7-91
	for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 23:20:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07790
	for <ipv6@ietf.org>; Wed, 6 Apr 2005 23:20:15 -0400 (EDT)
Received: from farside.isc.org ([204.152.187.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJNhW-0006pS-VG
	for ipv6@ietf.org; Wed, 06 Apr 2005 23:29:04 -0400
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 21F15677EF
	for <ipv6@ietf.org>; Thu,  7 Apr 2005 03:19:06 +0000 (UTC)
	(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j373JpbA039869;
	Thu, 7 Apr 2005 13:19:51 +1000 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200504070319.j373JpbA039869@drugs.dv.isc.org>
To: Fred Baker <fred@cisco.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Wed, 06 Apr 2005 19:37:34 MST."
	<1adbfc1e7867fa3edd169745ac02d795@cisco.com> 
Date: Thu, 07 Apr 2005 13:19:51 +1000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Brian Haberman <brian@innovationslab.net>,
        James Kempf <kempf@docomolabs-usa.com>,
        Bob Hinden <bob.hinden@nokia.com>,
        Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


> 
> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:
> 
> > 	Getting back to unicast initiated sessions I would still
> > 	like to see some mechanism (as low in the stack as possible)
> > 	which would allow long running session to survive routing
> > 	changes.
> 
> You're speaking in this thread. Did you take a look at the proposal 
> that Eric Nordmark, I, and the grow folks have discussed about a 
> care-of-address that would give a long term fixed address to the server 
> in question? Answering that question is where we started out.

	care-of-address would be overkill for somethings and
	quite a reasonable solution for others.  If it could be
	made selectable on a per/socket basis (I havn't looked
	at how implemetation do this at present) I suspect this
	will meet most of what would be required.

	In other words we would not want to do this for DNS/UDP but
	for DNS/TCP it would be acceptable even though it would only
	be really required for long running AXFR's (multi-megabyte).
 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 00:49:05 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18854
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 00:49:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJOss-0000jd-0x; Thu, 07 Apr 2005 00:44:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOso-0000iv-EZ
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 00:44:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18356
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 00:44:42 -0400 (EDT)
Received: from farside.isc.org ([204.152.187.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJOyu-0000q6-K6
	for ipv6@ietf.org; Thu, 07 Apr 2005 00:51:05 -0400
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 174D9677EF
	for <ipv6@ietf.org>; Thu,  7 Apr 2005 04:41:12 +0000 (UTC)
	(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j374fsto047183;
	Thu, 7 Apr 2005 14:41:54 +1000 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200504070441.j374fsto047183@drugs.dv.isc.org>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Thu, 07 Apr 2005 13:19:51 +1000."
Date: Thu, 07 Apr 2005 14:41:54 +1000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: Brian Haberman <brian@innovationslab.net>,
        James Kempf <kempf@docomolabs-usa.com>,
        Bob Hinden <bob.hinden@nokia.com>, Fred Baker <fred@cisco.com>,
        Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org



	One of my collegues pointed out I wasn't clear enough.

	The restictions on using a anycast address as a packet
	source definitely need to be relaxed.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 00:51:54 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19061
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 00:51:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJOt0-0000lp-Fw; Thu, 07 Apr 2005 00:44:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOsz-0000lG-2A
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 00:44:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18473
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 00:44:52 -0400 (EDT)
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 1DJOqL-0000Yd-K8
	for ipv6@ietf.org; Thu, 07 Apr 2005 00:42:14 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-2.cisco.com with ESMTP; 06 Apr 2005 21:33:18 -0700
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j374XEgT011005;
	Wed, 6 Apr 2005 21:33:15 -0700 (PDT)
In-Reply-To: <200504070319.j373JpbA039869@drugs.dv.isc.org>
References: <200504070319.j373JpbA039869@drugs.dv.isc.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <ccc7da5e892173700aaccada82768183@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Wed, 6 Apr 2005 21:33:12 -0700
To: Mark Andrews <Mark_Andrews@isc.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit
Cc: Brian Haberman <brian@innovationslab.net>,
        James Kempf <kempf@docomolabs-usa.com>, IPv6 WG <ipv6@ietf.org>,
        Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>, Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

OK, so then lets go back to the question posed in the thread. The 
current spec says that one should never use an anycast address as a 
source address under any circumstances. That clearly flies in the face 
of present practice, isn't responsiv to the set of concerns you raised 
about anycast in general, and can be mitigated if anycast is use for 
rendesvous. The suggestion was made that under a defined set of 
circumstances (single message each way exchange, rendezvous, perhaps 
some others) and with a defined set of procedures it would be OK to use 
it as a source address. Those procedures need to spell out the whys and 
wherefores.

Would you be willing to see the 100% ban removed from the draft 
standard and substitute text to the effect of that above included, with 
follow-up work in grow-or-wherever to spell out those procedures?



On Apr 6, 2005, at 8:19 PM, Mark Andrews wrote:

>
>>
>> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:
>>
>>> 	Getting back to unicast initiated sessions I would still
>>> 	like to see some mechanism (as low in the stack as possible)
>>> 	which would allow long running session to survive routing
>>> 	changes.
>>
>> You're speaking in this thread. Did you take a look at the proposal
>> that Eric Nordmark, I, and the grow folks have discussed about a
>> care-of-address that would give a long term fixed address to the 
>> server
>> in question? Answering that question is where we started out.
>
> 	care-of-address would be overkill for somethings and
> 	quite a reasonable solution for others.  If it could be
> 	made selectable on a per/socket basis (I havn't looked
> 	at how implemetation do this at present) I suspect this
> 	will meet most of what would be required.
>
> 	In other words we would not want to do this for DNS/UDP but
> 	for DNS/TCP it would be acceptable even though it would only
> 	be really required for long running AXFR's (multi-megabyte).
>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 00:53:34 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19263
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 00:53:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJOyM-0001Lh-Bq; Thu, 07 Apr 2005 00:50:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOyF-0001LE-Ba
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 00:50:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18962
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 00:50:20 -0400 (EDT)
Received: from farside.isc.org ([204.152.187.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJP6j-0001C7-PQ
	for ipv6@ietf.org; Thu, 07 Apr 2005 00:59:10 -0400
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 91C4B677EF
	for <ipv6@ietf.org>; Thu,  7 Apr 2005 04:49:19 +0000 (UTC)
	(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j374o5Qp047242;
	Thu, 7 Apr 2005 14:50:05 +1000 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200504070450.j374o5Qp047242@drugs.dv.isc.org>
To: Fred Baker <fred@cisco.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Wed, 06 Apr 2005 21:33:12 MST."
	<ccc7da5e892173700aaccada82768183@cisco.com> 
Date: Thu, 07 Apr 2005 14:50:05 +1000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: Brian Haberman <brian@innovationslab.net>,
        James Kempf <kempf@docomolabs-usa.com>, IPv6 WG <ipv6@ietf.org>,
        Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>, Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


> OK, so then lets go back to the question posed in the thread. The 
> current spec says that one should never use an anycast address as a 
> source address under any circumstances. That clearly flies in the face 
> of present practice, isn't responsiv to the set of concerns you raised 
> about anycast in general, and can be mitigated if anycast is use for 
> rendesvous. The suggestion was made that under a defined set of 
> circumstances (single message each way exchange, rendezvous, perhaps 
> some others) and with a defined set of procedures it would be OK to use 
> it as a source address. Those procedures need to spell out the whys and 
> wherefores.
> 
> Would you be willing to see the 100% ban removed from the draft 
> standard and substitute text to the effect of that above included, with 
> follow-up work in grow-or-wherever to spell out those procedures?

	Definitely yes.
 
> On Apr 6, 2005, at 8:19 PM, Mark Andrews wrote:
> 
> >
> >>
> >> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:
> >>
> >>> 	Getting back to unicast initiated sessions I would still
> >>> 	like to see some mechanism (as low in the stack as possible)
> >>> 	which would allow long running session to survive routing
> >>> 	changes.
> >>
> >> You're speaking in this thread. Did you take a look at the proposal
> >> that Eric Nordmark, I, and the grow folks have discussed about a
> >> care-of-address that would give a long term fixed address to the 
> >> server
> >> in question? Answering that question is where we started out.
> >
> > 	care-of-address would be overkill for somethings and
> > 	quite a reasonable solution for others.  If it could be
> > 	made selectable on a per/socket basis (I havn't looked
> > 	at how implemetation do this at present) I suspect this
> > 	will meet most of what would be required.
> >
> > 	In other words we would not want to do this for DNS/UDP but
> > 	for DNS/TCP it would be acceptable even though it would only
> > 	be really required for long running AXFR's (multi-megabyte).
> >
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
> >
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 02:06:01 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29957
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 02:06:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJQ6s-0004dA-9O; Thu, 07 Apr 2005 02:03:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQ6k-0004Vf-J8
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 02:03:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27094
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 02:03:13 -0400 (EDT)
From: john.loughney@nokia.com
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQFF-0003UE-90
	for ipv6@ietf.org; Thu, 07 Apr 2005 02:12:01 -0400
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
	j3763Bu21098; Thu, 7 Apr 2005 09:03:11 +0300 (EET DST)
X-Scanned: Thu, 7 Apr 2005 09:02:12 +0300 Nokia Message Protector V1.3.34
	2004121512 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j3762C1J002074;
	Thu, 7 Apr 2005 09:02:12 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks003.ntc.nokia.com 00tbvd2v; Thu, 07 Apr 2005 09:02:10 EEST
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
	j3762AU13590; Thu, 7 Apr 2005 09:02:10 +0300 (EET DST)
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 7 Apr 2005 09:01:57 +0300
Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by
	esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 7 Apr 2005 09:01:57 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 7 Apr 2005 09:01:54 +0300
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: Thu, 7 Apr 2005 09:01:56 +0300
Message-ID: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
Thread-Topic: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
thread-index: AcU6ziXUpL5a7DHqQziQrquM1tojcwAZsd8g
To: <brian@innovationslab.net>, <ipv6@ietf.org>
X-OriginalArrivalTime: 07 Apr 2005 06:01:54.0627 (UTC)
	FILETIME=[4CB7A130:01C53B37]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
Cc: margaret@thingmagic.com, Bob.Hinden@nokia.com
Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Brian,
>       I am soliciting input on a proposal to modify the rules defined
> in the current addressing architecture draft with respect to anycast.
> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to =
change
> the following text in the addressing architecture:
>=20
>        o An anycast address must not be used as the source address of =
an
>           IPv6 packet.
>=20
>        o An anycast address must not be assigned to an IPv6 host, that
>           is, it may be assigned to an IPv6 router only.
>=20
> to
>=20
>     o  An anycast address MAY be used as the source address of an IPv6
>         packet.
>     o  An anycast address MAY be assigned to an IPv6 host.
>=20
> This change will allow users to operate IPv6 anycast services in the =
same
> manner in which they do today with IPv4 anycast.
>=20
> I would like people to chime in before April 15, 2005 with their =
opinion on
> making this change.

I support this change. Based on the discussions, I think that there =
seems to
be well thought-out uses for using an anycast address as a source =
address,
and similar uses of anycast in IPv4. =20

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 02:56:44 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19670
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 02:56:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJQr9-0001X8-T2; Thu, 07 Apr 2005 02:51:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQr6-0001WC-OS
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 02:51:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19306
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 02:51:07 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DJQzb-00055c-6m
	for ipv6@ietf.org; Thu, 07 Apr 2005 02:59:56 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-1.cisco.com with ESMTP; 06 Apr 2005 23:50:58 -0700
X-IronPort-AV: i="3.92,82,1112598000"; 
	d="scan'208"; a="626471344:sNHT35714604"
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j376osgT021410;
	Wed, 6 Apr 2005 23:50:54 -0700 (PDT)
In-Reply-To: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
References: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Wed, 6 Apr 2005 23:50:52 -0700
To: Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <Bob.Hinden@nokia.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

proposed text...

Replace

       o An anycast address must not be used as the source address of an
         IPv6 packet.

       o An anycast address must not be assigned to an IPv6 host, that
         is, it may be assigned to an IPv6 router only.

with

  - An anycast address is used for very short exchanges, such as single 
packet each way (DNS) or rendezvous exchanges (IPsec/IKE/ISAKMP). Use 
of Anycast as a source address in longer exchanges runs the risk of 
routing changing in the network and the stated shared by the 
communicating end stations being lost. For longer exchanges with an 
anycast service, a protocol must be defined that communicates to the 
originator of the session a stable address of the system it is 
communicating with, to be used for the substance of the exchange.

  - An anycast address is never advertised to the network by a host in 
neighbor discovery, but rather by a router or host advertising itself 
as a reasonable router to that end station. If routing fails, fail-over 
to another interface serving the address is this automatic.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 02:57:55 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19916
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 02:57:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJQuk-0001vD-NG; Thu, 07 Apr 2005 02:54:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJQnZ-0001Ol-75; Thu, 07 Apr 2005 02:47:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18889;
	Thu, 7 Apr 2005 02:47:27 -0400 (EDT)
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DJQw3-0004zC-5f; Thu, 07 Apr 2005 02:56:16 -0400
Received: from esealmw129.eemea.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	j376kHUO028336; Thu, 7 Apr 2005 08:47:25 +0200
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 7 Apr 2005 08:46:52 +0200
Received: from unixmail.ted.dk.eu.ericsson.se ([213.159.188.246]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 7 Apr 2005 08:46:52 +0200
Received: from nellike.ted.dk.eu.ericsson.se (tedpcn@nellike.ted.ericsson.se
	[213.159.189.18])
	by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with
	ESMTP id j376kqL20989; Thu, 7 Apr 2005 08:46:52 +0200 (MEST)
Date: Thu, 7 Apr 2005 08:46:52 +0200 (CEST)
From: "Peder Chr. Norgaard" <Peder.Chr.Norgaard@ericsson.com>
X-X-Sender: tedpcn@nellike.ted.dk.eu.ericsson.se
To: iesg@ietf.org
In-Reply-To: <E1DJC65-00079W-LC@newodin.ietf.org>
Message-ID: <Pine.LNX.4.58.0504070843480.17138@nellike.ted.dk.eu.ericsson.se>
References: <E1DJC65-00079W-LC@newodin.ietf.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by
	unixmail.ted.dk.eu.ericsson.se id j376kqL20989
X-OriginalArrivalTime: 07 Apr 2005 06:46:52.0823 (UTC)
	FILETIME=[94F7AA70:01C53B3D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 07 Apr 2005 02:54:53 -0400
Cc: ipv6@ietf.org
Subject: Re: Last Call: 'IP Version 6 Addressing Architecture' to Draft
 Standard
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

On Wed, 6 Apr 2005, The IESG wrote:

>
> The IESG has received a request from the IP Version 6 Working Group WG =
to
> consider the following document:
>
> - 'IP Version 6 Addressing Architecture'
>    <draft-ietf-ipv6-addr-arch-v4-02.txt> as a Draft Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-20.
>

Spotted a slightly confusing typo in Appendix B:

    o Deprecated the "IPv6 Compatible Address" because it is not being
                      ^^^^
should be

    o Deprecated the "IPv4 Compatible Address" because it is not being
                      ^^^^

best regards
--
Peder Chr. N=F8rgaard        	 Senior System Developer, M. Sc.
Ericsson Telebit A/S       	 tel: +45 30 91 84 31
Skanderborgvej 232         	 fax: +45 89 38 51 01
DK-8260 Viby J, Denmark
        e-mail: Peder.Chr.Norgaard@ericsson.com
(old e-mail 2000-2003: Peder.C.Norgaard@ted.ericsson.se)
         (old e-mail 1992-2000: pcn@tbit.dk)

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 03:00:53 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20230
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 03:00:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJQyZ-0003FR-7B; Thu, 07 Apr 2005 02:58:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQyV-0003FL-85
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 02:58:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20000
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 02:58:45 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJR6z-0005Mp-8c
	for ipv6@ietf.org; Thu, 07 Apr 2005 03:07:34 -0400
Received: from ocean.jinmei.org (PPP416.air-4x8x.dti.ne.jp [210.170.213.202])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 60F861525D; Thu,  7 Apr 2005 16:00:00 +0900 (JST)
Date: Thu, 07 Apr 2005 15:59:03 +0900
Message-ID: <y7v8y3voyx4.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: "Steve Cipolli" <SCipolli@radvision.com>
In-Reply-To: <BBC4EAA361F44F45AB1EC1915D0CF5244D4CE2@rvnj-mail.radvision.com>
References: <BBC4EAA361F44F45AB1EC1915D0CF5244D4CE2@rvnj-mail.radvision.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
	(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: ipv6@ietf.org
Subject: Re: Ordering of % and / in  RFC 4007
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

>>>>> On Wed, 6 Apr 2005 10:09:22 -0400, 
>>>>> "Steve Cipolli" <SCipolli@radvision.com> said:

> Can someone explain the rational for why RFC 4007 mandates the scope
> zone index before the prefix in the textual representation?  

(snip)

> Section 11.7 says its important to put the scope zone index first for
> parsing by name-to-address functions and references a document that I
> was unable to find.  I understand the "name-to-address functions" to
> mean getaddrinfo.  However I'm not clear why getaddrinfo should care
> that scope zone index appeared first assuming the substring "ip6 ['/'
> prefix]" were handled by a function similar in6_addr_pton above.

The intended function is getaddrinfo, yes.  And the expected usage in
this case is as follows:

(assume variable "prefix" points to a string like "fe80::%5/64")

	char *addr, *p;
	int plen;

	p = strchr(prefix, '/');
	*p++ = '\0';
	getaddrinfo(p, NULL, hints, res);
	plen = atoi(p);

(Note: error handling or proper handling of constant variables are
ignored for simplicity)

Then
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr = fe80::
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id = 5
  plen = 64

If we represented the scoped prefix as, e.g., "fe80::/64%5", the above
code couldn't be that straightforward.

					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 Apr  7 03:25:03 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22087
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 03:25:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJRMQ-00034H-Cx; Thu, 07 Apr 2005 03:23:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRMJ-00031w-Md
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 03:23:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21877
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 03:23:21 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRUp-0006AN-Dt
	for ipv6@ietf.org; Thu, 07 Apr 2005 03:32:11 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net
	[IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net",
	Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id 104B5641;
	Thu,  7 Apr 2005 03:23:12 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id 682DD41EA;
	Thu,  7 Apr 2005 03:23:11 -0400 (EDT)
Date: Thu, 07 Apr 2005 03:23:11 -0400
From: Rob Austein <sra@isc.org>
To: Fred Baker <fred@cisco.com>
In-Reply-To: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
References: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
	<7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050407072311.682DD41EA@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote:
> 
> proposed text...

While I appreciate the effort that Fred put into crafting text, I'd
prefer Brian's original proposal.  The only parts of this set of
anycast issues that's specific to IPv6 are the restrictions that the
IPv6 address architecture doc imposes on use of anycast in IPv6.  The
rest of the issues are IP-version-independent, and are already under
consideration in another WG which has the relevant routing expertise.
So I think the best thing for the IPv6 WG per se to do would be to
clear up the old IPv6-specific restrictions, then bow out gracefully.

If folks from the IPv6 WG want to wander over to GROW and chat about
the issues Fred's proposed text attempts to document, that sounds like
a fine and useful thing, and I'm sure that the folks over in GROW
would be happy to get additional eyes reviewing their work, but to me
that looks like a separate activity in a separate WG and does not need
to be tightly coupled to the IPv6 address architecture doc.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From pewters@yebox.com  Thu Apr  7 07:17: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 HAA09116;
	Thu, 7 Apr 2005 07:17:16 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DJV9E-0005Xg-Bq; Thu, 07 Apr 2005 07:26:09 -0400
Received: from p1049-ipbf11akatuka.ibaraki.ocn.ne.jp ([222.144.47.49])
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1DJV0W-0003eG-Qj; Thu, 07 Apr 2005 07:17:11 -0400
X-Apparently-To: ipngwg-archive@ietf.org
X-Sieve: CMU Sieve 2.2
Received: from kombu.because.pochta.ru ([unix socket])
         by inventory.approximate.pochta.ru (Cyrus v2.2.4) with LMTPA;
         Thu, 07 Apr 2005 09:13:03 -0300
Date: Thu, 07 Apr 2005 09:07:03 -0300
From: "Ward Maloney" <pewters@yebox.com>
Message-Id: <CFE9.AA79.9A51-003063598B8C@mac.com>
X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org, ipr@ietf.org
Subject: Your account #4M7624
X-Mailer: Forte Agent 1.91/32.564
X-Spam-Score: 5.3 (+++++)
X-Spam-Flag: YES
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.3-m-n.net/sign.asp



 Best Regards,

 Carly Meredith
 
 to be remov(ed:	http://www.3-m-n.net/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From zembower@yebox.com  Thu Apr  7 11:11: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 LAA02966;
	Thu, 7 Apr 2005 11:11:37 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DJYo2-0006XA-7F; Thu, 07 Apr 2005 11:20:31 -0400
Received: from [211.226.226.108] (helo=65.246.255.50)
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1DJYfL-0001IG-5n; Thu, 07 Apr 2005 11:11:33 -0400
Delivered-To: occipital@replicate.dreamhost.com
Received: from leathery.dreamhost.com by near.dreamhost.com (Pingofix) with ESMTP id 5CC7A59D5B
        for <lista-ipngwg-archive@ietf.org>;
        Thu, 07 Apr 2005 17:04:02 +0100
Message-ID: <BKELLDAGKABIOCHDFD910DGAA.dannipngwg-archive@ietf.org>
Date: Thu, 07 Apr 2005 12:00:02 -0400
From: "Davis Honeycutt" <zembower@yebox.com>
To: <ipngwg-archive@ietf.org>
Subject: Approved mortage rate
X-Mailer: Mailman v2.0.4
X-SpamTest-Info: Profile: Formal (167/041179)
X-SpamTest-Info: Profile: Detect Hard No RBL (4/030524)
X-Spam-Score: 6.7 (++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.3-m-n.net/sign.asp



 Best Regards,

 Tyree Luna
 
 to be remov(ed:	http://www.3-m-n.net/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Thu Apr  7 11:17:44 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03780
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 11:17:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJYh1-0003Cc-GO; Thu, 07 Apr 2005 11:13:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJYgz-0003BX-Lt
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 11:13:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03181
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 11:13:10 -0400 (EDT)
Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYpY-0006cQ-Gs
	for ipv6@ietf.org; Thu, 07 Apr 2005 11:22:05 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Thu, 7 Apr 2005 11:13:00 -0400
Message-ID: <BBC4EAA361F44F45AB1EC1915D0CF5244D4CE9@rvnj-mail.radvision.com>
Thread-Topic: Ordering of % and / in  RFC 4007
Thread-Index: AcU7P0A5vG2Q1abcTUqHYGHcw8BywQAQiKiQ
From: "Steve Cipolli" <SCipolli@radvision.com>
To: "JINMEI Tatuya / ????" <jinmei@isl.rdc.toshiba.co.jp>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org
Subject: RE: Ordering of % and / in  RFC 4007
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable


The code below would be straightforward if the "/64" prefix were
accepted by getaddrinfo. =20

Besides, I don't think the textual representation should be defined to
make only Basic Socket API functions straightforward.  IMHO, the order
should be logical on its own.  The prefix is clearly more tightly
related to the IP address (in6_addr) and the scope zone index is clearly
(by virtual of the fact that scope_id is in sockaddr_in6) related to the
transport address.  So the textual representation as it stands now mixes
IP address and Transport address information.

--Stephen

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp]

Sent: Thursday, April 07, 2005 2:59 AM
To: Steve Cipolli
Cc: ipv6@ietf.org
Subject: Re: Ordering of % and / in RFC 4007


>>>>> On Wed, 6 Apr 2005 10:09:22 -0400,
>>>>> "Steve Cipolli" <SCipolli@radvision.com> said:

> Can someone explain the rational for why RFC 4007 mandates the scope=20
> zone index before the prefix in the textual representation?

(snip)

> Section 11.7 says its important to put the scope zone index first for=20
> parsing by name-to-address functions and references a document that I=20
> was unable to find.  I understand the "name-to-address functions" to=20
> mean getaddrinfo.  However I'm not clear why getaddrinfo should care=20
> that scope zone index appeared first assuming the substring "ip6 ['/'=20
> prefix]" were handled by a function similar in6_addr_pton above.

The intended function is getaddrinfo, yes.  And the expected usage in
this case is as follows:

(assume variable "prefix" points to a string like "fe80::%5/64")

	char *addr, *p;
	int plen;

	p =3D strchr(prefix, '/');
	*p++ =3D '\0';
	getaddrinfo(p, NULL, hints, res);
	plen =3D atoi(p);

(Note: error handling or proper handling of constant variables are
ignored for simplicity)

Then
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr =3D fe80::
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id =3D 5
  plen =3D 64

If we represented the scoped prefix as, e.g., "fe80::/64%5", the above
code couldn't be that straightforward.

					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 Apr  7 11:48:37 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06802
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 11:48:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJZ5s-0004xA-C7; Thu, 07 Apr 2005 11:38:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZ5q-0004wz-Nw
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 11:38:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05948
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 11:38:51 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZEP-0007eb-UD
	for ipv6@ietf.org; Thu, 07 Apr 2005 11:47:47 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DJZ5l-000946-4D; Thu, 07 Apr 2005 15:38:49 +0000
In-Reply-To: <20050407072311.682DD41EA@thrintun.hactrn.net>
References: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
	<7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
	<20050407072311.682DD41EA@thrintun.hactrn.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b5670584d21a7c43b21050dd6df46fe7@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Thu, 7 Apr 2005 11:38:16 -0400
To: Rob Austein <sra@isc.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Fred Baker <fred@cisco.com>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 7 Apr 2005, at 03:23, Rob Austein wrote:

> At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote:
>>
>> proposed text...
>
> While I appreciate the effort that Fred put into crafting text, I'd
> prefer Brian's original proposal.

To further paraphrase Rob's comments here, there is a lot to think 
about when considering the deployment of services using anycast; to 
insert comprehensive text on that subject into the draft at hand would 
require a lot more than two paragraphs.

The issues that Fred addressed with his text are discussed at length in 
draft-ietf-grow-anycast. I would submit that the grow document is the 
right place for them, and that it's not necessary to duplicate them in 
the v6 addressing architecture: in fact, I think clarity is best served 
by keeping them separate.


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 12:06:04 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08707
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 12:06:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJZQY-00048b-VJ; Thu, 07 Apr 2005 12:00:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZQO-00045h-L2
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:00:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08229
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 12:00:04 -0400 (EDT)
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 1DJZYw-0008Sl-Ji
	for ipv6@ietf.org; Thu, 07 Apr 2005 12:09:00 -0400
Message-ID: <080f01c53b8b$02759380$0f6115ac@dcml.docomolabsusa.com>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Fred Baker" <fred@cisco.com>, "Mark Andrews" <Mark_Andrews@isc.org>
References: <200504070450.j374o5Qp047242@drugs.dv.isc.org>
Date: Thu, 7 Apr 2005 09:00:59 -0700
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: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Brian Haberman <brian@innovationslab.net>,
        Bob Hinden <bob.hinden@nokia.com>, Joe Abley <Joe_Abley@isc.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

I agree.

            jak

----- Original Message ----- 
From: "Mark Andrews" <Mark_Andrews@isc.org>
To: "Fred Baker" <fred@cisco.com>
Cc: "Brian Haberman" <brian@innovationslab.net>; "James Kempf"
<kempf@docomolabs-usa.com>; "Margaret Wasserman" <margaret@thingmagic.com>;
"Bob Hinden" <bob.hinden@nokia.com>; "IPv6 WG" <ipv6@ietf.org>; "Joe Abley"
<Joe_Abley@isc.org>
Sent: Wednesday, April 06, 2005 9:50 PM
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt


>
> > OK, so then lets go back to the question posed in the thread. The
> > current spec says that one should never use an anycast address as a
> > source address under any circumstances. That clearly flies in the face
> > of present practice, isn't responsiv to the set of concerns you raised
> > about anycast in general, and can be mitigated if anycast is use for
> > rendesvous. The suggestion was made that under a defined set of
> > circumstances (single message each way exchange, rendezvous, perhaps
> > some others) and with a defined set of procedures it would be OK to use
> > it as a source address. Those procedures need to spell out the whys and
> > wherefores.
> >
> > Would you be willing to see the 100% ban removed from the draft
> > standard and substitute text to the effect of that above included, with
> > follow-up work in grow-or-wherever to spell out those procedures?
>
> Definitely yes.
>
> > On Apr 6, 2005, at 8:19 PM, Mark Andrews wrote:
> >
> > >
> > >>
> > >> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:
> > >>
> > >>> Getting back to unicast initiated sessions I would still
> > >>> like to see some mechanism (as low in the stack as possible)
> > >>> which would allow long running session to survive routing
> > >>> changes.
> > >>
> > >> You're speaking in this thread. Did you take a look at the proposal
> > >> that Eric Nordmark, I, and the grow folks have discussed about a
> > >> care-of-address that would give a long term fixed address to the
> > >> server
> > >> in question? Answering that question is where we started out.
> > >
> > > care-of-address would be overkill for somethings and
> > > quite a reasonable solution for others.  If it could be
> > > made selectable on a per/socket basis (I havn't looked
> > > at how implemetation do this at present) I suspect this
> > > will meet most of what would be required.
> > >
> > > In other words we would not want to do this for DNS/UDP but
> > > for DNS/TCP it would be acceptable even though it would only
> > > be really required for long running AXFR's (multi-megabyte).
> > >
> > >> --------------------------------------------------------------------
> > >> IETF IPv6 working group mailing list
> > >> ipv6@ietf.org
> > >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > >> --------------------------------------------------------------------
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
> > >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
>



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 12:22:59 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10539
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 12:22:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJZYm-000533-3C; Thu, 07 Apr 2005 12:08:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZYk-00052x-PE
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:08:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08939
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 12:08:43 -0400 (EDT)
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 1DJZhL-0000LA-0m
	for ipv6@ietf.org; Thu, 07 Apr 2005 12:17:39 -0400
Message-ID: <082101c53b8c$3b6da9b0$0f6115ac@dcml.docomolabsusa.com>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Rob Austein" <sra@isc.org>, "Fred Baker" <fred@cisco.com>
References: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com><7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
	<20050407072311.682DD41EA@thrintun.hactrn.net>
Date: Thu, 7 Apr 2005 09:09:45 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Sounds eminently logical. I think it makes sense to remove the restriction
in draft-ietf-ipv6-addr-arch but spend some time discussing the finer points
in more depth rather than try to craft some text on the fly to substitute.
GROW might be the right place to do so (I see there's a draft about anycast
there) but I do note that the GROW charter does not specifically mention
anycast, and some of the issues discussed in this thread may involve more
IGP rather than EGP operations, which seems to be GROW's focus.

            jak


----- Original Message ----- 
From: "Rob Austein" <sra@isc.org>
To: "Fred Baker" <fred@cisco.com>
Cc: "Margaret Wasserman" <margaret@thingmagic.com>; "IPv6 WG"
<ipv6@ietf.org>
Sent: Thursday, April 07, 2005 12:23 AM
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt


> At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote:
> >
> > proposed text...
>
> While I appreciate the effort that Fred put into crafting text, I'd
> prefer Brian's original proposal.  The only parts of this set of
> anycast issues that's specific to IPv6 are the restrictions that the
> IPv6 address architecture doc imposes on use of anycast in IPv6.  The
> rest of the issues are IP-version-independent, and are already under
> consideration in another WG which has the relevant routing expertise.
> So I think the best thing for the IPv6 WG per se to do would be to
> clear up the old IPv6-specific restrictions, then bow out gracefully.
>
> If folks from the IPv6 WG want to wander over to GROW and chat about
> the issues Fred's proposed text attempts to document, that sounds like
> a fine and useful thing, and I'm sure that the folks over in GROW
> would be happy to get additional eyes reviewing their work, but to me
> that looks like a separate activity in a separate WG and does not need
> to be tightly coupled to the IPv6 address architecture doc.
>
> --------------------------------------------------------------------
> 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 Apr  7 12:31:27 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11758
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 12:31:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJZnW-0007sf-2W; Thu, 07 Apr 2005 12:24:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZnU-0007s7-SI
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:24:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10724
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 12:23:57 -0400 (EDT)
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 1DJZw4-00011V-Ef
	for ipv6@ietf.org; Thu, 07 Apr 2005 12:32:53 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 07 Apr 2005 09:23:50 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j37GNhgE004851;
	Thu, 7 Apr 2005 09:23:44 -0700 (PDT)
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j37GFa4R022552;
	Thu, 7 Apr 2005 09:15:37 -0700
In-Reply-To: <20050407072311.682DD41EA@thrintun.hactrn.net>
References: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
	<7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
	<20050407072311.682DD41EA@thrintun.hactrn.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <67ef7ff27e819df40874f5af5a90f261@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Thu, 7 Apr 2005 09:23:46 -0700
To: Rob Austein <sra@isc.org>
X-Mailer: Apple Mail (2.619.2)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1112890537.178550"; x:"432200"; a:"rsa-sha1"; b:"nofws:1038";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"NKUGI1MRbVr4kQF9+69PdiWqleRrMfljeIQrJAjgDePm42zif+fJY5DYZmWDKGTgHy0lZy/r"
	"GjJpqPTaSRQNPl5KCpsLnYS5WgfD3SK2Dj61vZQcJ/Vwtq1LO0o+vda4eHOUzunkYrvrkIERQ8a"
	"W+8lH2G5ZDzNsb1dM3ac87IA="; c:"From: Fred Baker <fred@cisco.com>";
	c:"Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt";
	c:"Date: Thu, 7 Apr 2005 09:23:46 -0700"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

My problem is that the current text precludes the grow work. I am not 
trying to specify it; I am trying to permit it.

Remind me what Brian's original text proposal was?


On Apr 7, 2005, at 12:23 AM, Rob Austein wrote:

> At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote:
>>
>> proposed text...
>
> While I appreciate the effort that Fred put into crafting text, I'd
> prefer Brian's original proposal.  The only parts of this set of
> anycast issues that's specific to IPv6 are the restrictions that the
> IPv6 address architecture doc imposes on use of anycast in IPv6.  The
> rest of the issues are IP-version-independent, and are already under
> consideration in another WG which has the relevant routing expertise.
> So I think the best thing for the IPv6 WG per se to do would be to
> clear up the old IPv6-specific restrictions, then bow out gracefully.
>
> If folks from the IPv6 WG want to wander over to GROW and chat about
> the issues Fred's proposed text attempts to document, that sounds like
> a fine and useful thing, and I'm sure that the folks over in GROW
> would be happy to get additional eyes reviewing their work, but to me
> that looks like a separate activity in a separate WG and does not need
> to be tightly coupled to the IPv6 address architecture doc.
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 13:01:16 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14508
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 13:01:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJaIo-0003gO-Kt; Thu, 07 Apr 2005 12:56:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaIm-0003gJ-Su
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:56:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14115
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 12:56:17 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaRM-0002MK-AG
	for ipv6@ietf.org; Thu, 07 Apr 2005 13:05:13 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DJaIj-0009G8-8D; Thu, 07 Apr 2005 16:56:17 +0000
In-Reply-To: <67ef7ff27e819df40874f5af5a90f261@cisco.com>
References: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
	<7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
	<20050407072311.682DD41EA@thrintun.hactrn.net>
	<67ef7ff27e819df40874f5af5a90f261@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <c1c81c579482c2ae50bc97642155a6ce@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Thu, 7 Apr 2005 12:55:44 -0400
To: Fred Baker <fred@cisco.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: Rob Austein <sra@isc.org>, Margaret Wasserman <margaret@thingmagic.com>,
        IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 7 Apr 2005, at 12:23, Fred Baker wrote:

> My problem is that the current text precludes the grow work. I am not 
> trying to specify it; I am trying to permit it.
>
> Remind me what Brian's original text proposal was?

In my note to the IESG, I requested that the following text in 
draft-ietf-ipv6-addr-arch-v4-02 be simply removed from section 2.6:

>>    There is little experience with widespread, arbitrary use of 
>> Internet
>>    anycast addresses, and some known complications and hazards when
>>    using them in their full generality [ANYCST].  Until more 
>> experience
>>    has been gained and solutions are specified, the following
>>    restrictions are imposed on IPv6 anycast addresses:
>>
>>       o An anycast address must not be used as the source address of 
>> an
>>         IPv6 packet.
>>
>>       o An anycast address must not be assigned to an IPv6 host, that
>>         is, it may be assigned to an IPv6 router only.

Brian's note, which quotes draft-jabley-v6-anycast-clarify-00, is below.


Joe

> On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote:
>
>> All,
>>      I am soliciting input on a proposal to modify the rules defined
>> in the current addressing architecture draft with respect to anycast.
>> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to 
>> change
>> the following text in the addressing architecture:
>>
>>       o An anycast address must not be used as the source address of 
>> an
>>          IPv6 packet.
>>
>>       o An anycast address must not be assigned to an IPv6 host, that
>>          is, it may be assigned to an IPv6 router only.
>>
>> to
>>
>>    o  An anycast address MAY be used as the source address of an IPv6
>>        packet.
>>    o  An anycast address MAY be assigned to an IPv6 host.
>>
>> This change will allow users to operate IPv6 anycast services in the 
>> same
>> manner in which they do today with IPv4 anycast.
>>
>> I would like people to chime in before April 15, 2005 with their 
>> opinion on
>> making this change.
>>
>> It should be noted that the addressing architecture is currently in 
>> IETF Last
>> Call.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 13:39:52 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17902
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 13:39:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJawI-0007il-On; Thu, 07 Apr 2005 13:37:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJawG-0007iK-Uy
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 13:37:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17668
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 13:37:05 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJb4s-0003qi-33
	for ipv6@ietf.org; Thu, 07 Apr 2005 13:46:02 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-5.cisco.com with ESMTP; 07 Apr 2005 10:36:59 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j37HauDr003426;
	Thu, 7 Apr 2005 10:36:57 -0700 (PDT)
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j37HSjkL023336;
	Thu, 7 Apr 2005 10:28:45 -0700
In-Reply-To: <c1c81c579482c2ae50bc97642155a6ce@isc.org>
References: <FBA7FB88A51E804BA4A111CDFD2DE638604139@esebe105.NOE.Nokia.com>
	<7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com>
	<20050407072311.682DD41EA@thrintun.hactrn.net>
	<67ef7ff27e819df40874f5af5a90f261@cisco.com>
	<c1c81c579482c2ae50bc97642155a6ce@isc.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <94349e728e2a2a872d5256cedf9abfa4@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Thu, 7 Apr 2005 10:36:54 -0700
To: Joe Abley <jabley@isc.org>
X-Mailer: Apple Mail (2.619.2)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1112894925.892493"; x:"432200"; a:"rsa-sha1"; b:"nofws:1889";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"dU+5reOZaD4sra4h4hpiDAtmBEBJyR7PU9OrH6hp6z03MkSzgAtu1n7gxo8L3eCnbtnIjB5/"
	"nT64Ki/wWtRDXN9hD5NPNm4atEvV1MkLE5NXlqb0H2ulRnW9+57t5uCqXIFMEKsfQNKBo3ZL+Gw"
	"/pK+sHVC5CiT6u0g9oIhl6KA="; c:"From: Fred Baker <fred@cisco.com>";
	c:"Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt";
	c:"Date: Thu, 7 Apr 2005 10:36:54 -0700"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Cc: Rob Austein <sra@isc.org>, Margaret Wasserman <margaret@thingmagic.com>,
        IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

OK.

I can go with Brian's first bullet. That said, since any other unicast 
address may be used as a source address, I wonder whether it would be 
more useful to simply remove the bullets.


On Apr 7, 2005, at 9:55 AM, Joe Abley wrote:

>
> On 7 Apr 2005, at 12:23, Fred Baker wrote:
>
>> My problem is that the current text precludes the grow work. I am not 
>> trying to specify it; I am trying to permit it.
>>
>> Remind me what Brian's original text proposal was?
>
> In my note to the IESG, I requested that the following text in 
> draft-ietf-ipv6-addr-arch-v4-02 be simply removed from section 2.6:
>
>>>    There is little experience with widespread, arbitrary use of 
>>> Internet
>>>    anycast addresses, and some known complications and hazards when
>>>    using them in their full generality [ANYCST].  Until more 
>>> experience
>>>    has been gained and solutions are specified, the following
>>>    restrictions are imposed on IPv6 anycast addresses:
>>>
>>>       o An anycast address must not be used as the source address of 
>>> an
>>>         IPv6 packet.
>>>
>>>       o An anycast address must not be assigned to an IPv6 host, that
>>>         is, it may be assigned to an IPv6 router only.
>
> Brian's note, which quotes draft-jabley-v6-anycast-clarify-00, is 
> below.
>
>
> Joe
>
>> On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote:
>>
>>> All,
>>>      I am soliciting input on a proposal to modify the rules defined
>>> in the current addressing architecture draft with respect to anycast.
>>> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to 
>>> change
>>> the following text in the addressing architecture:
>>>
>>>       o An anycast address must not be used as the source address of 
>>> an
>>>          IPv6 packet.
>>>
>>>       o An anycast address must not be assigned to an IPv6 host, that
>>>          is, it may be assigned to an IPv6 router only.
>>>
>>> to
>>>
>>>    o  An anycast address MAY be used as the source address of an IPv6
>>>        packet.
>>>    o  An anycast address MAY be assigned to an IPv6 host.
>>>
>>> This change will allow users to operate IPv6 anycast services in the 
>>> same
>>> manner in which they do today with IPv4 anycast.
>>>
>>> I would like people to chime in before April 15, 2005 with their 
>>> opinion on
>>> making this change.
>>>
>>> It should be noted that the addressing architecture is currently in 
>>> IETF Last
>>> Call.
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 14:05:26 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20818
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 14:05:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJbL8-0004Hh-2Q; Thu, 07 Apr 2005 14:02:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbL5-0004F9-SS
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 14:02:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20262
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 14:02:43 -0400 (EDT)
From: kck@netcom.com
Received: from smtp10.atl.mindspring.net ([207.69.200.246])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbTc-0004kp-Rw
	for ipv6@ietf.org; Thu, 07 Apr 2005 14:11:39 -0400
Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net)
	by smtp10.atl.mindspring.net with esmtp (Exim 3.36 #1)
	id 1DJbKu-0003tu-00
	for ipv6@ietf.org; Thu, 07 Apr 2005 14:02:36 -0400
Message-ID: <5113226.1112896957217.JavaMail.root@wamui04.slb.atl.earthlink.net>
Date: Thu, 7 Apr 2005 11:02:37 -0700 (GMT-07:00)
To: ipv6@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Earthlink Zoo Mail 1.0
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: kck@netcom.com
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit





> Do you have any concerns that relate to using an anycast address as the 
> *source*?

What keeps 2 different hosts from using the same anycast address? If they both talk to the same destination address tuple (a different anycast address but 2 different hosts) can't there be problems?

Seems that there are edge cases that can cause real problems.



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From lefklb@ausi.com  Thu Apr  7 14:08: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 OAA21654;
	Thu, 7 Apr 2005 14:08:33 -0400 (EDT)
Date: Thu, 7 Apr 2005 14:08:33 -0400 (EDT)
Received: from gen92-4-82-235-10-136.fbx.proxad.net ([82.235.10.136])
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DJbZH-0004wz-4n; Thu, 07 Apr 2005 14:17:28 -0400
Received: from pessimism.dynamite.com ([68.57.127.163])
          by quake.axn-asia.com
          (InterMail vK.4.04.00.03 280-880-452-20030223 license 963117fv08xp3crr0de440h9p85r9w56)
          with SMTP id <20040913446839.UHPT17437.quake@pessimism.dynamite.com>
          for <imrg@ietf.org>; Thu, 07 Apr 2005 13:08:23 -0600
	  Date: Thu, 07 Apr 2005 13:08:23 -0600
From: Ivan Heard <lefklb@ausi.com>
Subject: Vicodin,Soma,Valium at very low price
To: <imrg@ietf.org>
References: <KWN58TNOV8X4ZEXH@axn-asia.com>
In-Reply-To: <KWN58TNOV8X4ZEXH@axn-asia.com>
Message-ID: <832816109971.TZO78216@francimel.com>ghost.dynamite.com>
Message-ID: <832816109971.TZO78216@francimel.com>
MIME-version: 1.0
Content-Type: multipart/alternative;
	boundary="----_001_8651_92Z70NX6.03FF6119"
X-Mailer: mPOP Web-Mail 2.19
X-Spam-Score: 3.4 (+++)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

This is a multi-part message in MIME format.

------_001_8651_92Z70NX6.03FF6119
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7Bit

Hi,
You can buy the most wanted medications from our site.
we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable price.
we ship worldwide and no prescription is needed.
http://www.grx-meds.com/scripts/default.asp?idaff=110
Cheapest Online Pharmacy

------_001_8651_92Z70NX6.03FF6119
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7Bit

Hi,<br>You can buy the most wanted medications from our site.<br>we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable 

price.<br>
we ship worldwide and no prescription is needed.<br><A HREF="http://www.grx-meds.com/scripts/default.asp?idaff=110">Cheapest Online 

Pharmacy</A>

------_001_8651_92Z70NX6.03FF6119--


From ipv6-bounces@ietf.org  Thu Apr  7 14:37:33 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24780
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 14:37:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJbrG-0001jR-B2; Thu, 07 Apr 2005 14:36:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbrE-0001jL-Na
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 14:36:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24492
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 14:35:57 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbze-0005x5-Et
	for ipv6@ietf.org; Thu, 07 Apr 2005 14:44:53 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DJbqv-0009WN-E8; Thu, 07 Apr 2005 18:35:41 +0000
In-Reply-To: <5113226.1112896957217.JavaMail.root@wamui04.slb.atl.earthlink.net>
References: <5113226.1112896957217.JavaMail.root@wamui04.slb.atl.earthlink.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <c68a1ab4b65624f5f1e8847228e6cba7@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Thu, 7 Apr 2005 14:35:09 -0400
To: kck@netcom.com
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 7 Apr 2005, at 14:02, kck@netcom.com wrote:

>> Do you have any concerns that relate to using an anycast address as 
>> the
>> *source*?
>
> What keeps 2 different hosts from using the same anycast address? If 
> they both talk to the same destination address tuple (a different 
> anycast address but 2 different hosts) can't there be problems?
>
> Seems that there are edge cases that can cause real problems.

It is usual for more than one host to use the same anycast address 
(that's what makes the otherwise-unremarkable unicast address concerned 
"anycast").

The proposal to remove the restrictions in the v6 address architecture 
is not based on the belief that it is impossible to use anycast badly; 
it is based on operational experience that it is possible to use 
anycast safely.

Successful anycast services deployments are made in environments where 
the expected stability of the routing system between a unicast client 
and an anycast destination is good enough that packets from the client 
to the service address will continue to land on the same server for as 
long as it takes for the transaction to complete.

For some routing systems this means that only short-lived transactions 
are suitable for deployment as anycast systems (e.g. DNS has a small 
transaction time, and experience seems to show that it is a reasonable 
candidate for anycast deployment on the public Internet with relatively 
dense node placement).

For other routing systems, longer-duration transactions may be suitable 
(e.g. within the IGP of a service provider, it is not unknown for web 
cache services and mail submission services to be anycast within the 
IGP, say one server per site, allowing rapid service for local clients 
with an automatic fall-back to other sites if a server fails).

Where anycast is used inappropriately, it is entirely possible that 
persistent failures may result from successive packets from the same 
client (in the same transaction) being received by different anycast 
nodes.

The grow wg document draft-ietf-grow-anycast-00 aims to provide 
guidance to implementors such that inappropriate use of anycast can be 
avoided.


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr  7 18:33:50 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16747
	for <ipngwg-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:33:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJfWd-00088Z-Ki; Thu, 07 Apr 2005 18:30:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfWb-00088R-IX
	for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 18:30:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16023
	for <ipv6@ietf.org>; Thu, 7 Apr 2005 18:30:54 -0400 (EDT)
Received: from farside.isc.org ([204.152.187.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJffE-0005cl-81
	for ipv6@ietf.org; Thu, 07 Apr 2005 18:39:53 -0400
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 960B567503
	for <ipv6@ietf.org>; Thu,  7 Apr 2005 22:30:41 +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 j37MUcBe048123;
	Fri, 8 Apr 2005 08:30:38 +1000 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200504072230.j37MUcBe048123@drugs.dv.isc.org>
To: "Steve Cipolli" <SCipolli@radvision.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Thu, 07 Apr 2005 11:13:00 -0400."
	<BBC4EAA361F44F45AB1EC1915D0CF5244D4CE9@rvnj-mail.radvision.com> 
Date: Fri, 08 Apr 2005 08:30:38 +1000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: ipv6@ietf.org, JINMEI Tatuya / ???? <jinmei@isl.rdc.toshiba.co.jp>
Subject: Re: Ordering of % and / in RFC 4007 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


> 
> The code below would be straightforward if the "/64" prefix were
> accepted by getaddrinfo.  
> 
> Besides, I don't think the textual representation should be defined to
> make only Basic Socket API functions straightforward.  IMHO, the order
> should be logical on its own.  The prefix is clearly more tightly
> related to the IP address (in6_addr) and the scope zone index is clearly
> (by virtual of the fact that scope_id is in sockaddr_in6) related to the
> transport address.  So the textual representation as it stands now mixes
> IP address and Transport address information.
> 
> --Stephen

	No they are both properties that can be associated with a
	address.  If anything the scope ties closer than the prefix
	as a link-local address or prefix is meanless w/o the scope.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From clerkley@doneasy.com  Thu Apr  7 18:52: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 SAA17802;
	Thu, 7 Apr 2005 18:52:47 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DJg0L-0006MI-CZ; Thu, 07 Apr 2005 19:01:47 -0400
Received: from [220.91.17.165] (helo=65.246.255.50)
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1DJYer-0001IF-5s; Thu, 07 Apr 2005 11:11:01 -0400
Received: from sizzle-jcoppens.com (EHLO beside.jcoppens.com) 
  by christy.jcoppens.com with SMTP; Thu, 07 Apr 2005 14:11:20 -0200
Date: Thu, 07 Apr 2005 20:11:20 +0400
From: "Florence Flores" <clerkley@doneasy.com>
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org
Subject: Pre-approved Application #HDLV666
Message-ID: <BKELLDAGKABIOCHDFD344DGAA.danny866@virgilio.it>
X-SpamTest-Info: Profile: SysLog
X-SpamTest-Status: Not detected
X-SpamTest-Version: SMTP-Filter Version 2.0.0 [601], SpamtestISP/Release
X-Mailer: MIME-tools 5.41 (Entity 5.404)
X-Spam-Score: 10.8 (++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.3-m-n.net/sign.asp



 Best Regards,

 Parker Billings
 
 to be remov(ed:	http://www.3-m-n.net/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Fri Apr  8 07:30:11 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05580
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 07:30:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJrcK-0003Nx-Qw; Fri, 08 Apr 2005 07:25:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrcH-0003Nh-SH
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 07:25:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04949
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 07:25:35 -0400 (EDT)
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJrkx-0007By-0M
	for ipv6@ietf.org; Fri, 08 Apr 2005 07:34:40 -0400
Received: (qmail 1231 invoked from network); 8 Apr 2005 11:23:19 -0000
Received: from 200-70-176-45.mrse.com.ar (HELO fernando.gont.com.ar)
	(gont-fernando@200.70.176.45)
	by server.frh.utn.edu.ar with SMTP; 8 Apr 2005 11:23:19 -0000
Message-Id: <4.3.2.7.2.20050408081441.00dafc00@server.frh.utn.edu.ar>
X-Sender: gont-fernando@server.frh.utn.edu.ar
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 08 Apr 2005 08:36:06 -0300
To: Mukesh.K.Gupta@nokia.com, <ipv6@ietf.org>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B052093@daebe102.NOE.Nokia. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Subject: Re: ICMPv6 draft: Source Address Determination
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At 10:53 09/03/2005 -0600, Mukesh.K.Gupta@nokia.com wrote:

>As discussed in the IPv6 WG meeting yesterday, I am planning to
>replace sub-sections (b), (c) and (d) of section 2.2 in the
>draft with the following text:
>
>=======================================
>(b) If the message is a response to a message sent to any other
>     address, such as
>       - a multicast group address,
>       - an anycast address implemented by the node, or
>       - a unicast address which does not belong to the node
>     the Source Address of the ICMPv6 packet MUST be a unicast
>     address belonging to the node.  The address SHOULD be chosen
>     according to the rules which would used to select the source
>     address for any other packet originated by the node, given
>     the destination address of the packet, but MAY be selected
>     in an alternative way if this would lead to a more
>     informative choice of address which is reachable from the
>     destination of the ICMPv6 packet.
>=======================================

Unless I'm missing something this change makes it more probably that the 
source address of the ICMP be different than the destination IP address of 
the packet that elicited it.

Suppose an ICMP error refers to a TCP connection I have established with a 
remote peer. With this modifications to the ICMPv6 draft, I could no longer 
require ICMP messages to have the same source address that is being used 
for the TCP connection.

As a result, an attacker would not need to forge the source address of 
ICMPv6 messages for them to be passed to the corresponding transport 
protocol instance, and thus simple egress-filtering would not server as a 
counter-measure against ICMP-based attacks.

Let me know if I am missing something.

Thanks!


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 07:41:51 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06803
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 07:41:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJrcJ-0003Nq-TP; Fri, 08 Apr 2005 07:25:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrcH-0003Ng-SH
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 07:25:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04948
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 07:25:34 -0400 (EDT)
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJrkx-0007Bz-1C
	for ipv6@ietf.org; Fri, 08 Apr 2005 07:34:40 -0400
Received: (qmail 23559 invoked from network); 8 Apr 2005 11:23:23 -0000
Received: from 200-70-176-45.mrse.com.ar (HELO fernando.gont.com.ar)
	(gont-fernando@200.70.176.45)
	by server.frh.utn.edu.ar with SMTP; 8 Apr 2005 11:23:23 -0000
Message-Id: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar>
X-Sender: gont-fernando@server.frh.utn.edu.ar
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 08 Apr 2005 08:43:37 -0300
To: ipv6@ietf.org
From: Fernando Gont <fernando@gont.com.ar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Mukesh.K.Gupta@nokia.com
Subject: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Folks,

I sent some comments off-list to Mukesh, and he suggested to raise them on 
the list.

I think the ICMPv6 draft should add some words to raise awareness about 
ICMP-based attacks that can be performed against transport protocols.

For example, the current draft suggest IPsec, or no checks at all on the 
received ICMP error mesasges.

As pointed out by Pekka:

>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.


Another issue that may be worth considering is suggesting that the 
so-called "hard errors" should not necessarily be considered "hard". While 
there's no RFC 1122 for IPv6 (and thus you might say there's no such thing 
as "hard errors" and "soft errors" in v6), I think everyone will 
extrapolate RFC 1122's statements on soft and hard errors to the ICMPv6 
specification.


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 08:16:11 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10863
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 08:16:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJsMj-0004V0-6Q; Fri, 08 Apr 2005 08:13:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsMh-0004Ur-KK
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 08:13:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10573
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 08:13:34 -0400 (EDT)
Message-Id: <200504081213.IAA10573@ietf.org>
Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsVR-0001cX-03
	for ipv6@ietf.org; Fri, 08 Apr 2005 08:22:38 -0400
Received: from [81.187.254.247] (helo=elwynslaptop)
	by smtp.aaisp.net.uk with esmtp (Exim 4.42)
	id 1DJsMU-0007rm-01; Fri, 08 Apr 2005 13:13:22 +0100
From: "Elwyn davies" <elwynd@dial.pipex.com>
To: "'Fernando Gont'" <fernando@gont.com.ar>, <Mukesh.K.Gupta@nokia.com>,
        <ipv6@ietf.org>
Date: Fri, 8 Apr 2005 13:13:57 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-reply-to: <4.3.2.7.2.20050408081441.00dafc00@server.frh.utn.edu.ar>
thread-index: AcU8L32ztS6kyD4gTeKvf4Or7BU4DQAAXTRQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit
Subject: RE: ICMPv6 draft: Source Address Determination/Anycast
	considerations
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit



(As party to the discussion which produced this new text) I don't believe
that this alters the current state of affairs significantly.  If the ICMPv6
message is coming from the destination node it is (still) required by 2.2(a)
to use the destination adddress of the original message as source.  The new
text just pulls together the three pre-existing cases where the ICMP message
is generated at another node or refers to a message which has a destination
which could be one of several nodes (multicast or anycast).

Egress filtering will still be as effective as it might have been because
the message is coming from and has a source address of a node on the routing
path to the destination. At least one of the intentions of the change was to
ensure that the source address was a unicast address with a suitable scope
to make it through all the relevant filters (in particular avoiding getting
a link local address as source in response to a message which came from off
link).

However, we should maybe pause a moment and think about the anycast case in
the light of recent proposals to change the restrictions on anycast
addresses being used as the source address for packets. My view is that this
does NOT affect the proposal here: Substituting a 'real' unicast address for
the anycast address gives the best information to the originator of the
offending message in line with the principle in the new text.

Regards,
Elwyn

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Fernando Gont
> Sent: 08 April 2005 12:36
> To: Mukesh.K.Gupta@nokia.com; ipv6@ietf.org
> Subject: Re: ICMPv6 draft: Source Address Determination
> 
> At 10:53 09/03/2005 -0600, Mukesh.K.Gupta@nokia.com wrote:
> 
> >As discussed in the IPv6 WG meeting yesterday, I am planning to
> >replace sub-sections (b), (c) and (d) of section 2.2 in the
> >draft with the following text:
> >
> >=======================================
> >(b) If the message is a response to a message sent to any other
> >     address, such as
> >       - a multicast group address,
> >       - an anycast address implemented by the node, or
> >       - a unicast address which does not belong to the node
> >     the Source Address of the ICMPv6 packet MUST be a unicast
> >     address belonging to the node.  The address SHOULD be chosen
> >     according to the rules which would used to select the source
> >     address for any other packet originated by the node, given
> >     the destination address of the packet, but MAY be selected
> >     in an alternative way if this would lead to a more
> >     informative choice of address which is reachable from the
> >     destination of the ICMPv6 packet.
> >=======================================
> 
> Unless I'm missing something this change makes it more probably that the
> source address of the ICMP be different than the destination IP address of
> the packet that elicited it.
> 
> Suppose an ICMP error refers to a TCP connection I have established with a
> remote peer. With this modifications to the ICMPv6 draft, I could no
> longer
> require ICMP messages to have the same source address that is being used
> for the TCP connection.
> 
> As a result, an attacker would not need to forge the source address of
> ICMPv6 messages for them to be passed to the corresponding transport
> protocol instance, and thus simple egress-filtering would not server as a
> counter-measure against ICMP-based attacks.
> 
> Let me know if I am missing something.
> 
> Thanks!
> 
> 
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 09:27:09 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17538
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 09:27:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJtTU-0002HH-TT; Fri, 08 Apr 2005 09:24:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJtTT-0002HC-CR
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 09:24:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17084
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 09:24:38 -0400 (EDT)
Received: from e34.co.us.ibm.com ([32.97.110.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJtcD-0005Oh-Ku
	for ipv6@ietf.org; Fri, 08 Apr 2005 09:33:43 -0400
Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com
	[9.17.195.12])
	by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j38DOS5b438432
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 09:24:28 -0400
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167])
	by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j38DOR0k210256 for <ipv6@ietf.org>; Fri, 8 Apr 2005 07:24:28 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1])
	by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j38DORe1022514 for <ipv6@ietf.org>; Fri, 8 Apr 2005 07:24:27 -0600
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com
	[9.17.195.144])
	by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j38DORBw022502 for <ipv6@ietf.org>; Fri, 8 Apr 2005 07:24:27 -0600
In-Reply-To: <200504060104.j3614Bau005456@cichlid.raleigh.ibm.com>
To: ipv6@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OF5F34DE98.7F123361-ON87256FDD.0048B1F9-85256FDD.0049BABE@us.ibm.com>
From: Kristine Adamson <adamson@us.ibm.com>
Date: Fri, 8 Apr 2005 07:24:25 -0600
X-MIMETrack: S/MIME Sign by Notes Client on Kristine
	Adamson/Raleigh/IBM(Release 6.0.3|September
	26, 2003) at 04/08/2005 09:25:19 AM,
	Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release
	6.0.3|September 26, 2003) at 04/08/2005 09:25:19 AM,
	Serialize complete at 04/08/2005 09:25:19 AM,
	S/MIME Sign failed at 04/08/2005 09:25:19 AM: The cryptographic key was
	not found,
	Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta
	3|January 11, 2005) at 04/08/2005 07:24:26,
	Serialize complete at 04/08/2005 07:24:26
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Cc: Nicholas Carbone <pizza@us.ibm.com>
Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0465408413=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

This is a multipart message in MIME format.
--===============0465408413==
Content-Type: multipart/alternative;
	boundary="=_alternative 0049BAB685256FDD_="

This is a multipart message in MIME format.
--=_alternative 0049BAB685256FDD_=
Content-Type: text/plain; charset="US-ASCII"

Thomas Narten wrote on 04/05/2005 09:04:11 PM:

> JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
> <jinmei@isl.rdc.toshiba.co.jp> writes:
> 
> > >>>>> On Fri, 1 Apr 2005 06:13:22 -0700,
> > >>>>> Kristine Adamson <adamson@us.ibm.com> said:

> > > Thanks for the responses.  But if RFC3542 is not updated, won't this
> > > adversely affect the portability of applications that references 
these new
> > > codes?

> > Yes, it will.  However, the point is whether the portability issue is
> > serious enough to require a revision of RFC3542.  Different people may
> > have different opinions on this, and I personally don't think it's big
> > enough.

> Suggestion:

> 1) Set up an issue tracker for this (and perhaps every IPv6 RFC for
> which there are some known errors/omissions?) that keeps track of
> these sorts of things. That way folk will be able to more easily
> find the list of outstanding issues (and their likely resolution),
> and we (the IETF community) won't lose track of them.
> 
> 2) Although it may be overkill in this case, one could easily publish
> a (very!) short RFC just listing the additional code points, so
> that they are documened in the RFC series, and folk looking at the
> older RFC can find the new RFC via the "updated by" tag.
> 

Besides adding the programming names of the new ICMPv6 code points to 
RFC3542, the following documents an old, minor problem with RFC3542, that 
was listed in the errata.  This problem could also be resolved with a new, 
short RFC that updates RFC3542.  Since there are 2 problems that could be 
resolved with a new RFC, do we now have sufficient reasons to publish a 
new RFC?  Thanks!

>>>>>> On Sun, 30 Nov 2003 15:58:17 +0200 (EET), 
>>>>>> Pekka Savola <pekkas@netcore.fi> said:

>>> And, in fact, the current implementation of the KAME project uses
>>> uint8_t for the align parameter.
>>> 
>>> I don't know how to correct this one, though.  Obviously, we cannot
>>> revise the document again just due to this problem.

>> Well, one could at least report it to:

>> http://www.rfc-editor.org/cgi-bin/errata.pl (link form the main page)

>Just FYI: I've reported this issue, and the errata page has just
>included the correction.

>> .. but most folks probably don't check that when reading the 
>> specs..

>I tend to agree...

>JINMEI, Tatuya
>Communication Platform Lab.
>Corporate R&D Center, Toshiba Corp.
>jinmei@isl.rdc.toshiba.co.jp

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:adamson@us.ibm.com
--=_alternative 0049BAB685256FDD_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif"><br>
</font><font size=2><tt>Thomas Narten wrote on 04/05/2005 09:04:11 PM:<br>
<br>
&gt; JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=<br>
&gt; &lt;jinmei@isl.rdc.toshiba.co.jp&gt; writes:</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; On Fri, 1 Apr 2005 06:13:22 -0700,<br>
&gt; &gt; &gt;&gt;&gt;&gt;&gt; Kristine Adamson &lt;adamson@us.ibm.com&gt;
said:<br>
</tt></font>
<br><font size=2><tt>&gt; &gt; &gt; Thanks for the responses. &nbsp;But
if RFC3542 is not updated, won't this<br>
&gt; &gt; &gt; adversely affect the portability of applications that references
these new<br>
&gt; &gt; &gt; codes?<br>
</tt></font>
<br><font size=2><tt>&gt; &gt; Yes, it will. &nbsp;However, the point is
whether the portability issue is<br>
&gt; &gt; serious enough to require a revision of RFC3542. &nbsp;Different
people may<br>
&gt; &gt; have different opinions on this, and I personally don't think
it's big<br>
&gt; &gt; enough.<br>
</tt></font>
<br><font size=2><tt>&gt; Suggestion:<br>
</tt></font>
<br><font size=2><tt>&gt; 1) Set up an issue tracker for this (and perhaps
every IPv6 RFC for<br>
&gt; which there are some known errors/omissions?) that keeps track of<br>
&gt; these sorts of things. That way folk will be able to more easily<br>
&gt; find the list of outstanding issues (and their likely resolution),<br>
&gt; and we (the IETF community) won't lose track of them.</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; 2) Although it may be overkill in this case, one could easily publish<br>
&gt; a (very!) short RFC just listing the additional code points, so<br>
&gt; that they are documened in the RFC series, and folk looking at the<br>
&gt; older RFC can find the new RFC via the &quot;updated by&quot; tag.</tt></font>
<br><font size=2><tt>&gt; <br>
</tt></font>
<br><font size=2><tt>Besides adding the programming names of the new ICMPv6
code points to RFC3542, the following documents an old, minor problem with
RFC3542, that was listed in the errata. &nbsp;This problem could also be
resolved with a new, short RFC that updates RFC3542. &nbsp;Since there
are 2 problems that could be resolved with a new RFC, do we now have sufficient
reasons to publish a new RFC? &nbsp;Thanks!</tt></font>
<br>
<br><font size=2><tt>&gt;&gt;&gt;&gt;&gt;&gt; On Sun, 30 Nov 2003 15:58:17
+0200 (EET), <br>
&gt;&gt;&gt;&gt;&gt;&gt; Pekka Savola &lt;pekkas@netcore.fi&gt; said:<br>
<br>
&gt;&gt;&gt; And, in fact, the current implementation of the KAME project
uses<br>
&gt;&gt;&gt; uint8_t for the align parameter.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; I don't know how to correct this one, though. &nbsp;Obviously,
we cannot<br>
&gt;&gt;&gt; revise the document again just due to this problem.<br>
<br>
&gt;&gt; Well, one could at least report it to:<br>
<br>
&gt;&gt; http://www.rfc-editor.org/cgi-bin/errata.pl (link form the main
page)<br>
<br>
&gt;Just FYI: I've reported this issue, and the errata page has just<br>
&gt;included the correction.<br>
<br>
&gt;&gt; .. but most folks probably don't check that when reading the <br>
&gt;&gt; specs..<br>
<br>
&gt;I tend to agree...<br>
<br>
&gt;JINMEI, Tatuya<br>
&gt;Communication Platform Lab.<br>
&gt;Corporate R&amp;D Center, Toshiba Corp.<br>
&gt;jinmei@isl.rdc.toshiba.co.jp<br>
</tt></font>
<br><font size=2 face="sans-serif">Kristine Adamson<br>
IBM z/OS Communications Server: TCP/IP Development<br>
Phone: (919) 254-7911 &nbsp; T/L 444-7911<br>
Internet e-mail:adamson@us.ibm.com</font>
--=_alternative 0049BAB685256FDD_=--


--===============0465408413==
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
--------------------------------------------------------------------

--===============0465408413==--



From ipv6-bounces@ietf.org  Fri Apr  8 11:13:49 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01884
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 11:13:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJvAR-0001mJ-HC; Fri, 08 Apr 2005 11:13:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvAB-0000pf-TB
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 11:12:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01339
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 11:10:36 -0400 (EDT)
Message-Id: <200504081510.LAA01339@ietf.org>
Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJv5O-0006op-MO
	for ipv6@ietf.org; Fri, 08 Apr 2005 11:07:58 -0400
Received: from [81.187.254.247] (helo=elwynslaptop)
	by smtp.aaisp.net.uk with esmtp (Exim 4.42)
	id 1DJuwM-00053z-17; Fri, 08 Apr 2005 15:58:34 +0100
From: "Elwyn davies" <elwynd@dial.pipex.com>
To: "'Fernando Gont'" <fernando@gont.com.ar>, <ipv6@ietf.org>
Date: Fri, 8 Apr 2005 15:59:09 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-reply-to: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar>
thread-index: AcU8Ls537v3tooQ4RUqZqi9tLsTgDAAGlSGw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
Cc: v6ops@ops.ietf.org, Mukesh.K.Gupta@nokia.com
Subject: RE: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Hi, Fernando,

Looking back at the ICMPv6 draft, in the light of this, there are a number
of sanity checks that could be performed on returning error messages to
minimise security risks.

For example:
In draft-gont-tcpm-icmp-attacks-03.txt, the 'port unreachable' error is
cited as possibly being classified as a 'hard error' and provoking a reset.
This error message should only be generated by the destination node (not an
intermediate node) so a check could be added to ensure that the ICMPv6
source was equal to the original packet destination, thus requiring address
spoofing (which you suggest is otherwise not necessary because of the rules
in 2.2).  This would slightly cramp the style of would be hackers.

Likewise, getting a spurious 'fragment reassembly time execeeded' message
for a packet which wasn't fragmented in the first place.

And a number of others.

There is also a significant chance that ICMPv6 packets related to TCP coming
from outside a firewall would be junked by the firewall, especially if they
weren't from the destination address (but usually anyway).

Some of this is discussed in the IPv6 Security Overview draft:
draft-savola-v6ops-security-overview-03.txt

It's very late in the day to modify the ICMPv6 draft but we could put some
extra stuff into the security overview as recommendations (I am currently
editing this and could add some thoughts on this stuff).

What is the community view?
- Add some comments and additional sanity checks to the ICMPv6 spec, or
- Update the security overview, or
- Combination, or
- Neither?

Regards,
Elwyn




> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Fernando Gont
> Sent: 08 April 2005 12:44
> To: ipv6@ietf.org
> Cc: Mukesh.K.Gupta@nokia.com
> Subject: Security considerations of the ICMPv6 draft
> 
> Folks,
> 
> I sent some comments off-list to Mukesh, and he suggested to raise them on
> the list.
> 
> I think the ICMPv6 draft should add some words to raise awareness about
> ICMP-based attacks that can be performed against transport protocols.
> 
> For example, the current draft suggest IPsec, or no checks at all on the
> received ICMP error mesasges.
> 
> As pointed out by Pekka:
> 
> >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.
> 
> 
> Another issue that may be worth considering is suggesting that the
> so-called "hard errors" should not necessarily be considered "hard". While
> there's no RFC 1122 for IPv6 (and thus you might say there's no such thing
> as "hard errors" and "soft errors" in v6), I think everyone will
> extrapolate RFC 1122's statements on soft and hard errors to the ICMPv6
> specification.
> 
> 
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 11:32:12 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03398
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 11:32:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJv71-0007Gw-6V; Fri, 08 Apr 2005 11:09:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJv6y-0007Cx-PC
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 11:09:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00368
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 11:09:26 -0400 (EDT)
Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvDR-0000Qm-G7
	for ipv6@ietf.org; Fri, 08 Apr 2005 11:16:14 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Fri, 8 Apr 2005 11:06:56 -0400
Message-ID: <BBC4EAA361F44F45AB1EC1915D0CF5245A849C@rvnj-mail.radvision.com>
Thread-Topic: Ordering of % and / in  RFC 4007
Thread-Index: AcU7P0A5vG2Q1abcTUqHYGHcw8BywQAQiKiQ
From: "Steve Cipolli" <SCipolli@radvision.com>
To: <ipv6@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ordering of % and / in  RFC 4007
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable


The code below would be straightforward if the "/64" prefix were
accepted by getaddrinfo. =20

Besides, I don't think the textual representation should be defined to
make only Basic Socket API functions straightforward.  IMHO, the order
should be logical on its own.  The prefix is clearly more tightly
related to the IP address (in6_addr) and the scope zone index is clearly
(by virtual of the fact that scope_id is in sockaddr_in6) related to the
transport address.  So the textual representation as it stands now mixes
IP address and Transport address information.

--Stephen

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp]

Sent: Thursday, April 07, 2005 2:59 AM
To: Steve Cipolli
Cc: ipv6@ietf.org
Subject: Re: Ordering of % and / in RFC 4007


>>>>> On Wed, 6 Apr 2005 10:09:22 -0400,
>>>>> "Steve Cipolli" <SCipolli@radvision.com> said:

> Can someone explain the rational for why RFC 4007 mandates the scope=20
> zone index before the prefix in the textual representation?

(snip)

> Section 11.7 says its important to put the scope zone index first for=20
> parsing by name-to-address functions and references a document that I=20
> was unable to find.  I understand the "name-to-address functions" to=20
> mean getaddrinfo.  However I'm not clear why getaddrinfo should care=20
> that scope zone index appeared first assuming the substring "ip6 ['/'=20
> prefix]" were handled by a function similar in6_addr_pton above.

The intended function is getaddrinfo, yes.  And the expected usage in
this case is as follows:

(assume variable "prefix" points to a string like "fe80::%5/64")

	char *addr, *p;
	int plen;

	p =3D strchr(prefix, '/');
	*p++ =3D '\0';
	getaddrinfo(p, NULL, hints, res);
	plen =3D atoi(p);

(Note: error handling or proper handling of constant variables are
ignored for simplicity)

Then
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr =3D fe80::
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id =3D 5
  plen =3D 64

If we represented the scoped prefix as, e.g., "fe80::/64%5", the above
code couldn't be that straightforward.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					jinmei@isl.rdc.toshiba.co.jp


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 17:22:39 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13448
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 17:22:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK0ty-0005JM-NX; Fri, 08 Apr 2005 17:20:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK0tr-0005D5-6z
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 17:20:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13345
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 17:20:21 -0400 (EDT)
Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK12g-0007FO-5M
	for ipv6@ietf.org; Fri, 08 Apr 2005 17:29:31 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Fri, 8 Apr 2005 17:20:06 -0400
Message-ID: <BBC4EAA361F44F45AB1EC1915D0CF5244D4CEE@rvnj-mail.radvision.com>
Thread-Topic: Ordering of % and / in RFC 4007 
Thread-Index: AcU7wXlfrV9f5yb4Tf2i6M3kNdp7CwAty3OA
From: "Steve Cipolli" <SCipolli@radvision.com>
To: <Mark_Andrews@isc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org, JINMEI Tatuya / ???? <jinmei@isl.rdc.toshiba.co.jp>
Subject: RE: Ordering of % and / in RFC 4007 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable


>>=20
>> The code below would be straightforward if the "/64" prefix were=20
>> accepted by getaddrinfo.
>>=20
>> Besides, I don't think the textual representation should be defined
to=20
>> make only Basic Socket API functions straightforward.  IMHO, the
order=20
>> should be logical on its own.  The prefix is clearly more tightly=20
>> related to the IP address (in6_addr) and the scope zone index is=20
>> clearly (by virtual of the fact that scope_id is in sockaddr_in6)=20
>> related to the transport address.  So the textual representation as
it=20
>> stands now mixes IP address and Transport address information.
>>=20
>> --Stephen
>
>	No they are both properties that can be associated with a
>	address.  If anything the scope ties closer than the prefix
>	as a link-local address or prefix is meanless w/o the scope.
I'm not sure what you mean by "address" above.  My argument is that the
prefix is associated with IP addresses (represented by struct in6_addr
in the API) and the scope is associated with transport addresses
(represented by struct sockaddr_in6 in the API).  They are both
"addresses", but they are different layer addresses.  If I map what
textual representation to what data structure it has effect on:
	[ipaddr%scope/prefix]:port is mapped into
[in6_addr%sockaddr_in6/in6_addr]:sockaddr_in6
>From my view the the textual representation and the Basic socket API
structures are inconsistent.=20

>
>	Mark
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 19:27:21 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21403
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 19:27:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK2qT-0006iQ-OD; Fri, 08 Apr 2005 19:25:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2qP-0006iG-EH
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:24:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21271
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 19:24:54 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2zG-0004AJ-38
	for ipv6@ietf.org; Fri, 08 Apr 2005 19:34:06 -0400
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id j38NOUW17249;
	Sat, 9 Apr 2005 02:24:35 +0300
Date: Sat, 9 Apr 2005 02:24:30 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar>
Message-ID: <Pine.LNX.4.61.0504090220200.17023@netcore.fi>
References: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: ipv6@ietf.org, Mukesh.K.Gupta@nokia.com
Subject: Re: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

On Fri, 8 Apr 2005, Fernando Gont wrote:
>
> I think the ICMPv6 draft should add some words to raise awareness about 
> ICMP-based attacks that can be performed against transport protocols.

Any text suggestions -- just to have an idea how verbose and explicit 
you're looking at; did you refer to the proposed text below, or 
something more extensive?

> For example, the current draft suggest IPsec, or no checks at all on the 
> received ICMP error mesasges.
>
> As pointed out by Pekka:
>
>> 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.

Yes, something like this should be added.  I thought it already was 
there, but apparently not...

> Another issue that may be worth considering is suggesting that the so-called 
> "hard errors" should not necessarily be considered "hard". While there's no 
> RFC 1122 for IPv6 (and thus you might say there's no such thing as "hard 
> errors" and "soft errors" in v6), I think everyone will extrapolate RFC 
> 1122's statements on soft and hard errors to the ICMPv6 specification.

Even if I may agree with this sentiment, IMHO it seems to go too much 
on the side of the transport protocols, and doesn't seem to be 
appropriate in this document.  The above already a provides a pointer.

-- 
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 Apr  8 19:42:46 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22201
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 19:42:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK36s-0002bf-5V; Fri, 08 Apr 2005 19:41:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK36f-0002Zb-GT
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:41:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22143
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 19:41:42 -0400 (EDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3FV-0004qq-JA
	for ipv6@ietf.org; Fri, 08 Apr 2005 19:50:55 -0400
Received: from jurassic.eng.sun.com ([129.146.86.38])
	by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j38NfgJx008292; 
	Fri, 8 Apr 2005 16:41:42 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11])
	by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id
	j38NffU5782324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Apr 2005 16:41:41 -0700 (PDT)
Message-ID: <425716A6.7060700@sun.com>
Date: Fri, 08 Apr 2005 16:41:26 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian Haberman <brian@innovationslab.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
In-Reply-To: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
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 <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>, IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Brian Haberman wrote:

>    o  An anycast address MAY be used as the source address of an IPv6
>        packet.
>    o  An anycast address MAY be assigned to an IPv6 host.
> 
> This change will allow users to operate IPv6 anycast services in the same
> manner in which they do today with IPv4 anycast.

If we do this, shouldn't we also list the issues one needs to cope with?

For instance, when anycast is used as a source address, ICMP errors 
might no longer be delivered to the sender (they might be delivered to 
some other host that uses the same anycast address). This means that 
ICMP path mtu discovery might not work. As a result, I think it would 
make sense to say that when an anycast address is used as source 
address, the sender SHOULD limit the IPv6 packets to 1280 bytes.

It might also make sense to note that the lack of ICMP errors means that 
debugging tools like ping and traceroute might not work when an anycast 
address is used as source address.

    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 Apr  8 19:54:47 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22884
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 19:54:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK3Ht-0005IJ-RP; Fri, 08 Apr 2005 19:53:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Ho-0005IE-F9
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:53:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22658
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 19:53:13 -0400 (EDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Qe-0005NG-JU
	for ipv6@ietf.org; Fri, 08 Apr 2005 20:02:25 -0400
Received: from jurassic.eng.sun.com ([129.146.17.55])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j38Nr6Xi026026; 
	Fri, 8 Apr 2005 17:53:06 -0600 (MDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11])
	by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id
	j38Nr5qa788352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Apr 2005 16:53:05 -0700 (PDT)
Message-ID: <42571952.40708@sun.com>
Date: Fri, 08 Apr 2005 16:52:50 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net><8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>	<53d287f38cdaf4d20dda471b03eb4e1e@isc.org>
	<06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com>
In-Reply-To: <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>, Fred Baker <fred@cisco.com>,
        Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>,
        Brian Haberman <brian@innovationslab.net>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

James Kempf wrote:

>>Correct. However, the v6 addressing spec prohibits the use of an 
>>anycast address from being used as the source address in a datagram, or 
>>being bound to an interface on a host. These two restrictions 
>>effectively prohibit the use of anycast as a service distribution 
>>mechanism.
>>
> 
> 
> Why was this prohibition was put into the specification? 

My recollection was that it was a combination of issues.
1. ICMP and pmtu discovery not working, means you can't use it as a
    source
2. We don't have a protocol that allow hosts to tell the routers which
    anycast addresses they want to receive
3. TCP and higher level protocols might be confused when things change
    due to routing changes

The "rebuttals" to those could be
1. Add text to say "SHOULD limit packets with an anycast source to 1280
    bytes". Add note that ICMP-based tools don't work with an anycast
    source address.
2. Any IGP (RIPng, OSPF, etc) can be used for this. (There was also some
    work to extend MLD to do this). But this really isn't a need to
    architecturally prohibit hosts from being anycast receivers; if/when
    there is a protocol by which they can advertise things, they should
    be able to use anycasts.
3. From the IPv6 WG we can point out that this is an issue, but leave it
    to some other WG to solve (whether it is solved by a protocol
    mechanisms, or operational constraints such as not using TCP with
    anycast, or ensuring that routing stays stable enough)

   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 Apr  8 20:00:03 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23291
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 20:00:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK3Mt-0006Ok-EN; Fri, 08 Apr 2005 19:58:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Mq-0006Od-OZ
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:58:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23130
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 19:58:25 -0400 (EDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Vh-0005dP-0i
	for ipv6@ietf.org; Fri, 08 Apr 2005 20:07:38 -0400
Received: from jurassic.eng.sun.com ([129.146.89.50])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j38NwJK2010264; 
	Fri, 8 Apr 2005 17:58:20 -0600 (MDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11])
	by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id
	j38NwIrb789926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Apr 2005 16:58:19 -0700 (PDT)
Message-ID: <42571A8C.5080203@sun.com>
Date: Fri, 08 Apr 2005 16:58:04 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
	<38eddbd55b0134c3497b8e4c09b41e2a@cisco.com>
In-Reply-To: <38eddbd55b0134c3497b8e4c09b41e2a@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Fred Baker wrote:

> The mobility model that Joe and I discussed requires a security 
> association to be set up with the anycast address (IPSEC management 
> protocols reply with the anycast address as a source), supply a COA, and 
> then TCP is set up to the COA.

FWIW if you believe that routing is trustworthy, i.e. that packets only 
get delivered to the hosts that are somehow authorized to receive for 
that anycast address, then it would suffice to use the return rout 
ability property for securing things, just as in MIPv6.

The only downside to this is that today the only way we have to 
authorize anycast receivers is by manual configuration in the routers 
that inject the routes for the anycast addresses.

Applying IPsec doesn't help solve the authorization issue of who should 
be allowed to receive packets sent to a particular anycast address.

    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 Apr  8 20:06:45 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23726
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 20:06:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK3Ts-0008RC-Na; Fri, 08 Apr 2005 20:05:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Tg-0008R1-Nu
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 20:05:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23635
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 20:05:29 -0400 (EDT)
Received: from farside.isc.org ([204.152.187.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3cW-0005vi-57
	for ipv6@ietf.org; Fri, 08 Apr 2005 20:14:42 -0400
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 A8E9B67503
	for <ipv6@ietf.org>; Sat,  9 Apr 2005 00:05:20 +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 j3905HKn009419;
	Sat, 9 Apr 2005 10:05:17 +1000 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200504090005.j3905HKn009419@drugs.dv.isc.org>
To: "Steve Cipolli" <SCipolli@radvision.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Fri, 08 Apr 2005 17:20:06 -0400."
	<BBC4EAA361F44F45AB1EC1915D0CF5244D4CEE@rvnj-mail.radvision.com> 
Date: Sat, 09 Apr 2005 10:05:17 +1000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: ipv6@ietf.org, JINMEI Tatuya / ???? <jinmei@isl.rdc.toshiba.co.jp>
Subject: Re: Ordering of % and / in RFC 4007 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


> >> The code below would be straightforward if the "/64" prefix were 
> >> accepted by getaddrinfo.
> >> 
> >> Besides, I don't think the textual representation should be defined
> to 
> >> make only Basic Socket API functions straightforward.  IMHO, the
> order 
> >> should be logical on its own.  The prefix is clearly more tightly 
> >> related to the IP address (in6_addr) and the scope zone index is 
> >> clearly (by virtual of the fact that scope_id is in sockaddr_in6) 
> >> related to the transport address.  So the textual representation as
> it 
> >> stands now mixes IP address and Transport address information.
> >> 
> >> --Stephen
> >
> >	No they are both properties that can be associated with a
> >	address.  If anything the scope ties closer than the prefix
> >	as a link-local address or prefix is meanless w/o the scope.
>
> I'm not sure what you mean by "address" above.  My argument is that the
> prefix is associated with IP addresses (represented by struct in6_addr
> in the API) and the scope is associated with transport addresses
> (represented by struct sockaddr_in6 in the API).  They are both
> "addresses", but they are different layer addresses.  If I map what
> textual representation to what data structure it has effect on:
> 	[ipaddr%scope/prefix]:port is mapped into
> [in6_addr%sockaddr_in6/in6_addr]:sockaddr_in6
> >From my view the the textual representation and the Basic socket API
> structures are inconsistent. 

	You are assuming you can have a prefix without a scope.  This is
	a false assumption.  All prefixes have scope even if it is only
	global scope.

> >	Mark
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 21:11:09 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27912
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 21:11:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK4Ri-00062i-Qg; Fri, 08 Apr 2005 21:07:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4Qy-0005nQ-D8
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 21:06:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27322
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 21:06:47 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DK4Zo-0000Cm-9t
	for ipv6@ietf.org; Fri, 08 Apr 2005 21:15:58 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-1.cisco.com with ESMTP; 08 Apr 2005 18:06:37 -0700
X-IronPort-AV: i="3.92,90,1112598000"; 
	d="scan'208"; a="627098319:sNHT35696396"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3916WDr004302;
	Fri, 8 Apr 2005 18:06:32 -0700 (PDT)
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com
	[10.32.244.218])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j390wIrR004471;
	Fri, 8 Apr 2005 17:58:18 -0700
In-Reply-To: <42571A8C.5080203@sun.com>
References: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
	<38eddbd55b0134c3497b8e4c09b41e2a@cisco.com>
	<42571A8C.5080203@sun.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b9e1874ceaded02e271ff1d33ffa62dc@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Fri, 8 Apr 2005 18:06:32 -0700
To: Erik Nordmark <erik.nordmark@sun.com>
X-Mailer: Apple Mail (2.619.2)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113008298.677788"; x:"432200"; a:"rsa-sha1"; b:"nofws:258";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"WBOuYV+y6Rw61tVrdtpJoYeyTZfF0iVZAvUOnU1Nv5AbxMNhKpoAMvs0y4hx/VOgYbHmRyBf"
	"IsvMZV8Eric9tzG+fgrE2DzttAfp26QBWHTFu+JorYB0LxUELyC6JOljJ76cdGyl0IgZCVE8q1E"
	"eGMckkwBlrXTu8Fc3QOGbkV0="; c:"From: Fred Baker <fred@cisco.com>";
	c:"Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt";
	c:"Date: Fri, 8 Apr 2005 18:06:32 -0700"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote:

> Applying IPsec doesn't help solve the authorization issue of who 
> should be allowed to receive packets sent to a particular anycast 
> address.

Can you tell me any address or type of address for which that is an 
objective either of internet routing or addressing?

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr  8 21:41:51 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29167
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 21:41:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK4xV-0004Wb-A3; Fri, 08 Apr 2005 21:40:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4xT-0004WW-Cb
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 21:40:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29101
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 21:40:21 -0400 (EDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK56L-0001bZ-Fc
	for ipv6@ietf.org; Fri, 08 Apr 2005 21:49:33 -0400
Received: from jurassic.eng.sun.com ([129.146.17.57])
	by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j391dFJx017955; 
	Fri, 8 Apr 2005 18:39:15 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11])
	by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id
	j391dEr0823994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Apr 2005 18:39:15 -0700 (PDT)
Message-ID: <42573231.8090504@sun.com>
Date: Fri, 08 Apr 2005 18:38:57 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com>
	<38eddbd55b0134c3497b8e4c09b41e2a@cisco.com>
	<42571A8C.5080203@sun.com>
	<b9e1874ceaded02e271ff1d33ffa62dc@cisco.com>
In-Reply-To: <b9e1874ceaded02e271ff1d33ffa62dc@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Fred Baker wrote:
> 
> On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote:
> 
>> Applying IPsec doesn't help solve the authorization issue of who 
>> should be allowed to receive packets sent to a particular anycast 
>> address.
> 
> 
> Can you tell me any address or type of address for which that is an 
> objective either of internet routing or addressing?

I guess I don't understand the question.

The way I use "authorize" in this context is best shown in this example:
For regular unicast, the fact the my ISP has assigned a /29 to me, and 
inserted that in their routing tables manually, means that the DSL line 
to my house is authorized to receive packets addressed to that address 
prefix.

This coupled with trust in the ISPs that run BGP (but not necessarily 
much security) we are pretty confident that packets sent to one of 
google's IP address in fact get routed to one of google's machines (or 
dropped under overload).

Enter anycast. If we try to design a protocol mechanism by which any 
host can say "send me packets for this anycast address" and with anycast 
addresses being syntactically indistinguishable from unicast, what would 
prevent my laptop from saying it wants to receive packets addressed to 
one of google's unicast address?

Thus my point is that any grand unified approach to anycast needs to 
think about the authorization issues.

Of course, this isn't a problem in the way IPv4 anycast is used for DNS, 
because there is manual configuration hence implicit authorization of 
which DNS servers are part of the anycast sets.

    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 Apr  8 22:05:59 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00654
	for <ipngwg-archive@lists.ietf.org>; Fri, 8 Apr 2005 22:05:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DK5IN-0000zv-J9; Fri, 08 Apr 2005 22:01:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DK5IL-0000zq-8a
	for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 22:01:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00418
	for <ipv6@ietf.org>; Fri, 8 Apr 2005 22:01:55 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5RC-0002UF-FF
	for ipv6@ietf.org; Fri, 08 Apr 2005 22:11:07 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net
	[IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net",
	Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id 8FCC31C5
	for <ipv6@ietf.org>; Fri,  8 Apr 2005 22:01:44 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id D234F41EA
	for <ipv6@ietf.org>; Fri,  8 Apr 2005 22:01:43 -0400 (EDT)
Date: Fri, 08 Apr 2005 22:01:43 -0400
From: Rob Austein <sra@isc.org>
To: IPv6 WG <ipv6@ietf.org>
In-Reply-To: <42571952.40708@sun.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
	<53d287f38cdaf4d20dda471b03eb4e1e@isc.org>
	<06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com>
	<42571952.40708@sun.com>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050409020143.D234F41EA@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Fri, 08 Apr 2005 16:52:50 -0700, Erik Nordmark wrote:
> 
> 1. Add text to say "SHOULD limit packets with an anycast source to 1280
>     bytes". Add note that ICMP-based tools don't work with an anycast
>     source address.

Unless, of course, the application protocol in question happens to be
one of those for which, after all these years of trying to relegate IP
fragmentation to the dustbin of history, we still have no better
transport protocol than UDP without path MTU discovery, and if that
means that we have to send fragments, so be it, we send fragments.

Yes, there are such protocols, and yes, at least one of them is being
used today with anycast source addresses.

It's not that fragmented UDP without path MTU discovery is good.  It's
just that sometimes all the other alternatives are even worse.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From BarbaraHendricks@soundwavesound.org  Sat Apr  9 04:11: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 EAA17214;
	Sat, 9 Apr 2005 04:11:12 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DKBCX-0002dO-7U; Sat, 09 Apr 2005 04:20:27 -0400
Received: from [221.161.176.227] (helo=65.246.255.50)
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1DKB3X-0005Ec-Kf; Sat, 09 Apr 2005 04:11:04 -0400
Received: from aLFs@localhost by meNu.int (8.11.6/8.11.6); Sat, 09 Apr 2005 02:05:24 -0700
Message-ID: <KdF9eY2x0i9Yohmsq8Up6@art-omma.org>
From: "Sally Brantley" <BarbaraHendricks@soundwavesound.org>
Reply-To: "Sally Brantley" <BarbaraHendricks@soundwavesound.org>
To: nsis@ietf.org, ipngwg-archive@ietf.org, sigtran@ietf.org,
        nemo-admin@ietf.org
Subject: Re: OEM XP, Symantec, & Windows XP on Sale Now
Date: Sat, 09 Apr 2005 02:03:24 -0700
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2
X-Sender: BarbaraHendricks@soundwavesound.org
Content-Type: multipart/mixed;  boundary="--ynSEBlgJFAPZpgNj"
X-Spam-Score: 7.9 (+++++++)
X-Spam-Flag: YES
X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd

RDY 

----ynSEBlgJFAPZpgNj
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3D"Content-Language" content=3D"en-us">
<meta name=3D"WdDV" content=3D"HBwh">
<meta name=3D"ProgId" content=3D"LfM9">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<title>5229456</title>
</head>

<body>

<table border=3D"1" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#003399" width=3D"676" id=3D"AutoNumber1"=
 height=3D"22">
  <tr>
    <td width=3D"118" height=3D"22" align=3D"center" bgcolor=3D"#003399">
    <font face=3D"Arial" size=3D"2" color=3D"#FFFFFF"><b>
    <a style=3D"color: #FFFFFF; text-decoration: none" href=3D"http://supe=
rhrunsoft.com/?h">
    Browse</a></b></font></td>
    <td width=3D"118" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://superhrunsoft.com/?m" style=3D"text-decoration: none=
">
    <font color=3D"#000000">Search</font></a></b></font></td>
    <td width=3D"119" height=3D"22" align=3D"center"><b><font face=3D"Aria=
l" size=3D"2">
    <a href=3D"http://superhrunsoft.com/?l" style=3D"text-decoration: none=
">
    <font color=3D"#000000">Shop</font></a></font></b></td>
    <td width=3D"119" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://superhrunsoft.com/?Y" style=3D"text-decoration: none=
">
    <font color=3D"#000000">My eSoft</font></a></b></font></td>
    <td width=3D"151" height=3D"22" align=3D"center"><font face=3D"Arial" =
size=3D"2"><b>
    <a href=3D"http://superhrunsoft.com/?8" style=3D"text-decoration: none=
">
    <font color=3D"#000000">Community</font></a></b></font></td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#111111" width=3D"677" id=3D"AutoNumber2"=
 height=3D"34">
  <tr>
    <td width=3D"194" height=3D"34"><font face=3D"Arial">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/viewitem/backArrow_14x1=
4.gif" width=3D"14" height=3D"14">
    <font size=3D"2"><a href=3D"http://superhrunsoft.com/?t">Back to Softw=
are Overview</a></font></font></td>
    <td width=3D"439" height=3D"34">
    <p align=3D"center"><font face=3D"Arial"><font size=3D"1">
    <a href=3D"http://superhrunsoft.com/?y">Home</a> &gt;
    <a href=3D"http://superhrunsoft.com/?T">All Categories</a> &gt;
    <a href=3D"http://superhrunsoft.com/?k">Computers</a> &gt;
    <a href=3D"http://superhrunsoft.com/?3">Software</a> &gt;
    <a href=3D"http://superhrunsoft.com/?c">Operating Systems</a> &gt; </f=
ont><b>
    <font size=3D"1">Windows</font></b></font></p>
    </td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#111111" width=3D"678" id=3D"AutoNumber3"=
 height=3D"1">
  <tr>
    <td height=3D"1" width=3D"6">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_first=
Dark_6x29.gif" width=3D"6" height=3D"25"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"157" bgcolor=3D"#ffc=
c00" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" border=3D"0"=
 summary height=3D"13">
      <tr>
        <td bgcolor=3D"#f7f7f7" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#e6e6e6" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#d6d6d6" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#ffcc00" height=3D"1"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#ffe682" height=3D"1"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle" height=3D"13">
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2"><b=
>All Items</b></font></td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"14">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_midDa=
rkOnLight_14x29.gif" width=3D"14" height=3D"25"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"174" bgcolor=3D"#FFE=
682" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" border=3D"0"=
 summary>
      <tr>
        <td bgcolor=3D"#F7F7F7"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#E6E6E6"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#D6D6D6"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFCC00"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFE682"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle">
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2"><b=
>
        <a href=3D"http://superhrunsoft.com/?L">Auctions</a></b></font></t=
d>
      </tr>
      <tr>
        <td></td>
      </tr>
      <tr>
        <td valign=3D"bottom">
        <table height=3D"2" cellspacing=3D"0" cellpadding=3D"0" width=3D"1=
00%" border=3D"0" valign=3D"bottom" summary>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#EFD778" height=3D"1"></td>
          </tr>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#D4BF6A" height=3D"1"></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"14">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_midLi=
ghtLight_14x29.gif" width=3D"14" height=3D"23"></td>
    <td valign=3D"top" nowrap align=3D"left" width=3D"176" bgcolor=3D"#FFE=
682" height=3D"1">
    <table cellspacing=3D"0" cellpadding=3D"0" width=3D"55" border=3D"0" s=
ummary>
      <tr>
        <td bgcolor=3D"#F7F7F7" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#E6E6E6" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#D6D6D6" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFCC00" width=3D"175"></td>
      </tr>
      <tr>
        <td bgcolor=3D"#FFE682" width=3D"175"></td>
      </tr>
      <tr>
        <td nowrap align=3D"middle" width=3D"175">
        <a href=3D"http://superhrunsoft.com/?P"><b>
        <font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D"2">Bu=
y</font></b></a><font face=3D"Arial, Verdana, Helvetica, Sans-Serif" size=3D=
"2"><b><a href=3D"http://superhrunsoft.com/?2"> 
        It Now</a></b></font></td>
      </tr>
      <tr>
        <td width=3D"175"></td>
      </tr>
      <tr>
        <td valign=3D"bottom" width=3D"175">
        <table height=3D"2" cellspacing=3D"0" cellpadding=3D"0" width=3D"1=
00%" border=3D"0" valign=3D"bottom" summary>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#EFD778" height=3D"1"></td>
          </tr>
          <tr>
            <td valign=3D"bottom" bgcolor=3D"#D4BF6A" height=3D"1"></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
    <td height=3D"1" width=3D"137">
    <img src=3D"http://pics.ebaystatic.com/aw/pics/listings/allitems_endLi=
ghtTab_14x29.gif" width=3D"14" height=3D"23"></td>
  </tr>
</table>
<table width=3D"582" bgcolor=3D"#FFFFFF" border=3D"0" cellpadding=3D"0" ce=
llspacing=3D"0" style=3D"border-collapse: collapse" bordercolor=3D"#111111=
">
  <tr>
    <td bgcolor=3D"#FFCC00" width=3D"1"><font face=3D"Arial" size=3D"2">
    <img height=3D"1" src=3D"http://pics.ebaystatic.com/aw/pics/s.gif" wid=
th=3D"1"></font></td>
    <td width=3D"598">
    <table border=3D"1" bgcolor=3D"#FFFFCC" width=3D"676" cellpadding=3D"0=
" cellspacing=3D"0" style=3D"border-collapse: collapse" bordercolor=3D"#FF=
CC00" height=3D"52">
      <tr>
        <td valign=3D"middle" nowrap width=3D"627" height=3D"52"><font fac=
e=3D"Arial">&nbsp;&nbsp;&nbsp;
        <input type=3D"text" name=3D"satitle" size=3D"43" maxlength=3D"300=
" value><font size=3D"2">
        </font><select name=3D"sacategory">
        <option selected>Windows</option>
        <option>Adobe</option>
        <option>Macromedia</option>
        </select><font size=3D"2"> </font><a href=3D"http://superhrunsoft.=
com/?l">
        <input type=3D"button" name=3D"bs" value=3D"Search" onclick></a><f=
ont size=3D"2">
        </font></font><span class=3D"navigation"><font size=3D"2" face=3D"=
Arial">
        <a class href=3D"http://superhrunsoft.com/?P">Refine Search</a></f=
ont></span></td>
      </tr>
    </table>
    </td>
  </tr>
</table>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-co=
llapse: collapse" bordercolor=3D"#CCCCCC" width=3D"676" id=3D"AutoNumber4"=
 height=3D"234">
  <tr>
    <td width=3D"134" height=3D"234" rowspan=3D"6">
    <table border=3D"1" cellpadding=3D"2" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#FFCC00" width=3D"100%" id=3D"AutoNum=
ber5" height=3D"423" bgcolor=3D"#FFFFCC">
      <tr>
        <td width=3D"100%" height=3D"10" bgcolor=3D"#FFE682">&nbsp;<b><fon=
t face=3D"Arial" size=3D"2">Top 
        Sellers</font></b></td>
      </tr>
      <tr>
        <td width=3D"100%" height=3D"413" valign=3D"top"><font face=3D"Ari=
al" size=3D"1">1&nbsp;&nbsp;
        <a href=3D"http://superhrunsoft.com/?Z" style=3D"text-decoration: =
none">Windows 
        XP Pro</a><br>
        2&nbsp;&nbsp;
        <a href=3D"http://superhrunsoft.com/?f" style=3D"text-decoration: =
none">Office 
        XP 2002 Pro</a><br>
        3&nbsp;&nbsp;
        <a href=3D"http://superhrunsoft.com/?3" style=3D"text-decoration: =
none">Adobe 
        Acrobat<br>
&nbsp;&nbsp;&nbsp;&nbsp; 7.0 Professional</a><br>
        4&nbsp;&nbsp;
        <a href=3D"http://superhrunsoft.com/?D" style=3D"text-decoration: =
none">Adobe 
        Photoshop<br>
&nbsp;&nbsp;&nbsp;&nbsp; CS 8.0</a><br>
        5<a href=3D"http://superhrunsoft.com/?m" style=3D"text-decoration:=
 none">&nbsp;&nbsp; 
        Office 2003 Pro&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </a><br>
        6&nbsp;&nbsp;
        <a style=3D"text-decoration: none" href=3D"http://superhrunsoft.co=
m/?R">Macromedia<br>
&nbsp;&nbsp;&nbsp;&nbsp; Dream Weaver<br>
&nbsp;&nbsp;&nbsp;&nbsp; MX 2004</a><br>
        <a href=3D"http://superhrunsoft.com/?L" style=3D"text-decoration: =
none">
        <font color=3D"#000000">7</font></a>
        <a href=3D"http://superhrunsoft.com/?I" style=3D"text-decoration: =
none">
        <font color=3D"#000000">&nbsp;</font></a>
        <a href=3D"http://superhrunsoft.com/?M" style=3D"text-decoration: =
none">Macromedia 
        Flash<br>
&nbsp;&nbsp;&nbsp;&nbsp; MX 2004 Pro</a><br>
        8&nbsp;&nbsp;
        <a href=3D"http://superhrunsoft.com/?i" style=3D"text-decoration: =
none">MS 
        2003 Server<br>
&nbsp;&nbsp;&nbsp;&nbsp; (Enterprise Edition)</a><br>
        9&nbsp;&nbsp;
        <a href=3D"http://superhrunsoft.com/?C" style=3D"text-decoration: =
none">Norton 
        Antivirus 2005</a><br>
        10 <a href=3D"http://superhrunsoft.com/?G" style=3D"text-decoratio=
n: none">
        CorelDraw<br>
&nbsp;&nbsp;&nbsp;&nbsp; Graphics Suite 12.0<br>
        </a>11
        <a href=3D"http://superhrunsoft.com/?Q" style=3D"text-decoration: =
none">Adobe 
        Creative Suite<br>
&nbsp;&nbsp;&nbsp;&nbsp; Premium</a><br>
        12 <a href=3D"http://superhrunsoft.com/?e" style=3D"text-decoratio=
n: none">
        Alias Wavefront
        <br</a>6.0<br>
        <font color=3D"#000000">13</font>
        <br</a></a>
        <br</a>
        <a href=3D"http://superhrunsoft.com/?k" style=3D"text-decoration: =
none">Adobe 
        Primer<br>
        </a>14
        <a href=3D"http://superhrunsoft.com/?z" style=3D"text-decoration: =
none">AutoDesk 
        3d Studio<br>
&nbsp;&nbsp;&nbsp;&nbsp; MAX v6.0</a><br>
        15 <a href=3D"http://superhrunsoft.com/?2" style=3D"text-decoratio=
n: none">
        Adobe </a></font>
        <br</a>
        <a href=3D"http://superhrunsoft.com/?9" style=3D"text-decoration: =
none">
        <font face=3D"Arial" size=3D"1">Encore DVD</font></a><br</a></td>
      </tr>
    </table>
    <p>&nbsp;</p>
    <p>&nbsp;</p>
    </td>
    <td width=3D"542" height=3D"18" bgcolor=3D"#D6D6D6" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber6" bgcolor=3D"#E6E6E6">
      <tr>
        <td width=3D"58%" bgcolor=3D"#E6E6E6" align=3D"center">
        <p align=3D"center"><b><font face=3D"Arial" size=3D"2">Featured It=
em</font></b></p>
        </td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">PRlCE</font></b></td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">Bids</font></b></td>
        <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" size=3D=
"2">Time Left</font></b></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"97" height=3D"95">
    <p align=3D"center">
    <img border=3D"0" src=3D"http://www.tails.nl/images/xppro.jpg" width=3D=
"101" height=3D"120" align=3D"left"></p>
    </td>
    <td width=3D"214" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2">
    <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/aw/pi=
cs/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
    <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?I">&nbsp;Micro=
soft Windows 
    XP PRO<br>
    -Current Edition-</a><br>
    <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?L"><br>
    </a></font><font face=3D"Arial" size=3D"1">
    <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?I">
    <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://pics.=
ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=3D"=
10"></a> 
    from Our eStore</font></p>
    </td>
    <td width=3D"74" height=3D"95">
    <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$49.95</b>
    <font color=3D"#999999">USD</font></font></p>
    </td>
    <td width=3D"79" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2">4<a target=3D"help=
win" href=3D"http://superhrunsoft.com/?7"><br>
    <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://pics.=
ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=3D"=
15"></a></font></p>
    </td>
    <td width=3D"78" height=3D"95">
    <p align=3D"center"><font face=3D"Arial" size=3D"2" color=3D"#660066">=
<nobr>0h 14m</nobr></font></p>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"20" colspan=3D"5" bgcolor=3D"#D6D6D6">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber7" bgcolor=3D"#E6E6E6">
      <tr>
        <td width=3D"80%">
        <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"b=
order-collapse: collapse" bordercolor=3D"#111111" width=3D"100=
%">
          <tr>
            <td width=3D"57%" bgcolor=3D"#E6E6E6" align=3D"center" borderc=
olor=3D"#FFFFFF">
            <p align=3D"center"><b><font face=3D"Arial" size=3D"2">Nevv It=
ems</font></b></p>
            </td>
            <td width=3D"15%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">PRlCE</font></b></td>
            <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">Bids</font></b></td>
            <td width=3D"14%" align=3D"center"><b><font face=3D"Arial" siz=
e=3D"2">Time Left</font></b></td>
          </tr>
        </table>
        </td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"45" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber8" height=3D"97">
      <tr>
        <td width=3D"12%" height=3D"97">
        <p align=3D"center">
        <img border=3D"0" src=3D"http://www.imj.co.jp/g-coop/syohin/img/Of=
fice2003.gif" align=3D"left" width=3D"102" height=3D"129"></p>
        </td>
        <td width=3D"25%" height=3D"97">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?7">&nbsp;M=
icrosoft 
        Office 2003 PRO or<br>
        Microsoft Office XP PRO</a><br>
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?x"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?f">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"9%" height=3D"97" align=3D"center">
        <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$49.95</b>
        <font color=3D"#999999">USD</font></font></p>
        </td>
        <td width=3D"9%" height=3D"97">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">9<a target=3D"=
helpwin" href=3D"http://superhrunsoft.com/?f"><br>
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></p>
        </td>
        <td width=3D"9%" height=3D"97" align=3D"center"><font face=3D"Aria=
l" size=3D"2">0h 14m</font></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"70" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber9" height=3D"99">
      <tr>
        <td width=3D"15%" height=3D"99">
        <img border=3D"0" src=3D"http://www.re-solution.de/img/photoshopcs=
gif" width=3D"103" height=3D"106" align=3D"left"></td>
        <td width=3D"29%" height=3D"99">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?h">&nbsp;A=
dobe Photoshop 
        CS 8.0 or Adobe Acrobat PRO 7.0</a><br>
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?e"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?w">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"11%" height=3D"99" align=3D"center">
        <p align=3D"center"><font size=3D"2" face=3D"Arial"><b>$59.95</b>
        <font color=3D"#999999">USD</font></font></p>
        </td>
        <td width=3D"11%" height=3D"99" align=3D"center"><font face=3D"Ari=
al" size=3D"2">3<a target=3D"helpwin" href=3D"http://superhrunsoft.com/?t"=
><br>
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></td>
        <td width=3D"10%" height=3D"99" align=3D"center"><font face=3D"Ari=
al" size=3D"2">
        0h 14m</font></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width=3D"542" height=3D"32" colspan=3D"5">
    <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"borde=
r-collapse: collapse" bordercolor=3D"#111111" width=3D"100%" id=3D"AutoNum=
ber10" height=3D"70">
      <tr>
        <td width=3D"15%" height=3D"70">
        <img border=3D"0" src=3D"http://www.hyperpc.co.jp/shozai/soft/flas=
hmxpro2004.jpg" width=3D"113" height=3D"95"></td>
        <td width=3D"30%" height=3D"70">
        <p align=3D"center"><font face=3D"Arial" size=3D"2">
        <img title=3D"New" alt=3D"New" src=3D"http://pics.ebaystatic.com/a=
w/pics/icon/iconNew_16x16.gif" border=3D"0" width=3D"16" height=3D"15">
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?n">&nbsp;M=
acromedia 
        FlashMX Pro 2004 or Macromedia Dreamweaver MX Pro 2004</a><br>
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?0"><br>
        </a></font><font face=3D"Arial" size=3D"1">
        <a target=3D"helpwin" href=3D"http://superhrunsoft.com/?Y">
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"10"></a> 
        from Our eStore</font></p>
        </td>
        <td width=3D"11%" height=3D"70" align=3D"center"><font size=3D"2" =
face=3D"Arial">
        <b>$39.95</b> <font color=3D"#999999">USD</font></font></td>
        <td width=3D"11%" height=3D"70" align=3D"center"><font face=3D"Ari=
al" size=3D"2">5<a target=3D"helpwin" href=3D"http://superhrunsoft.com/?Y"=
><br>
        <img title=3D"Gift Services" alt=3D"Gift Services" src=3D"http://p=
ics.ebaystatic.com/aw/pics/bin_15x54.gif" border=3D"0" width=3D"54" height=
=3D"15"></a></font></td>
        <td width=3D"10%" height=3D"70" align=3D"center"><font face=3D"Ari=
al" size=3D"2">
        0h 13m</font></td>
      </tr>
    </table>
    </td>
  </tr>
</table>

</body>

</html>

----ynSEBlgJFAPZpgNj--


From sprout@yebox.com  Sat Apr  9 06:59: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 GAA26296;
	Sat, 9 Apr 2005 06:59:51 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DKDpr-0001kA-ON; Sat, 09 Apr 2005 07:09:09 -0400
Received: from [62.5.210.226] (helo=SERVER)
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1DKDgs-0000q5-W3; Sat, 09 Apr 2005 06:59:51 -0400
Delivered-To: cattleman@twigging.dreamhost.com
Received: from dessert.dreamhost.com by pound.dreamhost.com (Pingofix) with ESMTP id 9CC4A39D6B
        for <lista-ipngwg-archive@ietf.org>;
        Sat, 09 Apr 2005 13:55:03 +0200
Message-ID: <BKELLDAGKABIOCHDFD107DGAA.dannipngwg-archive@ietf.org>
Date: Sat, 09 Apr 2005 16:51:03 +0500
From: "Leona Rhoades" <sprout@yebox.com>
To: <ipngwg-archive@ietf.org>
Subject: Notification: We offer low rates
X-Mailer: Mailman v2.0.6
X-SpamTest-Info: Profile: Formal (167/041174)
X-SpamTest-Info: Profile: Detect Hard No RBL (4/030565)
X-Spam-Score: 12.0 (++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.3-m-n.net/sign.asp



 Best Regards,

 Kennith Cowan
 
 to be remov(ed:	http://www.3-m-n.net/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Sun Apr 10 00:03:23 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28239
	for <ipngwg-archive@lists.ietf.org>; Sun, 10 Apr 2005 00:03:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKTcq-0005gb-Rv; Sun, 10 Apr 2005 00:00:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DKTco-0005gU-Pp
	for ipv6@megatron.ietf.org; Sun, 10 Apr 2005 00:00:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28123
	for <ipv6@ietf.org>; Sun, 10 Apr 2005 00:00:40 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKTlu-0006P0-IE
	for ipv6@ietf.org; Sun, 10 Apr 2005 00:10:06 -0400
Received: from hactrn.net (localhost [127.0.0.1])
	by cyteen.hactrn.net (Postfix) with ESMTP id 2145F77F
	for <ipv6@ietf.org>; Sun, 10 Apr 2005 00:00:29 -0400 (EDT)
To: ipv6@ietf.org
From: Rob Austein <sra+ipng@hactrn.net>
Date: Sun, 10 Apr 2005 00:00:29 -0400
Message-Id: <20050410040029.2145F77F@cyteen.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 12.50% |    9 | 12.49% |    46104 | fred@cisco.com
  9.72% |    7 |  9.59% |    35401 | mark_andrews@isc.org
  9.72% |    7 |  9.04% |    33381 | jabley@isc.org
  5.56% |    4 | 10.45% |    38585 | brian@innovationslab.net
  6.94% |    5 |  6.19% |    22865 | jinmei@isl.rdc.toshiba.co.jp
  5.56% |    4 |  5.46% |    20163 | scipolli@radvision.com
  5.56% |    4 |  4.80% |    17723 | erik.nordmark@sun.com
  5.56% |    4 |  4.67% |    17239 | pekkas@netcore.fi
  4.17% |    3 |  3.86% |    14247 | kempf@docomolabs-usa.com
  4.17% |    3 |  3.49% |    12899 | sra@isc.org
  4.17% |    3 |  3.30% |    12194 | fenner@research.att.com
  2.78% |    2 |  3.57% |    13175 | elwynd@dial.pipex.com
  2.78% |    2 |  2.70% |     9967 | narten@us.ibm.com
  2.78% |    2 |  2.40% |     8844 | fernando@gont.com.ar
  2.78% |    2 |  1.71% |     6319 | kck@netcom.com
  1.39% |    1 |  2.96% |    10937 | adamson@us.ibm.com
  1.39% |    1 |  1.79% |     6622 | internet-drafts@ietf.org
  1.39% |    1 |  1.69% |     6232 | dmm@1-4-5.net
  1.39% |    1 |  1.57% |     5794 | nwnetworks@dial.pipex.com
  1.39% |    1 |  1.39% |     5127 | john.loughney@nokia.com
  1.39% |    1 |  1.36% |     5033 | perry@coders.net
  1.39% |    1 |  1.25% |     4600 | peder.chr.norgaard@ericsson.com
  1.39% |    1 |  1.24% |     4580 | sra+ipng@hactrn.net
  1.39% |    1 |  1.10% |     4065 | albert.e.manfredi@boeing.com
  1.39% |    1 |  1.09% |     4035 | suresh.krishnan@ericsson.ca
  1.39% |    1 |  0.84% |     3107 | iesg-secretary@ietf.org
--------+------+--------+----------+------------------------
100.00% |   72 |100.00% |   369238 | 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 gresham@doramail.com  Sun Apr 10 03:18: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 DAA28651;
	Sun, 10 Apr 2005 03:18:19 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DKWrA-0006km-VM; Sun, 10 Apr 2005 03:27:46 -0400
Received: from [220.116.203.26] (helo=65.246.255.50)
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1DKWhz-0005lG-7y; Sun, 10 Apr 2005 03:18:16 -0400
Delivered-To: alderman@congestive.dreamhost.com
Received: from danbury.dreamhost.com by southernmost.dreamhost.com (Pingofix) with ESMTP id 1CC3A62D9B
        for <lista-ipngwg-archive@ietf.org>;
        Sun, 10 Apr 2005 03:13:22 -0500
Message-ID: <BKELLDAGKABIOCHDFD111DGAA.dannipngwg-archive@ietf.org>
Date: Sun, 10 Apr 2005 13:10:22 +0500
From: "Shawna Sanford" <gresham@doramail.com>
To: <ipngwg-archive@ietf.org>
Subject: Approved mortage rate
X-Mailer: Mailman v2.0.7
X-SpamTest-Info: Profile: Formal (167/041194)
X-SpamTest-Info: Profile: Detect Hard No RBL (4/030542)
X-Spam-Score: 8.1 (++++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.3-m-n.net/sign.asp



 Best Regards,

 Dwight Hanks
 
 to be remov(ed:	http://www.3-m-n.net/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Sun Apr 10 13:19:23 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03669
	for <ipngwg-archive@lists.ietf.org>; Sun, 10 Apr 2005 13:19:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKg3L-0002Mg-B2; Sun, 10 Apr 2005 13:16:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKfxQ-0001X4-MI; Sun, 10 Apr 2005 13:10:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02749;
	Sun, 10 Apr 2005 13:10:45 -0400 (EDT)
Received: from virtua-cwb212-198.ctb.virtua.com.br ([200.250.212.198])
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DKg6b-00069I-Ni; Sun, 10 Apr 2005 13:20:19 -0400
X-Message-Info: 152hlfQNJwTU5SqiJ759SAE1YxisYcdwqGIdvtRd636UVY
Received: from lycos.co.uk (222.16.203.232) by lb935-pye78.lycos.co.uk with
	Microsoft SMTPSVC(0.7.1616.1412); Sun, 10 Apr 2005 16:04:32 -0200
Received: from lycos.co.uk (lycos.co.uk 20.108.68.21)
	by lycos.co.uk (8.12.10/8.12.9) with ESMTP id iyo4NEYV687
	for <ips@ietf.org>; Sun, 10 Apr 2005 23:06:32 +0500 (EST)
	(envelope-from xyyrdvdwytcm@swbell.net)
Received: from JGV804581783989 (modemcable3.294-331.e.lycos.co.uk
	180.208.221.144) (authenticated bits=2)
	by lycos.co.uk (8.12.10/8.12.9) with ESMTP id xxc274MIH32tw386
	for <ips@ietf.org>; Sun, 10 Apr 2005 15:03:32 -0300 (EST)
	(envelope-from xyyrdvdwytcm@swbell.net)
Message-ID: <91538eu76tkf46$lmy78s3ru8$336q602p8@ZYF57866236551112>
From: "Velma Hastings" <xyyrdvdwytcm@swbell.net>
To: <Ips@ietf.org>
Date: Sun, 10 Apr 2005 13:03:32 -0500
MIME-Version: 1.0
X-Spam-Score: 4.8 (++++)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
X-Mailman-Approved-At: Sun, 10 Apr 2005 13:16:54 -0400
Subject: uExttander is here now! Do not waise your time alvin
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0213340997=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

--===============0213340997==
Content-Type: multipart/alternative;
	boundary="--wbytisr876382393wsqdlis"

----wbytisr876382393wsqdlis
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

New... and improved: exxtand your tool now!
simple, safe, quick ! a few minutes and you got yourself a hugge tool, 
with permenent reasults and no surgary needed.
you'll get tired of scrrewing, for sure :)
come take a look now!

The new, bast Extandder online website!
http://ruddy.j5k.net/ext/erika/cannabis.htm  


and now for the second round judging feature the entire blog again in alphabetical order it is strictly due to the grace of nick that i am in this position of esteemed judge.
-nizar sakhnini board member near east cultural and educational foundation of canada toronto ontario canada.
there is a war for sure going on but it is a war against good and evil it boils down to being a war against our god by what ever name we call him the creator of all heaven and earth.
el zurdo eleazar mora abri oacute por los porte ntilde os hasta completar siete y un tercio aunque el rev eacute s lo sufri oacute el relevista erubiel gonz aacute lez.
bon souvenir agrave montr eacute al j ai ammen eacute me s trois filles elles l ont tous trouv eacute e super nous sommes autochtones mekwetc!
the chinese year result is written in the day month year format in the year cycle format followed by the stem-branch format in its chinese name english equivalent.
for best results ayres recommends that clam enthusiasts start digging at least one hour before low tide.
quot un triunfo m aacute s significa una medalla y creo que vamos a lucharla quot indic oacute cano.
it was fully a week before the satellite tv dragooned that no dish network were appearing at dusk in the dish network of the cottage under the dish network.
ben you can drink your fansy ales you can drink them by the flagin but the only brew that is good and true comes from the green dragon!
i would like to see films with orlando and kate hudson because they look like a great couple thats why not kates bosworth i don t know why.
power is the ability to define reality and to have other people respond to your definition as if it is their own.
places to fish are the docks around the madrona and leschi areas mount baker seward park and gene coulon park in renton.


----wbytisr876382393wsqdlis--



--===============0213340997==
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
--------------------------------------------------------------------

--===============0213340997==--




From ipv6-bounces@ietf.org  Sun Apr 10 21:01:11 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08926
	for <ipngwg-archive@lists.ietf.org>; Sun, 10 Apr 2005 21:01:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKnFQ-0002vu-0r; Sun, 10 Apr 2005 20:57:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DKnFO-0002vk-RX
	for ipv6@megatron.ietf.org; Sun, 10 Apr 2005 20:57:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08751
	for <ipv6@ietf.org>; Sun, 10 Apr 2005 20:57:48 -0400 (EDT)
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 1DKnOe-0004qO-HU
	for ipv6@ietf.org; Sun, 10 Apr 2005 21:07:26 -0400
Message-ID: <005301c53e31$a1cb6bf0$636015ac@dcml.docomolabsusa.com>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Fred Baker" <fred@cisco.com>, "Erik Nordmark" <erik.nordmark@sun.com>
References: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3946@xch-ne-02.ne.nos.boeing.com><38eddbd55b0134c3497b8e4c09b41e2a@cisco.com><42571A8C.5080203@sun.com>
	<b9e1874ceaded02e271ff1d33ffa62dc@cisco.com>
Date: Sun, 10 Apr 2005 17:58:47 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


> > Applying IPsec doesn't help solve the authorization issue of who
> > should be allowed to receive packets sent to a particular anycast
> > address.
>
> Can you tell me any address or type of address for which that is an
> objective either of internet routing or addressing?
>

It is possible to determine authorization to use an address with CGA. RFC
3972 describes how to construct a CGA and its security properties, RFC 3971
describes how to use them to secure the resolution of link addresses to IP
addresses in Neighbor Discovery (i.e. SEND). There is also an individual
draft that describes how to use CGAs for securing Mobile IPv6 binding
updates (grep for "OMIPv6").

            jak



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr 11 00:21:53 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18559
	for <ipngwg-archive@lists.ietf.org>; Mon, 11 Apr 2005 00:21:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKqJv-0006F9-G8; Mon, 11 Apr 2005 00:14:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DKqJt-0006F4-KC
	for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 00:14:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17797
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 00:14:37 -0400 (EDT)
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKqTA-0002of-Kz
	for ipv6@ietf.org; Mon, 11 Apr 2005 00:24:18 -0400
Received: (qmail 2968 invoked from network); 11 Apr 2005 04:12:30 -0000
Received: from 200-70-178-40.mrse.com.ar (HELO fernando.gont.com.ar)
	(gont-fernando@200.70.178.40)
	by server.frh.utn.edu.ar with SMTP; 11 Apr 2005 04:12:30 -0000
Message-Id: <4.3.2.7.2.20050411012019.04149100@server.frh.utn.edu.ar>
X-Sender: gont-fernando@server.frh.utn.edu.ar
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 11 Apr 2005 01:34:51 -0300
To: Pekka Savola <pekkas@netcore.fi>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <Pine.LNX.4.61.0504090220200.17023@netcore.fi>
References: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar>
	<4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: ipv6@ietf.org, Mukesh.K.Gupta@nokia.com
Subject: Re: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At 02:24 09/04/2005 +0300, Pekka Savola wrote:

>>I think the ICMPv6 draft should add some words to raise awareness about 
>>ICMP-based attacks that can be performed against transport protocols.
>
>Any text suggestions -- just to have an idea how verbose and explicit 
>you're looking at; did you refer to the proposed text below, or something 
>more extensive?

I referred to the text you had proposed. However, maybe a few additional 
words could be added. With the current specs, you either have IPsec, or no 
counter-measures at all. So I think the ICMP spec should say something like 
"transport protocols SHOULD use the information contained in the ICMP 
payload to validate the received ICMP messages". Probably not in the 
"Security Considerations section", but earlier in the spec.



>>>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.
>
>Yes, something like this should be added.  I thought it already was there, 
>but apparently not...

Yes, this text has not yet been added.



>>Another issue that may be worth considering is suggesting that the 
>>so-called "hard errors" should not necessarily be considered "hard". 
>>While there's no RFC 1122 for IPv6 (and thus you might say there's no 
>>such thing as "hard errors" and "soft errors" in v6), I think everyone 
>>will extrapolate RFC 1122's statements on soft and hard errors to the 
>>ICMPv6 specification.
>
>Even if I may agree with this sentiment, IMHO it seems to go too much on 
>the side of the transport protocols, and doesn't seem to be appropriate in 
>this document.  The above already a provides a pointer.

Note that I'm not saying the ICMPv6 should say whether connections should 
be aborted upon receipt of ICMP errors or not. I'm saying that maybe the 
spec could suggest what the errors being reported "mean". E.g., is a "Port 
unreachable" a soft or a hard error?
With this information, a transport-protocol designer could elaborate the 
policy of reaction to ICMP errors.

I think that part of RFC 1122 that discusses which ICMP errors are soft or 
hard is a complement to the ICMPv4 spec. Then, when RFC 1122 says "TCP 
SHOULD abort...", *that* is the transport-protocol stuff.


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr 11 02:14:14 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07156
	for <ipngwg-archive@lists.ietf.org>; Mon, 11 Apr 2005 02:14:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKs8m-0005W0-LZ; Mon, 11 Apr 2005 02:11:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DKs8j-0005Vv-Ns
	for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 02:11:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04189
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 02:11:16 -0400 (EDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKsI3-0005l8-Ja
	for ipv6@ietf.org; Mon, 11 Apr 2005 02:20:56 -0400
Received: from jurassic.eng.sun.com ([129.146.81.144])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j3B6BFrO015460; 
	Sun, 10 Apr 2005 23:11:15 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11])
	by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id
	j3B6BCq8490874
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 10 Apr 2005 23:11:15 -0700 (PDT)
Message-ID: <425A14F1.6030809@sun.com>
Date: Sun, 10 Apr 2005 23:10:57 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rob Austein <sra@isc.org>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>	<8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>	<53d287f38cdaf4d20dda471b03eb4e1e@isc.org>	<06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com>	<42571952.40708@sun.com>
	<20050409020143.D234F41EA@thrintun.hactrn.net>
In-Reply-To: <20050409020143.D234F41EA@thrintun.hactrn.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Rob Austein wrote:
> At Fri, 08 Apr 2005 16:52:50 -0700, Erik Nordmark wrote:
> 
>>1. Add text to say "SHOULD limit packets with an anycast source to 1280
>>    bytes". Add note that ICMP-based tools don't work with an anycast
>>    source address.
> 
> 
> Unless, of course, the application protocol in question happens to be
> one of those for which, after all these years of trying to relegate IP
> fragmentation to the dustbin of history, we still have no better
> transport protocol than UDP without path MTU discovery, and if that
> means that we have to send fragments, so be it, we send fragments.

That's ok, as long as no packet is larger than 1280 bytes i.e. that the 
sender fragments to 1280 bytes instead of, say, 1500.

> Yes, there are such protocols, and yes, at least one of them is being
> used today with anycast source addresses.
> 
> It's not that fragmented UDP without path MTU discovery is good.  It's
> just that sometimes all the other alternatives are even worse.

Sounds like my suggestion above needs to be clarified in that it doesn't 
prohibit fragmentation. Sending at 1280 bytes is the IPv6 way to run 
without path MTU discovery i.e. the logical counterpart of not setting 
DF in IPv4.

    Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr 11 06:42:54 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00838
	for <ipngwg-archive@lists.ietf.org>; Mon, 11 Apr 2005 06:42:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKvpu-0005T3-L3; Mon, 11 Apr 2005 06:08:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DKvhj-0004dz-SH
	for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 05:59:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16752
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 03:05:18 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKt8M-0006sw-CP
	for ipv6@ietf.org; Mon, 11 Apr 2005 03:14:58 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net
	[IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net",
	Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id 7C77727E
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 03:05:03 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id DA37C41EA
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 03:05:02 -0400 (EDT)
Date: Mon, 11 Apr 2005 03:05:02 -0400
From: Rob Austein <sra@isc.org>
To: IPv6 WG <ipv6@ietf.org>
In-Reply-To: <425A14F1.6030809@sun.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com>
	<53d287f38cdaf4d20dda471b03eb4e1e@isc.org>
	<06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com>
	<42571952.40708@sun.com>
	<20050409020143.D234F41EA@thrintun.hactrn.net>
	<425A14F1.6030809@sun.com>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050411070502.DA37C41EA@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Sun, 10 Apr 2005 23:10:57 -0700, Erik Nordmark wrote:
> 
> Sounds like my suggestion above needs to be clarified in that it doesn't 
> prohibit fragmentation.

Yep.

Probably best just to say that we don't know how to do Path MTU
discovery with anycast source address and point to the text in other
specs that explain how to handle that (eg, RFC 2460 section 5).

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Mon Apr 11 10:21:41 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16931
	for <ipngwg-archive@lists.ietf.org>; Mon, 11 Apr 2005 10:21:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKzW3-0000cb-L1; Mon, 11 Apr 2005 10:03:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzW1-0000cD-Oh
	for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 10:03:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15262
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 10:03:39 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKzfG-0000YB-Nv
	for ipv6@ietf.org; Mon, 11 Apr 2005 10:13:24 -0400
Received: from ([128.244.124.185])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10357442;
	Mon, 11 Apr 2005 10:02:56 -0400
In-Reply-To: <425716A6.7060700@sun.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Message-Id: <88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Mon, 11 Apr 2005 10:02:57 -0400
To: Erik Nordmark <erik.nordmark@sun.com>
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: 34d35111647d654d033d58d318c0d21a
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0287334143=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============0287334143==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--370492114;
	protocol="application/pkcs7-signature"


--Apple-Mail-2--370492114
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi Erik,

On Apr 8, 2005, at 19:41, Erik Nordmark wrote:

> Brian Haberman wrote:
>
>>    o  An anycast address MAY be used as the source address of an IPv6
>>        packet.
>>    o  An anycast address MAY be assigned to an IPv6 host.
>> This change will allow users to operate IPv6 anycast services in the 
>> same
>> manner in which they do today with IPv4 anycast.
>
> If we do this, shouldn't we also list the issues one needs to cope 
> with?
>
> For instance, when anycast is used as a source address, ICMP errors 
> might no longer be delivered to the sender (they might be delivered to 
> some other host that uses the same anycast address). This means that 
> ICMP path mtu discovery might not work. As a result, I think it would 
> make sense to say that when an anycast address is used as source 
> address, the sender SHOULD limit the IPv6 packets to 1280 bytes.
>
> It might also make sense to note that the lack of ICMP errors means 
> that debugging tools like ping and traceroute might not work when an 
> anycast address is used as source address.
>

I tend to think that it is worthwhile to list some of these issues in 
the spec.  These
are not intuitive problems that people will recognize without some 
guidance.

Regards,
Brian

--Apple-Mail-2--370492114
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDExMTQwMjU4WjAjBgkqhkiG9w0B
CQQxFgQUuT+JaDzCrL0BdD1eQdTvf4rkLx4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEAR9KO0yj7IuoGGMZdPRdzp6PAZ0fZeqwUONyZEQbqM7Tj8JpfQWWSqtugsd3yvO9f7cdW
5X6OTGbGniYU3DEcbxcfK3cnIh+JvDVYgAGNZR+Osx6Qus0qeI+rEel1aIsAPSfiGPVOT33VzKRE
3v1SDYoCchB+xWqSGDBlGz0UKhSUPxtKWU959ORwZyo1ukk6ikj+k++ah3VRj1CbDuk1ff31KFMg
z/2yb0lHDhJ4+8aDRTByfXV6E6/OPk8IJdRklogWHbhhb8OVZ+/SLnGPcdPsK0STTPBLytnL7KE/
GGxN1+LvA8rC634tSFEZybkPIX1/lH+s0yEp+m9gj12+UgAAAAAAAA==

--Apple-Mail-2--370492114--



--===============0287334143==
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
--------------------------------------------------------------------

--===============0287334143==--




From ipv6-bounces@ietf.org  Mon Apr 11 15:27:10 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12278
	for <ipngwg-archive@lists.ietf.org>; Mon, 11 Apr 2005 15:27:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DL475-000409-2c; Mon, 11 Apr 2005 14:58:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DL471-0003zO-JL
	for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 14:58:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08702
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 14:58:09 -0400 (EDT)
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 1DL4GK-0001Mq-6Q
	for ipv6@ietf.org; Mon, 11 Apr 2005 15:07:56 -0400
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j3BIvwr11790; Mon, 11 Apr 2005 21:57:58 +0300 (EET DST)
X-Scanned: Mon, 11 Apr 2005 21:57:50 +0300 Nokia Message Protector V1.3.34
	2004121512 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j3BIvoVN009466;
	Mon, 11 Apr 2005 21:57:50 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00MY4kZK; Mon, 11 Apr 2005 21:57:50 EEST
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
	j3BIvmM27182; Mon, 11 Apr 2005 21:57:48 +0300 (EET DST)
Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by
	daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Mon, 11 Apr 2005 13:57:23 -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: Mon, 11 Apr 2005 13:57:23 -0500
Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@daebe102.NOE.Nokia.com>
Thread-Topic: Security considerations of the ICMPv6 draft
Thread-Index: AcU+TUepnH0BhnyJRSmZpOTk2QmK9QAeqHng
To: <fernando@gont.com.ar>, <pekkas@netcore.fi>
X-OriginalArrivalTime: 11 Apr 2005 18:57:23.0923 (UTC)
	FILETIME=[4BFDC230:01C53EC8]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org
Subject: RE: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Fernando,

I agree that we should add some words to raise awareness
about the ICMP-based attacks.  We could add the text that
Pekka suggested in the security consideration section and
provide an informative reference to your draft.

I don't think the ICMP draft should go in details of how
a transport protocol should protect itself against these
attacks.  I think, it will be a good idea to write separate
drafts for those details.

We all seem to agree about adding some words and a reference
to draft-gont-tcpm-icmp-attacks-03.txt.  Right ?

Regards
Mukesh

> -----Original Message-----
> From: ext Fernando Gont [mailto:fernando@gont.com.ar]
> Sent: Sunday, April 10, 2005 9:35 PM
> To: Pekka Savola
> Cc: ipv6@ietf.org; Gupta Mukesh.K (Nokia-NET/MtView)
> Subject: Re: Security considerations of the ICMPv6 draft
>=20
>=20
> At 02:24 09/04/2005 +0300, Pekka Savola wrote:
>=20
> >>I think the ICMPv6 draft should add some words to raise=20
> awareness about=20
> >>ICMP-based attacks that can be performed against transport=20
> protocols.
> >
> >Any text suggestions -- just to have an idea how verbose and=20
> explicit=20
> >you're looking at; did you refer to the proposed text below,=20
> or something=20
> >more extensive?
>=20
> I referred to the text you had proposed. However, maybe a few=20
> additional=20
> words could be added. With the current specs, you either have=20
> IPsec, or no=20
> counter-measures at all. So I think the ICMP spec should say=20
> something like=20
> "transport protocols SHOULD use the information contained in the ICMP=20
> payload to validate the received ICMP messages". Probably not in the=20
> "Security Considerations section", but earlier in the spec.
>=20
>=20
>=20
> >>>By the way, one additional ICMP attack that could possibly=20
> be included=20
> >>>in 5.2:
> >>>    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=20
> upper layer
> >>>       with IPsec mitigates this problem, though the upper=20
> layers may
> >>>       also perform some form of validation of ICMPs on their own.
> >>>Where [TCP-attack] is an informative reference to=20
> >>>draft-gont-tcpm-icmp-attacks-03.txt.
> >
> >Yes, something like this should be added.  I thought it=20
> already was there,=20
> >but apparently not...
>=20
> Yes, this text has not yet been added.
>=20
>=20
>=20
> >>Another issue that may be worth considering is suggesting that the=20
> >>so-called "hard errors" should not necessarily be=20
> considered "hard".=20
> >>While there's no RFC 1122 for IPv6 (and thus you might say=20
> there's no=20
> >>such thing as "hard errors" and "soft errors" in v6), I=20
> think everyone=20
> >>will extrapolate RFC 1122's statements on soft and hard=20
> errors to the=20
> >>ICMPv6 specification.
> >
> >Even if I may agree with this sentiment, IMHO it seems to go=20
> too much on=20
> >the side of the transport protocols, and doesn't seem to be=20
> appropriate in=20
> >this document.  The above already a provides a pointer.
>=20
> Note that I'm not saying the ICMPv6 should say whether=20
> connections should=20
> be aborted upon receipt of ICMP errors or not. I'm saying=20
> that maybe the=20
> spec could suggest what the errors being reported "mean".=20
> E.g., is a "Port=20
> unreachable" a soft or a hard error?
> With this information, a transport-protocol designer could=20
> elaborate the=20
> policy of reaction to ICMP errors.
>=20
> I think that part of RFC 1122 that discusses which ICMP=20
> errors are soft or=20
> hard is a complement to the ICMPv4 spec. Then, when RFC 1122=20
> says "TCP=20
> SHOULD abort...", *that* is the transport-protocol stuff.
>=20
>=20
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
>=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  Mon Apr 11 17:22:56 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02595
	for <ipngwg-archive@lists.ietf.org>; Mon, 11 Apr 2005 17:22:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DL6Ix-0006Gi-Hc; Mon, 11 Apr 2005 17:18:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DL6Iv-0006FM-8Q
	for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 17:18:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02118
	for <ipv6@ietf.org>; Mon, 11 Apr 2005 17:18:34 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6SE-0000al-BG
	for ipv6@ietf.org; Mon, 11 Apr 2005 17:28:23 -0400
Received: from ([128.244.124.185])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10379099;
	Mon, 11 Apr 2005 17:17:59 -0400
In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@daebe102.NOE.Nokia.com>
References: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@daebe102.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Message-Id: <2e29bf2751fb5a5b96593a897d2d3bc7@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Mon, 11 Apr 2005 17:17:58 -0400
To: Mukesh.K.Gupta@nokia.com
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: 32b73d73e8047ed17386f9799119ce43
Cc: ipv6@ietf.org, pekkas@netcore.fi
Subject: Re: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2098549458=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============2098549458==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--344391424;
	protocol="application/pkcs7-signature"


--Apple-Mail-2--344391424
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi Mukesh,

On Apr 11, 2005, at 14:57, Mukesh.K.Gupta@nokia.com wrote:

> Fernando,
>
> I agree that we should add some words to raise awareness
> about the ICMP-based attacks.  We could add the text that
> Pekka suggested in the security consideration section and
> provide an informative reference to your draft.

Sounds like the right path to me.  Emphasis on the *informative*
reference.

>
> I don't think the ICMP draft should go in details of how
> a transport protocol should protect itself against these
> attacks.  I think, it will be a good idea to write separate
> drafts for those details.

Agreed.

>
> We all seem to agree about adding some words and a reference
> to draft-gont-tcpm-icmp-attacks-03.txt.  Right ?
>

That is my opinion.

Regards,
Brian

--Apple-Mail-2--344391424
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDExMjExNzU4WjAjBgkqhkiG9w0B
CQQxFgQUSmPRngpci6l0S3WJjF2l4hnoar4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEADDFWUxj7eurZcoL0xCVKbv8iWOJOLm0pbtmyk6Dh0zBl1EmBA+eURHPO6ckiFhbuOUvh
1c9SQENp8B4a1jbGksVDxyEK9RNNr/vbAs7WK7BcmW3ddZSUbslXiTfVhP1FmAyCggcIRTF5ORLh
p0ZfSp6/j79awAXxS+q9EDeCsL6l9NhHc6U9j1dgMzLVqRYGT2ophuJ0BiqFCig33OydugkH7Q1J
1J0UXP0OzeZ06jqeBSossBZKjbhW1JvDUzSXQ/7UjaztT6qfX1wFka0HC8LLwpY/Jrk5vSmSNbo/
Syqnh1qjsc0Q/UKFhwXjI2CF4nK7sbIKXtJWa+bOCD4ZJgAAAAAAAA==

--Apple-Mail-2--344391424--



--===============2098549458==
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
--------------------------------------------------------------------

--===============2098549458==--




From cowslip@yebox.com  Mon Apr 11 21:48: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 VAA20902;
	Mon, 11 Apr 2005 21:48:21 -0400 (EDT)
Received: from [222.111.28.136] (helo=132.151.6.1)
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DLAfL-0007Ry-5X; Mon, 11 Apr 2005 21:58:13 -0400
Authentication-Results: spanish.es
  from=premium.forwent.es; domainkeys=neutral (no sig)
X-Originating-IP: [76.200.129.140]
Received: from premium.countersunk.es  (EHLO premium.lufthansa.es) 
  by premium.visual.es with SMTP; Mon, 11 Apr 2005 20:41:00 -0600
Date: Mon, 11 Apr 2005 23:43:00 -0300
From: "Chester Hubbard" <cowslip@yebox.com>
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org
Subject: Become a homeowner with low rates
Message-ID: <116441.3837.cowslip@yebox.com>
X-Mailer: Kana Connect 6
X-Spam-Score: 9.7 (+++++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.mrg-now-yes.com/sign.asp



 Best Regards,

 Rosanna Todd
 
 to be remov(ed:	http://www.mrg-now-yes.com/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From imeneo@emailaccount.com  Mon Apr 11 21:48: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 VAA20980;
	Mon, 11 Apr 2005 21:48:33 -0400 (EDT)
Received: from [220.83.97.236] (helo=132.151.6.1)
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DLAfW-0007Sd-LO; Mon, 11 Apr 2005 21:58:24 -0400
Received: from upsurge.malocclusion-clap.com (HELO nonchalant.com 66.8.157.14)
  by cheerful.com with EMQP; Tue, 12 Apr 2005 08:47:29 +0600
Date: Tue, 12 Apr 2005 03:42:29 +0100
From: "Rex Reece" <imeneo@emailaccount.com>
Message-Id: <CFE3.AA79.9A71imeneo@emailaccount.com>
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org, ipr@ietf.org,
        ipr-wg@ietf.org
Subject: Become a homeowner with low rates
X-Mailer: CompuServe 7.0
X-Spam-Score: 7.5 (+++++++)
X-Spam-Flag: YES
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.mrg-now-yes.com/sign.asp



 Best Regards,

 Aurora Hatcher
 
 to be remov(ed:	http://www.mrg-now-yes.com/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Tue Apr 12 05:16:08 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11587
	for <ipngwg-archive@lists.ietf.org>; Tue, 12 Apr 2005 05:16:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLHBp-0003cJ-Vi; Tue, 12 Apr 2005 04:56:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLHBh-0003ae-Lu
	for ipv6@megatron.ietf.org; Tue, 12 Apr 2005 04:56:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10321
	for <ipv6@ietf.org>; Tue, 12 Apr 2005 04:55:50 -0400 (EDT)
Received: from smtp3.clb.oleane.net ([213.56.31.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLHL6-0001fa-4Z
	for ipv6@ietf.org; Tue, 12 Apr 2005 05:05:45 -0400
Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be
	forged)) (authenticated)
	by smtp3.clb.oleane.net with ESMTP id j3C8tfQG031395
	for <ipv6@ietf.org>; Tue, 12 Apr 2005 10:55:41 +0200
Message-Id: <200504120855.j3C8tfQG031395@smtp3.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <ipv6@ietf.org>
Date: Tue, 12 Apr 2005 10:55:31 +0200
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcU/PWHJ8n8nBeFiS0CZW0HWI6/hVQ==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Subject: ZigBee conference - Paris - France
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0918907521=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0918907521==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0196_01C53F4E.27B01FA0"

This is a multi-part message in MIME format.

------=_NextPart_000_0196_01C53F4E.27B01FA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

Only four weeks left before the starting of the ZigBee conference to be held
in Paris next 10-13 May.

Experts in sensor networks will examine all technical issues related to this
new technology.

Registration is still open.

Please get all details at:

 <http://www.upperside.fr/zigbee2005/zigbee2005intro.htm>
http://www.upperside.fr/zigbee2005/zigbee2005intro.htm

 


------=_NextPart_000_0196_01C53F4E.27B01FA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Only four weeks left before the starting of =
the
ZigBee conference to be held in <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Paris</st1:place></st1:City>
next 10-13 May.</span></font><span lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Experts in sensor networks will examine all =
technical
issues related to this new technology.</span></font><span =
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Registration is still open.</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Please get all details at:</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.upperside.fr/zigbee2005/zigbee2005intro.htm"
title=3D"http://www.upperside.fr/zigbee2005/zigbee2005intro.htm"><span
lang=3DEN-GB>http://www.upperside.fr/zigbee2005/zigbee2005intro.htm</span=
></a></span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0196_01C53F4E.27B01FA0--



--===============0918907521==
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
--------------------------------------------------------------------

--===============0918907521==--




From ekiru@emailaccount.com  Wed Apr 13 01:28: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 BAA19917;
	Wed, 13 Apr 2005 01:28:41 -0400 (EDT)
Received: from [217.29.19.11] (helo=132.151.6.1)
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DLaaI-0003uF-Dc; Wed, 13 Apr 2005 01:38:45 -0400
Received: from extinct-jcoppens.com (EHLO pentane.jcoppens.com) 
  by ms.jcoppens.com with SMTP; Wed, 13 Apr 2005 10:27:22 +0400
Date: Wed, 13 Apr 2005 03:21:22 -0300
From: "Federico Shipman" <ekiru@emailaccount.com>
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org, ipr@ietf.org,
        ipr-wg@ietf.org
Subject: Pre-approved Application #TSBRDV569
Message-ID: <BKELLDAGKABIOCHDFD111DGAA.danny146@virgilio.it>
X-SpamTest-Info: Profile: SysLog
X-SpamTest-Status: Not detected
X-SpamTest-Version: SMTP-Filter Version 2.0.0 [669], SpamtestISP/Release
X-Mailer: MIME-tools 5.41 (Entity 5.404)
X-Spam-Score: 6.4 (++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.mrg-now-yes.com/sign.asp



 Best Regards,

 Rickie Carr
 
 to be remov(ed:	http://www.mrg-now-yes.com/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Wed Apr 13 03:23:05 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02216
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 03:23:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLbwj-0003Kq-NN; Wed, 13 Apr 2005 03:05:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbwh-0003HU-61
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 03:05:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01331
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 03:05:50 -0400 (EDT)
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLc6L-0006Av-Ic
	for ipv6@ietf.org; Wed, 13 Apr 2005 03:15:55 -0400
Received: (qmail 27898 invoked from network); 13 Apr 2005 07:03:43 -0000
Received: from unknown (HELO fernando.gont.com.ar)
	(gont-fernando@200.41.120.18)
	by server.frh.utn.edu.ar with SMTP; 13 Apr 2005 07:03:43 -0000
Message-Id: <4.3.2.7.2.20050413033015.00da5a30@server.frh.utn.edu.ar>
X-Sender: gont-fernando@server.frh.utn.edu.ar
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Apr 2005 03:38:02 -0300
To: <Mukesh.K.Gupta@nokia.com>, <pekkas@netcore.fi>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@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: 21c69d3cfc2dd19218717dbe1d974352
Cc: ipv6@ietf.org
Subject: RE: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At 13:57 11/04/2005 -0500, Mukesh.K.Gupta@nokia.com wrote:

>I agree that we should add some words to raise awareness
>about the ICMP-based attacks.  We could add the text that
>Pekka suggested in the security consideration section and
>provide an informative reference to your draft.

That'd be a good thing.



>I don't think the ICMP draft should go in details of how
>a transport protocol should protect itself against these
>attacks.  I think, it will be a good idea to write separate
>drafts for those details.

I didn't mean we should provide details on how transport protocols should 
react to ICMP errors. I just suggested that the ICMPv6 draft should 
recommend transport protocols to use the information contained in the 
payload to validate the ICMP messages (but don't say a word about the 
actual checks), and also that it would be great if it provided a few words 
about what the ICMP error types/codes mean.
If left "as is", people will extrapolate the RFC 1122 description to ICMPv6.
I just say that adding something like "these error codes do not necessarily 
indicate hard errors". That little sentence would mean the discussion of 
ICMP in RFC 1122 does not necessarily apply to ICMPv6.

BTW, (closely related to this thread), this was released yesterday:

* Cisco's vulnerability report
http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml

* CERT/CC's vulnerability report
http://www.kb.cert.org/vuls/id/222750

* NISCC's vulnerability report
http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=en


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr 13 10:27:04 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00851
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 10:27:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLiYu-0008Lt-MP; Wed, 13 Apr 2005 10:09:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiYs-0008Km-RA
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 10:09:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28755
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 10:09:36 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLiiX-0008Hq-DY
	for ipv6@ietf.org; Wed, 13 Apr 2005 10:19:46 -0400
Received: from ([128.244.124.185])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10452889;
	Wed, 13 Apr 2005 10:09:13 -0400
Mime-Version: 1.0 (Apple Message framework v619.2)
To: IPv6 WG <ipv6@ietf.org>
Message-Id: <caab0e1b8f9a111b72c4a53df125c31a@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Wed, 13 Apr 2005 10:09:12 -0400
X-Mailer: Apple Mail (2.619.2)
X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0>
	HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0>
	URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary
	(TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0>
	Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary
	(TRU6):<0> Porn Dictionary (TRU6):<0> 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Subject: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1717155750=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============1717155750==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--197317112;
	protocol="application/pkcs7-signature"


--Apple-Mail-8--197317112
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

This starts a 2 week IPv6 WG Last Call for advancing:

	Title		: Considerations on M and O Flags of IPv6 Router Advertisement
	Author(s)	: S. Park, et al.
	Filename	: draft-ietf-ipv6-ra-mo-flags-01.txt
	Pages	: 13
	Date		: 2005-3-30
	
as a Proposed 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 April 27, 2005.

Regards,
Bob & Brian
IPv6 WG co-chairs


--Apple-Mail-8--197317112
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDEzMTQwOTEzWjAjBgkqhkiG9w0B
CQQxFgQUB0/MmcSG9y5qaCrdBw+Q9LY49hEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEALjry1FSdclqBZCvOK7w2Sny9Pyo+dNBF7hQCOOvvgS6vVbhK8UUm4062gclwFW8siPie
+JdU4iKQJCXzqDNZM3UatBtB0fd6+mC+VZI7gbaOgopwvpoZeiUL+R3OpHTMiD3+FVKUG6+ee36c
5vK4YyTGJxzObWpYoZ+g78ZqeHTyqwwJxXksYMgM1KjRFlwP7uItPEpDHWzKS78k/RFatRb7/iqE
2Z8cK2e5wGe8arTMulPkfeHEfUFjZd1Mp0iG1KoRex77QxEvxUX1ZE3SrpcXq3i1Xi+XQqh2Sp5U
6/8OWRqThRn87YCYR/FWI2/3rBRNBGhV1LTGW0C5kKQa6wAAAAAAAA==

--Apple-Mail-8--197317112--



--===============1717155750==
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
--------------------------------------------------------------------

--===============1717155750==--




From ipv6-bounces@ietf.org  Wed Apr 13 14:26:18 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20085
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 14:26:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLmV7-00010j-RV; Wed, 13 Apr 2005 14:22:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmV5-0000xY-KP
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 14:22:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19825
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 14:21:58 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmem-0006z9-KC
	for ipv6@ietf.org; Wed, 13 Apr 2005 14:32:09 -0400
Received: from ([128.244.124.185])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10465299;
	Wed, 13 Apr 2005 14:21:25 -0400
In-Reply-To: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Message-Id: <853acce3627cabf053004a5206ffd526@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Wed, 13 Apr 2005 14:21:24 -0400
To: IPv6 WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.619.2)
X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0>
	HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0>
	URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary
	(TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0>
	Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary
	(TRU6):<0> Porn Dictionary (TRU6):<0> 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0467926299=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============0467926299==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--182184968;
	protocol="application/pkcs7-signature"


--Apple-Mail-11--182184968
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

IPv6 WG,
      This is a status update on the centrally-allocated ULAs defined in
draft-ietf-ipv6-ula-central-01.txt.  At this time the chairs believe it
is prudent to gain operational experience with the locally-assigned
ULA specification (which is currently in the RFC Editor's Queue)
before continuing work on the centrally-allocated mechanism.

      The chairs would like to solicit input from WG members on this
approach.  Please state your support or disagreement with this
approach.  Those who disagree, please state rationale for wanting
to continue this work at this time.

Regards,
Brian & Bob
IPv6 WG co-chairs



--Apple-Mail-11--182184968
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDEzMTgyMTI1WjAjBgkqhkiG9w0B
CQQxFgQUiU6j4RuWHUgVkGmctW5NYeYUu/QweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEAUBMrnTUquRxVJkBNh+z304dqNhv4ePxJAR8bnMFzUwA3dd7mM6WVZdy7YZXGOJy3lukX
3yNna07Jib2qlmfH4fsjWLJFjW2GVwwA5BRb9aFTMxpEwzoIObFHRphRZYI67ni/JBXgEFgnEojW
W7gxWOcs+KBAiR04tU4/up+K9Wa8s6dt/U9Htc6Mg+4W67eODNWjASE64lujz/h5zXBQYjAo4NHk
85bwrNqOhZ8dVDiGY3GCvOyJdCiHeTsYVtlHA0EEr5P4dZV+uhjWk4dP+/24abxaqY/WgZiyfRnY
Vcy6Ew8eaGRUtfkC7REm8gjpl1FVKybomotpnDK9RLvMYAAAAAAAAA==

--Apple-Mail-11--182184968--



--===============0467926299==
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
--------------------------------------------------------------------

--===============0467926299==--




From ipv6-bounces@ietf.org  Wed Apr 13 15:52:51 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27717
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 15:52:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLnex-0004Pw-Mf; Wed, 13 Apr 2005 15:36:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLnew-0004Np-5c
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 15:36:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26610
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 15:36:12 -0400 (EDT)
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 1DLnoe-0000ZH-C9
	for ipv6@ietf.org; Wed, 13 Apr 2005 15:46:24 -0400
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
	j3DJa5E22116; Wed, 13 Apr 2005 22:36:05 +0300 (EET DST)
X-Scanned: Wed, 13 Apr 2005 22:54:24 +0300 Nokia Message Protector V1.3.34
	2004121512 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j3DJsO8x013458;
	Wed, 13 Apr 2005 22:54:24 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks001.ntc.nokia.com 00dp7Ki0; Wed, 13 Apr 2005 22:54:23 EEST
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
	j3DJZdM08757; Wed, 13 Apr 2005 22:35:40 +0300 (EET DST)
Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by
	daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 13 Apr 2005 14:35:16 -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, 13 Apr 2005 14:35:16 -0500
Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502E4@daebe102.NOE.Nokia.com>
Thread-Topic: Security considerations of the ICMPv6 draft
Thread-Index: AcU/9/q4176dwq1kSFu7LuWR8lkTgAAZQtsA
To: <fernando@gont.com.ar>, <pekkas@netcore.fi>
X-OriginalArrivalTime: 13 Apr 2005 19:35:16.0889 (UTC)
	FILETIME=[EB9C5890:01C5405F]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org
Subject: RE: Security considerations of the ICMPv6 draft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Ok so we are pretty much decided on adding the=20
awareness text.

What about we add the following text to cover your
second point also (i.e. recommending the upper layers to
use the payload for validation).

=3D=3D=3D
    6. As the ICMP messages are passed to the upper-layer=20
       processes, it is possible to perform attacks on the=20
       upper layer protocols (e.g., TCP) with ICMP [TCP-attack].
       Protecting the upper layer with IPsec mitigates this=20
       problem.  If not protected by IPsec, it is recommended
       for the upper layers to perform some form of validation
       of ICMP messages (using the information contained in=20
       the payload of the ICMP) before action upon them.  The
       actual validation checks are specific to the upper=20
       layers and are out of the scope of this spec.
=3D=3D=3D

The third point that you raise about the hard and the soft
errors, I am not sure what to do.  Do we already have a
resolution for TCP that=20
 - it should not consider any of the ICMP messages as=20
   hard errors ?  Or=20
 - it should perform some checks and then consider them
   as hard and soft according to RFC 1122 ? or
 - something else ?

Could you suggest what specific text we should add to
ICMPv6 to cover the issue of hard and soft errors ?

Regards
Mukesh

> -----Original Message-----
> From: ext Fernando Gont [mailto:fernando@gont.com.ar]
> Sent: Tuesday, April 12, 2005 11:38 PM
> To: Gupta Mukesh.K (Nokia-NET/MtView); pekkas@netcore.fi
> Cc: ipv6@ietf.org
> Subject: RE: Security considerations of the ICMPv6 draft
>=20
>=20
> At 13:57 11/04/2005 -0500, Mukesh.K.Gupta@nokia.com wrote:
>=20
> >I agree that we should add some words to raise awareness
> >about the ICMP-based attacks.  We could add the text that
> >Pekka suggested in the security consideration section and
> >provide an informative reference to your draft.
>=20
> That'd be a good thing.
>=20
>=20
>=20
> >I don't think the ICMP draft should go in details of how
> >a transport protocol should protect itself against these
> >attacks.  I think, it will be a good idea to write separate
> >drafts for those details.
>=20
> I didn't mean we should provide details on how transport=20
> protocols should=20
> react to ICMP errors. I just suggested that the ICMPv6 draft should=20
> recommend transport protocols to use the information contained in the=20
> payload to validate the ICMP messages (but don't say a word about the=20
> actual checks), and also that it would be great if it=20
> provided a few words=20
> about what the ICMP error types/codes mean.
> If left "as is", people will extrapolate the RFC 1122=20
> description to ICMPv6.
> I just say that adding something like "these error codes do=20
> not necessarily=20
> indicate hard errors". That little sentence would mean the=20
> discussion of=20
> ICMP in RFC 1122 does not necessarily apply to ICMPv6.
>=20
> BTW, (closely related to this thread), this was released yesterday:
>=20
> * Cisco's vulnerability report
> http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml
>=20
> * CERT/CC's vulnerability report
> http://www.kb.cert.org/vuls/id/222750
>=20
> * NISCC's vulnerability report
> http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=3Den
>=20
>=20
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
>=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 Apr 13 19:44:45 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20901
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 19:44:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLr2G-0006OJ-GL; Wed, 13 Apr 2005 19:12:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLr2E-0006I4-0f
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 19:12:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18076
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 19:12:35 -0400 (EDT)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrC6-0007gB-Cz
	for ipv6@ietf.org; Wed, 13 Apr 2005 19:22:50 -0400
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3DMgeh14513
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 15:42:40 -0700
X-mProtect: <200504132242> 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 smtpdKwA54t; Wed, 13 Apr 2005 15:42:37 PDT
Message-Id: <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 13 Apr 2005 14:13:34 -0700
To: <ipv6@ietf.org>
From: Bob Hinden <bob.hinden@nokia.com>
In-Reply-To: <88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi,

[Document author hat on]

Interesting discussion.  Sorry for not responding to this thread, but I 
have been dealing with a family matter and wasn't staying current with email.

I think there is general agreement that we can relax the anycast rules 
specified the address architecture.  The relevant text from Section 2.6 is 
currently:

    There is little experience with widespread, arbitrary use of Internet
    anycast addresses, and some known complications and hazards when
    using them in their full generality [ANYCST].  Until more experience
    has been gained and solutions are specified, the following
    restrictions are imposed on IPv6 anycast addresses:

       o An anycast address must not be used as the source address of an
         IPv6 packet.

       o An anycast address must not be assigned to an IPv6 host, that
         is, it may be assigned to an IPv6 router only.

The intent of this text was to not prohibit their usage for all time, but 
to wait until there was more experience and the usage was specified.  This 
may well be now.

I agree with the discussion that we shouldn't relax the rules without some 
additional text that summarizes the issues.  The cases where we think it is 
good to use anycast are specific and we still want to limit general usage.

Here is a proposal (rough) based loosely on Fred Baker's proposal and 
subsequent discussion on the list:

    Arbitrary use of Internet anycast addresses is not recommended.  There
    are known complications and hazards when using them in their full
    generality [ANYCST].  Specific usage guidelines are:

       1) Anycast may be used for simple query response applications
          (for example DNS) where all nodes serving the anycast
          address will respond with the same information and the packets
          are limited in size so path mtu discovery is not needed.

       2) Anycast may be used for applications where anycast is used to
          rendezvous with a server and subsequently learn a stable unicast
          address for further communication.

       3) Except as described in 1) and 2) above an anycast address must
          not be used as the source address of an IPv6 packet.

       4) Except as described in 1) and 2) an anycast address must not be
          assigned to an IPv6 host, that is, it may be assigned to an IPv6
          router only.

Comments and suggestions welcome.

Another approach is to write a separate document that relaxes the rules and 
describes the issues in more depth than we might want to add here.  This 
would keep the current limits in the address architecture (going forward to 
Draft standard) and have the new document start at Proposed standard.

Comments?

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 Apr 13 21:12:54 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26154
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 21:12:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLsoe-0007MT-90; Wed, 13 Apr 2005 21:06:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsoc-0007MO-2d
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 21:06:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25518
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 21:06:40 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsyU-00022D-WF
	for ipv6@ietf.org; Wed, 13 Apr 2005 21:16:55 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net
	[IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net",
	Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id D8C08F9
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 21:06:29 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id 3174341EA
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 21:06:29 -0400 (EDT)
Date: Wed, 13 Apr 2005 21:06:29 -0400
From: Rob Austein <sra@isc.org>
To: ipv6@ietf.org
In-Reply-To: <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050414010629.3174341EA@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Wed, 13 Apr 2005 14:13:34 -0700, Bob Hinden wrote:
> 
> Here is a proposal (rough) based loosely on Fred Baker's proposal and 
> subsequent discussion on the list:
> 
>     Arbitrary use of Internet anycast addresses is not recommended.  There
>     are known complications and hazards when using them in their full
>     generality [ANYCST].  Specific usage guidelines are:

Ok so far, although "arbitrary" is in the eye of the beholder....

>        1) Anycast may be used for simple query response applications
>           (for example DNS) where all nodes serving the anycast
>           address will respond with the same information and the packets
>           are limited in size so path mtu discovery is not needed.

Not quite right.  DNS packets might be big enough to need
fragmentation.  But there isn't any useful way to do path MTU
discovery in DNS/UDP anyway (very high client/server ratio, idempotent
lookup protocal, and the big packets are the responses going from the
server to the client, so the overhead of performing PMTU discovery and
keeping the necessary state on the server almost certainly outweighs
cost of just performing the query again when fragments get dropped).

So the criteria here are:

a) Short-lived session (typically two packet UDP exchange, but some
   argue that even a fast 7 packet TCP exchange is ok, so long as it's
   fast);

b) Path MTU either not needed or not useful for reasons having nothing
   to do with use of anycast.

>        2) Anycast may be used for applications where anycast is used to
>           rendezvous with a server and subsequently learn a stable unicast
>           address for further communication.

Ok.

>        3) Except as described in 1) and 2) above an anycast address must
>           not be used as the source address of an IPv6 packet.

Too strong.  I'd be ok with "should not".

>        4) Except as described in 1) and 2) an anycast address must not be
>           assigned to an IPv6 host, that is, it may be assigned to an IPv6
>           router only.

I realize that this is just continuation of a fine old IPv6 tradition,
but it has never made any sense to me.  What's so special about
routers in this context?  Why is it ok when a router does it but not
when a host does it?  As near as I can tell, the real historical
answer to this is that, once upon a time, somebody thought that router
discovery might use anycast, back before the current RA protocol.

If there's a strong technical justification for treating routers and
hosts differently here, please make it (here and in the text), but
absent such a justification I'd urge dropping point (4) entirely.

> Another approach is to write a separate document that relaxes the rules and 
> describes the issues in more depth than we might want to add here.  This 
> would keep the current limits in the address architecture (going forward to 
> Draft standard) and have the new document start at Proposed standard.

I'd rather just fix the current doc and let the ongoing work happen in
GROW.  If the GROW work results in enough IPv6-specific stuff that
there's a need for a new IPv6 WG document, fine, but so far I am not
seeing it.  Anycast is mostly an IP issue, not an IPv6 or IPv4 issue.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr 13 23:25:32 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04477
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 23:25:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLuum-0001Gy-Sw; Wed, 13 Apr 2005 23:21:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLuto-0001Cl-Fh
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 23:20:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04243
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 23:20:09 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLv3h-0005CD-TL
	for ipv6@ietf.org; Wed, 13 Apr 2005 23:30:27 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DLutg-000ABU-L7; Thu, 14 Apr 2005 03:20:04 +0000
In-Reply-To: <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <a7bc13b97402c73ec4228fa80ca5ce14@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Wed, 13 Apr 2005 23:19:32 -0400
To: Bob Hinden <bob.hinden@nokia.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Hi Bob,

On 13 Apr 2005, at 17:13, Bob Hinden wrote:

>    Arbitrary use of Internet anycast addresses is not recommended.  
> There
>    are known complications and hazards when using them in their full
>    generality [ANYCST].  Specific usage guidelines are:
>
>       1) Anycast may be used for simple query response applications
>          (for example DNS) where all nodes serving the anycast
>          address will respond with the same information and the packets
>          are limited in size so path mtu discovery is not needed.
>
>       2) Anycast may be used for applications where anycast is used to
>          rendezvous with a server and subsequently learn a stable 
> unicast
>          address for further communication.
>
>       3) Except as described in 1) and 2) above an anycast address must
>          not be used as the source address of an IPv6 packet.
>
>       4) Except as described in 1) and 2) an anycast address must not 
> be
>          assigned to an IPv6 host, that is, it may be assigned to an 
> IPv6
>          router only.
>
> Comments and suggestions welcome.

I think the issue of when it is appropriate to use anycast addresses is 
not going to be reasonably summarised in five paragraphs, and I caution 
against attempting to do so. By way of illustration, the document 
draft-ietf-grow-anycast-00 runs to 20 pages. (That draft could use 
improvements, but it doesn't contain 19 pages of filler :-)

Might it be better to simply note that anycast is not a 
universally-appropriate technique for service distribution, and that 
caution is required? From some vantage points the text you proposed 
doesn't actually say much more than that (since most services can be 
described as "simple query response applications" when deconstructed). 
If details are required, a reference to the grow document would provide 
better guidance to the reader.

Specific points raised by the text above include:

1. There are services distributed using anycast in IPv4 which 
deliberately provide different information from different nodes, in 
order to provide topologically-sensitive service. It is not clear that 
this is unreasonable, or should be prohibited in IPv6, as your 
suggested item (1) above does.

2. There are examples of "simple query response applications" that 
perform very badly when distributed using anycast, including the DNS. 
The suitability of anycast lies both in the nature of the protocols 
concerned and also the nature of the network across which the service 
is being distributed.


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr 13 23:37:03 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05113
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 23:37:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLv6H-00031J-Pk; Wed, 13 Apr 2005 23:33:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLv6A-00030I-NS
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 23:32:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04799
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 23:32:48 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvFu-0005TB-Eo
	for ipv6@ietf.org; Wed, 13 Apr 2005 23:43:05 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net
	[IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net",
	Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id 24C6AF9
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 23:32:36 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id 6D71D41EA
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 23:32:35 -0400 (EDT)
Date: Wed, 13 Apr 2005 23:32:35 -0400
From: Rob Austein <sra@isc.org>
To: ipv6@ietf.org
In-Reply-To: <a7bc13b97402c73ec4228fa80ca5ce14@isc.org>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
	<a7bc13b97402c73ec4228fa80ca5ce14@isc.org>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050414033235.6D71D41EA@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Upon further analysis....I agree with Joe.  I was trying to meet Bob
halfway, but upon reflection have concluded that I was wrong to do so.

Anycast is complicated, and the complications are not specific to
IPv6.  It really would be doing the world a favor if the IPv6 WG were
to get rid of the language in the IPv6 address architecture doc that
places IPv6-specific restrictions on anycast, then let the GROW WG
handle the general anycast problem.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Wed Apr 13 23:43:36 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05561
	for <ipngwg-archive@lists.ietf.org>; Wed, 13 Apr 2005 23:43:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLvCN-00046U-Fi; Wed, 13 Apr 2005 23:39:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvCF-00046D-J2
	for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 23:39:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05262
	for <ipv6@ietf.org>; Wed, 13 Apr 2005 23:39:05 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvM2-0005dr-D3
	for ipv6@ietf.org; Wed, 13 Apr 2005 23:49:22 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DLvC6-000AIA-DW; Thu, 14 Apr 2005 03:39:06 +0000
In-Reply-To: <20050414010629.3174341EA@thrintun.hactrn.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
	<20050414010629.3174341EA@thrintun.hactrn.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5fecacb05f7b463d6d5e3d06c4bf18e1@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Wed, 13 Apr 2005 23:38:33 -0400
To: Rob Austein <Rob_Austein@isc.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 13 Apr 2005, at 21:06, Rob Austein wrote:

> So the criteria here are:
>
> a) Short-lived session (typically two packet UDP exchange, but some
>    argue that even a fast 7 packet TCP exchange is ok, so long as it's
>    fast);

For the record, I know of people who have distributed video streaming 
services and ftp servers using anycast, with attendant long-held, 
million-packet TCP sessions, and who have done so very successfully. 
POP3 and SMTP services have been anycast in real, live ISPs' production 
networks for a long time (I know of an example that dates back at least 
10 years).

As I noted in my reply to Bob, the nature of the protocol is not the 
final discriminator here -- it's the protocol *and* the network *and* 
the distribution of nodes, and a comprehensive treatment (such as might 
be expected if MUST NOTs are showing up in the text) is not going to 
fit in this draft.

>> Another approach is to write a separate document that relaxes the 
>> rules and
>> describes the issues in more depth than we might want to add here.  
>> This
>> would keep the current limits in the address architecture (going 
>> forward to
>> Draft standard) and have the new document start at Proposed standard.

Such a draft already exists in the form of 
draft-jabley-v6-anycast-clarify, which tersely defers most commentary 
to the grow draft. If there is a use for that draft, then perhaps it 
lies in being able to include a normative reference to the grow draft 
without holding the v6 architecture document too long in the RFC 
editor's queue (waiting for the grow document to be WGLCd and 
published).

> [...] Anycast is mostly an IP issue, not an IPv6 or IPv4 issue.

That is my view, too, which is why I keep trying to illustrate this v6 
discussion with examples of v4 anycast deployment.


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From encinias@doneasy.com  Thu Apr 14 08:04: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 IAA04291;
	Thu, 14 Apr 2005 08:04:51 -0400 (EDT)
Received: from [210.92.86.5] (helo=132.151.6.1)
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DM3FV-0003mx-Ge; Thu, 14 Apr 2005 08:15:12 -0400
Received: from militiamen-jcoppens.com (EHLO bartok.jcoppens.com) 
  by debase.jcoppens.com with SMTP; Thu, 14 Apr 2005 06:58:20 -0600
Date: Thu, 14 Apr 2005 06:54:20 -0600
From: "Jewell Allison" <encinias@doneasy.com>
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org, ipr@ietf.org
Subject: Need a low mortage rate?
Message-ID: <BKELLDAGKABIOCHDFD012DGAA.danny306@virgilio.it>
X-SpamTest-Info: Profile: SysLog
X-SpamTest-Status: Not detected
X-SpamTest-Version: SMTP-Filter Version 2.0.0 [401], SpamtestISP/Release
X-Mailer: MIME-tools 5.41 (Entity 5.404)
X-Spam-Score: 9.7 (+++++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.mrg-now-yes.com/sign.asp



 Best Regards,

 Ophelia Snider
 
 to be remov(ed:	http://www.mrg-now-yes.com/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Thu Apr 14 08:22:58 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06010
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 08:22:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM34k-0003w5-Sq; Thu, 14 Apr 2005 08:04:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM34j-0003vq-8E
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 08:04:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04149
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 08:03:52 -0400 (EDT)
Received: from mtagate1.de.ibm.com ([195.212.29.150])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM3EZ-0003lQ-8m
	for ipv6@ietf.org; Thu, 14 Apr 2005 08:14:12 -0400
Received: from d12nrmr1507.megacenter.de.ibm.com
	(d12nrmr1507.megacenter.de.ibm.com [9.149.167.1])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j3EC3f0Q169132
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 12:03:41 GMT
Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com
	[9.149.165.213])
	by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j3EC3fU7184732 for <ipv6@ietf.org>; Thu, 14 Apr 2005 14:03:41 +0200
Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	j3EC3eaa012520 for <ipv6@ietf.org>; Thu, 14 Apr 2005 14:03:40 +0200
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	j3EC3eHm012510; Thu, 14 Apr 2005 14:03:40 +0200
Received: from zurich.ibm.com (sig-9-145-255-194.de.ibm.com [9.145.255.194])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA80384;
	Thu, 14 Apr 2005 14:03:39 +0200
Message-ID: <425E5C19.1050001@zurich.ibm.com>
Date: Thu, 14 Apr 2005 14:03:37 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Brian Haberman <brian@innovationslab.net>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
	<853acce3627cabf053004a5206ffd526@innovationslab.net>
In-Reply-To: <853acce3627cabf053004a5206ffd526@innovationslab.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>, IPv6 WG <ipv6@ietf.org>
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

I agree that this is the best approach right now.

    Brian C

Brian Haberman wrote:
> IPv6 WG,
>      This is a status update on the centrally-allocated ULAs defined in
> draft-ietf-ipv6-ula-central-01.txt.  At this time the chairs believe it
> is prudent to gain operational experience with the locally-assigned
> ULA specification (which is currently in the RFC Editor's Queue)
> before continuing work on the centrally-allocated mechanism.
> 
>      The chairs would like to solicit input from WG members on this
> approach.  Please state your support or disagreement with this
> approach.  Those who disagree, please state rationale for wanting
> to continue this work at this time.
> 
> Regards,
> Brian & Bob
> IPv6 WG co-chairs


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr 14 09:43:45 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12170
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 09:43:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM4TM-0000ab-Ar; Thu, 14 Apr 2005 09:33:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4TJ-0000Zi-9o
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 09:33:29 -0400
Received: from 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 <ipv6@ietf.org>; Thu, 14 Apr 2005 09:33:19 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4dA-0007TE-DS
	for ipv6@ietf.org; Thu, 14 Apr 2005 09:43:41 -0400
Received: from ([128.244.124.185])
	by piper.jhuapl.edu with ESMTP  id KP-BXZ33.10496649;
	Thu, 14 Apr 2005 09:32:49 -0400
In-Reply-To: <20050414033235.6D71D41EA@thrintun.hactrn.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
	<a7bc13b97402c73ec4228fa80ca5ce14@isc.org>
	<20050414033235.6D71D41EA@thrintun.hactrn.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Message-Id: <ee324678c5b8dfe1fb306e253ae15f3a@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Thu, 14 Apr 2005 09:32:47 -0400
To: Rob Austein <sra@isc.org>
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: b280b4db656c3ca28dd62e5e0b03daa8
Cc: ipv6@ietf.org
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2106632111=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


--===============2106632111==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--113102570;
	protocol="application/pkcs7-signature"


--Apple-Mail-1--113102570
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi Rob,

On Apr 13, 2005, at 23:32, Rob Austein wrote:

> Upon further analysis....I agree with Joe.  I was trying to meet Bob
> halfway, but upon reflection have concluded that I was wrong to do so.
>
> Anycast is complicated, and the complications are not specific to
> IPv6.  It really would be doing the world a favor if the IPv6 WG were
> to get rid of the language in the IPv6 address architecture doc that
> places IPv6-specific restrictions on anycast, then let the GROW WG
> handle the general anycast problem.
>

If I read this correctly, you would like to see the two rules on anycast
in the addressing architecture completely removed rather than relaxed.

I can see the benefit of having the anycast functionality defined in
one common place.

Regards,
Brian

--Apple-Mail-1--113102570
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDE0MTMzMjQ3WjAjBgkqhkiG9w0B
CQQxFgQUxAYTcIQPoCD070twPgmLv4DclPEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB
BQAEggEAtV3KxQ7qygqx39b8NFAyP2TmMFp3MbQw+SyNKvxI6ncL3phIu2FKF0ph5SSHfPjoZMW/
VFQKH9CKNucp0U0i4wQFNKh1rhaqADkbyIH6z260cqYzRipvLJnFAgxDmcIrTdozmvhriM3OO+2V
wFQFI8qB2CcTdOvoELTiUn/iMIH+ijarQnKSgYzWn0MqM24nlNxyTl2r5wBMeMKxX7mqtcUDZ6aa
6CVNEemBbGnJIHDHbZl1QKjBR+2SPRs5+QNqf/DAdam7Y5r0vT/NsONSE+nEIdWSDZA2Cax3eJFj
dP7KmfSFgo+QVCVuYyPEKSZurgEcQgT/WWG8l9npDD9RfgAAAAAAAA==

--Apple-Mail-1--113102570--



--===============2106632111==
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
--------------------------------------------------------------------

--===============2106632111==--




From ipv6-bounces@ietf.org  Thu Apr 14 12:10:33 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27674
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 12:10:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM6bt-0001si-8H; Thu, 14 Apr 2005 11:50:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6br-0001rs-3j
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 11:50:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26164
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 11:50:16 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6lk-0005GC-88
	for ipv6@ietf.org; Thu, 14 Apr 2005 12:00:40 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net
	[IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net",
	Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id 275AB27E
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 11:50:07 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id 72B0641EA
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 11:50:06 -0400 (EDT)
Date: Thu, 14 Apr 2005 11:50:06 -0400
From: Rob Austein <sra@isc.org>
To: ipv6@ietf.org
In-Reply-To: <ee324678c5b8dfe1fb306e253ae15f3a@innovationslab.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
	<a7bc13b97402c73ec4228fa80ca5ce14@isc.org>
	<20050414033235.6D71D41EA@thrintun.hactrn.net>
	<ee324678c5b8dfe1fb306e253ae15f3a@innovationslab.net>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050414155006.72B0641EA@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Thu, 14 Apr 2005 09:32:47 -0400, Brian Haberman wrote:
> 
> > Anycast is complicated, and the complications are not specific to
> > IPv6.  It really would be doing the world a favor if the IPv6 WG were
> > to get rid of the language in the IPv6 address architecture doc that
> > places IPv6-specific restrictions on anycast, then let the GROW WG
> > handle the general anycast problem.
> 
> If I read this correctly, you would like to see the two rules on anycast
> in the addressing architecture completely removed rather than relaxed.

Correct.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr 14 13:47:36 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05821
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 13:47:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM8EX-0005qY-NX; Thu, 14 Apr 2005 13:34:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8EW-0005q4-8f
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 13:34:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04711
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 13:34:19 -0400 (EDT)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8OP-0001Gr-B4
	for ipv6@ietf.org; Thu, 14 Apr 2005 13:44:42 -0400
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3EH4EH30299;
	Thu, 14 Apr 2005 10:04:14 -0700
X-mProtect: <200504141704> Nokia Silicon Valley Messaging Protection
Received: from danira-pool054211.americas.nokia.com (10.241.54.211,
	claiming to be "l5131412.nokia.com")
	by darkstar.iprg.nokia.com smtpdykZ9DF; Thu, 14 Apr 2005 10:04:12 PDT
Message-Id: <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 14 Apr 2005 10:33:45 -0700
To: Rob Austein <sra@isc.org>
From: Bob Hinden <bob.hinden@nokia.com>
In-Reply-To: <20050414033235.6D71D41EA@thrintun.hactrn.net>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
	<a7bc13b97402c73ec4228fa80ca5ce14@isc.org>
	<20050414033235.6D71D41EA@thrintun.hactrn.net>
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: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Rob,

>Anycast is complicated, and the complications are not specific to
>IPv6.  It really would be doing the world a favor if the IPv6 WG were
>to get rid of the language in the IPv6 address architecture doc that
>places IPv6-specific restrictions on anycast, then let the GROW WG
>handle the general anycast problem.

OK, I think this makes sense.

The proposal is then to remove the following text from the end of Section 
2.6 the document:

    There is little experience with widespread, arbitrary use of Internet
    anycast addresses, and some known complications and hazards when
    using them in their full generality [ANYCST].  Until more experience
    has been gained and solutions are specified, the following
    restrictions are imposed on IPv6 anycast addresses:

       o An anycast address must not be used as the source address of an
         IPv6 packet.

       o An anycast address must not be assigned to an IPv6 host, that
         is, it may be assigned to an IPv6 router only.

This would mean we would not try to describe the general issues with 
anycast usage in the document.  I agree this makes sense because the issues 
are not specific to IPv6, there is now a body of experience with anycast 
usage, and the GROW working group is working in this area.

Is everyone else OK with this proposed change?

Bob



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr 14 13:47:36 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05838
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 13:47:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM8Hq-0006Pd-4D; Thu, 14 Apr 2005 13:37:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8Ho-0006P4-2u
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 13:37:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05033
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 13:37:43 -0400 (EDT)
Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net
	([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8Rh-0001OH-6X
	for ipv6@ietf.org; Thu, 14 Apr 2005 13:48:06 -0400
Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1])
	by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id j3EHbbv31302;
	Thu, 14 Apr 2005 12:37:37 -0500
Message-ID: <005001c54118$e77bd4c0$6c0016ac@ssprunk>
From: "Stephen Sprunk" <stephen@sprunk.org>
To: "Brian Haberman" <brian@innovationslab.net>, "IPv6 WG" <ipv6@ietf.org>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
	<853acce3627cabf053004a5206ffd526@innovationslab.net>
Date: Thu, 14 Apr 2005 12:39:25 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Thus spake "Brian Haberman" <brian@innovationslab.net>
> IPv6 WG,
>       This is a status update on the centrally-allocated ULAs defined in
> draft-ietf-ipv6-ula-central-01.txt.  At this time the chairs believe it
> is prudent to gain operational experience with the locally-assigned
> ULA specification (which is currently in the RFC Editor's Queue)
> before continuing work on the centrally-allocated mechanism.
>
>       The chairs would like to solicit input from WG members on this
> approach.  Please state your support or disagreement with this
> approach.  Those who disagree, please state rationale for wanting
> to continue this work at this time.

Agreed.

I also believe that we should be watching the IPv6 PI policy proposal at
ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I
see little reason to continue work on centrally-assigned ULAs.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From homelyn@doramail.com  Thu Apr 14 15:25: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 PAA14927;
	Thu, 14 Apr 2005 15:25:19 -0400 (EDT)
Received: from g203165.upc-g.chello.nl ([80.57.203.165])
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DMA7q-0005kA-DD; Thu, 14 Apr 2005 15:35:44 -0400
Authentication-Results: debbie.es
  from=premium.bayonne.es; domainkeys=neutral (no sig)
X-Originating-IP: [70.40.48.208]
Received: from premium.dobbin.es  (EHLO premium.hewn.es) 
  by premium.redemption.es with SMTP; Thu, 14 Apr 2005 15:20:00 -0500
Date: Thu, 14 Apr 2005 16:19:00 -0400
From: "Landon Castle" <homelyn@doramail.com>
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org, ipr@ietf.org
Subject: High rates? Not with us! low fixed rate
Message-ID: <116941.4873.homelyn@doramail.com>
X-Mailer: Kana Connect 6
X-Spam-Score: 9.5 (+++++++++)
X-Spam-Flag: YES
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.mrg-now-yes.com/sign.asp



 Best Regards,

 Kerry Presley
 
 to be remov(ed:	http://www.mrg-now-yes.com/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.


From ipv6-bounces@ietf.org  Thu Apr 14 17:58:34 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04560
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 17:58:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMCCf-0005U8-5b; Thu, 14 Apr 2005 17:48:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCCb-0005TN-4b
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 17:48:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03744
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 17:48:34 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCMW-0005Us-Jh
	for ipv6@ietf.org; Thu, 14 Apr 2005 17:59:01 -0400
Received: from [199.212.90.16] (helo=[199.212.90.16])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1DMCCN-000EW8-TI; Thu, 14 Apr 2005 21:48:32 +0000
In-Reply-To: <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com>
References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net>
	<425716A6.7060700@sun.com>
	<88e8dc1650039076a0903c46ad99dcda@innovationslab.net>
	<6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com>
	<a7bc13b97402c73ec4228fa80ca5ce14@isc.org>
	<20050414033235.6D71D41EA@thrintun.hactrn.net>
	<6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <84d7ebc2f657162a0d03014674043a8b@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Date: Thu, 14 Apr 2005 17:47:59 -0400
To: Bob Hinden <bob.hinden@nokia.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: Rob Austein <Rob_Austein@isc.org>, ipv6@ietf.org
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit


On 14 Apr 2005, at 13:33, Bob Hinden wrote:

> The proposal is then to remove the following text from the end of 
> Section 2.6 the document:
>
>    There is little experience with widespread, arbitrary use of 
> Internet
>    anycast addresses, and some known complications and hazards when
>    using them in their full generality [ANYCST].  Until more experience
>    has been gained and solutions are specified, the following
>    restrictions are imposed on IPv6 anycast addresses:
>
>       o An anycast address must not be used as the source address of an
>         IPv6 packet.
>
>       o An anycast address must not be assigned to an IPv6 host, that
>         is, it may be assigned to an IPv6 router only.
>
> This would mean we would not try to describe the general issues with 
> anycast usage in the document.  I agree this makes sense because the 
> issues are not specific to IPv6, there is now a body of experience 
> with anycast usage, and the GROW working group is working in this 
> area.
>
> Is everyone else OK with this proposed change?

For the record, I am OK with this change (it's what I proposed to the 
IESG when we kicked off this thread, so I presume that's obvious, but 
just to be clear).


Joe


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr 14 18:30:20 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07976
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 18:30:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMCQE-0000sm-3u; Thu, 14 Apr 2005 18:02:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCQA-0000mg-F7
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 18:02:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05000
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 18:02:43 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com ([130.76.64.48])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCaE-00068H-Hp
	for ipv6@ietf.org; Thu, 14 Apr 2005 18:13:10 -0400
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id
	PAA24495; Thu, 14 Apr 2005 15:02:35 -0700 (PDT)
Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id
	j3EM2Zm01392; Thu, 14 Apr 2005 17:02:35 -0500 (CDT)
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); 
	Thu, 14 Apr 2005 18:02:34 -0400
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, 14 Apr 2005 18:02:33 -0400
Message-ID: <EF40C42ACAB7A649B2EAE70C19B6CD6E028DF208@xch-ne-02.ne.nos.boeing.com>
Thread-Topic: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
thread-index: AcVBHFArm7+/psWUTyGUuTpq4B2zSgAIRogw
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: "Bob Hinden" <bob.hinden@nokia.com>
X-OriginalArrivalTime: 14 Apr 2005 22:02:34.0231 (UTC)
	FILETIME=[A97D7870:01C5413D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org
Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Seems logical to me as well. If multicast is a specialized and =
complicated topic worthy of a separate RFC, I can easily accept that =
anycast should be given equal rights.

Bert


> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@nokia.com]
>=20
> Rob,
>=20
> >Anycast is complicated, and the complications are not specific to
> >IPv6.  It really would be doing the world a favor if the IPv6 WG were
> >to get rid of the language in the IPv6 address architecture doc that
> >places IPv6-specific restrictions on anycast, then let the GROW WG
> >handle the general anycast problem.
>=20
> OK, I think this makes sense.
>=20
> The proposal is then to remove the following text from the=20
> end of Section=20
> 2.6 the document:
>=20
>     There is little experience with widespread, arbitrary use=20
> of Internet
>     anycast addresses, and some known complications and hazards when
>     using them in their full generality [ANYCST].  Until more=20
> experience
>     has been gained and solutions are specified, the following
>     restrictions are imposed on IPv6 anycast addresses:
>=20
>        o An anycast address must not be used as the source=20
> address of an
>          IPv6 packet.
>=20
>        o An anycast address must not be assigned to an IPv6 host, that
>          is, it may be assigned to an IPv6 router only.
>=20
> This would mean we would not try to describe the general issues with=20
> anycast usage in the document.  I agree this makes sense=20
> because the issues=20
> are not specific to IPv6, there is now a body of experience=20
> with anycast=20
> usage, and the GROW working group is working in this area.
>=20
> Is everyone else OK with this proposed change?
>=20
> Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Thu Apr 14 21:54:30 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20703
	for <ipngwg-archive@lists.ietf.org>; Thu, 14 Apr 2005 21:54:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMFxK-0002j6-5d; Thu, 14 Apr 2005 21:49:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFxH-0002iD-8F
	for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 21:49:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20348
	for <ipv6@ietf.org>; Thu, 14 Apr 2005 21:48:57 -0400 (EDT)
Received: from 147.cust2.sa.dsl.ozemail.com.au ([210.84.225.147]
	helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMG7A-00063L-Sf
	for ipv6@ietf.org; Thu, 14 Apr 2005 21:59:26 -0400
Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1])
	by ubu.nosense.org (Postfix) with SMTP id 7988562AAE;
	Fri, 15 Apr 2005 11:18:43 +0930 (CST)
Date: Fri, 15 Apr 2005 11:18:43 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Brian Haberman <brian@innovationslab.net>
Message-Id: <20050415111843.4b03ed62.ipng@69706e6720323030352d30312d31340a.nosense.org>
In-Reply-To: <853acce3627cabf053004a5206ffd526@innovationslab.net>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
	<853acce3627cabf053004a5206ffd526@innovationslab.net>
X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: margaret@thingmagic.com, bob.hinden@nokia.com, ipv6@ietf.org
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

On Wed, 13 Apr 2005 14:21:24 -0400
Brian Haberman <brian@innovationslab.net> wrote:

> IPv6 WG,
>       This is a status update on the centrally-allocated ULAs defined in
> draft-ietf-ipv6-ula-central-01.txt.  At this time the chairs believe it
> is prudent to gain operational experience with the locally-assigned
> ULA specification (which is currently in the RFC Editor's Queue)
> before continuing work on the centrally-allocated mechanism.
> 
>       The chairs would like to solicit input from WG members on this
> approach.  Please state your support or disagreement with this
> approach.  Those who disagree, please state rationale for wanting
> to continue this work at this time.
> 

I agree with this approach.

I'd be interested to know if there is a somewhat formal process for
collecting or just documenting the data about this operational
experience. Any (offlist if necessary) pointers or references would be
appreciated.

Regards,
Mark.

-- 

    The Internet's nature is peer to peer.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr 15 04:15:41 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05063
	for <ipngwg-archive@lists.ietf.org>; Fri, 15 Apr 2005 04:15:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMLdG-0004Y2-QG; Fri, 15 Apr 2005 03:52:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLdA-0004XI-HN
	for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 03:52:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03364
	for <ipv6@ietf.org>; Fri, 15 Apr 2005 03:52:39 -0400 (EDT)
Received: from raven.ecs.soton.ac.uk ([152.78.70.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLnB-0001vi-1z
	for ipv6@ietf.org; Fri, 15 Apr 2005 04:03:10 -0400
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
	j3F7qYi3005775; Fri, 15 Apr 2005 08:52:34 +0100 (BST)
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 IAA28309;
	Fri, 15 Apr 2005 08:52:26 +0100 (BST)
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3F7qQ411565;
	Fri, 15 Apr 2005 08:52:26 +0100
Date: Fri, 15 Apr 2005 08:52:26 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: Stephen Sprunk <stephen@sprunk.org>
Message-ID: <20050415075226.GG10920@login.ecs.soton.ac.uk>
Mail-Followup-To: Stephen Sprunk <stephen@sprunk.org>,
	Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>,
	Margaret Wasserman <margaret@thingmagic.com>,
	Bob Hinden <bob.hinden@nokia.com>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
	<853acce3627cabf053004a5206ffd526@innovationslab.net>
	<005001c54118$e77bd4c0$6c0016ac@ssprunk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005001c54118$e77bd4c0$6c0016ac@ssprunk>
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: d6b246023072368de71562c0ab503126
Cc: Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>,
        Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote:
> 
> I also believe that we should be watching the IPv6 PI policy proposal at
> ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I
> see little reason to continue work on centrally-assigned ULAs.

I disagree.  The ARIN proposal seems to be 'PI for any ASN holder' in which
case

a) this will limit who gets the PI space to large organisations
b) be limited by the 16-bit ASN space (and may create a land rush)
c) be useless to the small end site that wants to use unique ULAs

But I may have misunderstood the ARIN proposal :)

-- 
Tim/::1



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr 15 04:28:27 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06155
	for <ipngwg-archive@lists.ietf.org>; Fri, 15 Apr 2005 04:28:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMLxe-0007j8-Gp; Fri, 15 Apr 2005 04:13:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLxa-0007hZ-BR
	for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 04:13:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04919
	for <ipv6@ietf.org>; Fri, 15 Apr 2005 04:13:44 -0400 (EDT)
Received: from raven.ecs.soton.ac.uk ([152.78.70.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMM7b-0002kS-WE
	for ipv6@ietf.org; Fri, 15 Apr 2005 04:24:16 -0400
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
	j3F8Dii3006166; Fri, 15 Apr 2005 09:13:44 +0100 (BST)
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 JAA29546;
	Fri, 15 Apr 2005 09:13:42 +0100 (BST)
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3F8Dg612221;
	Fri, 15 Apr 2005 09:13:42 +0100
Date: Fri, 15 Apr 2005 09:13:42 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: Brian E Carpenter <brc@zurich.ibm.com>
Message-ID: <20050415081342.GI10920@login.ecs.soton.ac.uk>
Mail-Followup-To: Brian E Carpenter <brc@zurich.ibm.com>,
	Brian Haberman <brian@innovationslab.net>,
	Margaret Wasserman <margaret@thingmagic.com>,
	Bob Hinden <bob.hinden@nokia.com>, IPv6 WG <ipv6@ietf.org>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
	<853acce3627cabf053004a5206ffd526@innovationslab.net>
	<425E5C19.1050001@zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <425E5C19.1050001@zurich.ibm.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more
	information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: Margaret Wasserman <margaret@thingmagic.com>, IPv6 WG <ipv6@ietf.org>,
        Brian Haberman <brian@innovationslab.net>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

For info, the copy of the ARIN proposal I have seen says:

"   6.11 Assignments to End-sites with Autonomous System Numbers

     Any  end-site which meets the current criteria for assignment of an
     autonomous  system  number  (ASN)  shall  also qualify for one IPv6
     prefix  assignment  of  the  minimum  size justified under the ARIN
     guidelines  for  assignment by an LIR. If the organization grows to
     require more space, it will not be entitled to an additional block,
     but  rather  may obtain a new, replacement block of sufficient size
     to  meet  its needs in exchange for making the commitment to return
     its existing block within 24 months, so that it may be reassigned."

Presumably if the end-site wishes to route the /32(?) globally as PI then
it is probably likely to need an ASN anyway?   

But it could be a /48, as per the IX allocations, presumably?

Tim

On Thu, Apr 14, 2005 at 02:03:37PM +0200, Brian E Carpenter wrote:
> I agree that this is the best approach right now.
> 
>    Brian C
> 
> Brian Haberman wrote:
> >IPv6 WG,
> >     This is a status update on the centrally-allocated ULAs defined in
> >draft-ietf-ipv6-ula-central-01.txt.  At this time the chairs believe it
> >is prudent to gain operational experience with the locally-assigned
> >ULA specification (which is currently in the RFC Editor's Queue)
> >before continuing work on the centrally-allocated mechanism.
> >
> >     The chairs would like to solicit input from WG members on this
> >approach.  Please state your support or disagreement with this
> >approach.  Those who disagree, please state rationale for wanting
> >to continue this work at this time.
> >
> >Regards,
> >Brian & Bob
> >IPv6 WG co-chairs
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Tim/::1



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr 15 04:34:25 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06698
	for <ipngwg-archive@lists.ietf.org>; Fri, 15 Apr 2005 04:34:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMM9o-0001pX-2J; Fri, 15 Apr 2005 04:26:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMM9b-0001kk-49
	for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 04:26:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05939
	for <ipv6@ietf.org>; Fri, 15 Apr 2005 04:26:17 -0400 (EDT)
Received: from raven.ecs.soton.ac.uk ([152.78.70.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMMJk-0003HM-Oe
	for ipv6@ietf.org; Fri, 15 Apr 2005 04:36:49 -0400
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
	j3F8QDi3007354; Fri, 15 Apr 2005 09:26:13 +0100 (BST)
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 JAA00271;
	Fri, 15 Apr 2005 09:26:09 +0100 (BST)
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3F8Q9R12826;
	Fri, 15 Apr 2005 09:26:09 +0100
Date: Fri, 15 Apr 2005 09:26:09 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: Stephen Sprunk <stephen@sprunk.org>,
        Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>,
        Margaret Wasserman <margaret@thingmagic.com>,
        Bob Hinden <bob.hinden@nokia.com>
Message-ID: <20050415082609.GL10920@login.ecs.soton.ac.uk>
Mail-Followup-To: Stephen Sprunk <stephen@sprunk.org>,
	Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>,
	Margaret Wasserman <margaret@thingmagic.com>,
	Bob Hinden <bob.hinden@nokia.com>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>
	<853acce3627cabf053004a5206ffd526@innovationslab.net>
	<005001c54118$e77bd4c0$6c0016ac@ssprunk>
	<20050415075226.GG10920@login.ecs.soton.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050415075226.GG10920@login.ecs.soton.ac.uk>
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: 7655788c23eb79e336f5f8ba8bce7906
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown wrote:
> On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote:
> > 
> > I also believe that we should be watching the IPv6 PI policy proposal at
> > ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I
> > see little reason to continue work on centrally-assigned ULAs.
> 
> I disagree.  The ARIN proposal seems to be 'PI for any ASN holder' in which
> case
> 
> a) this will limit who gets the PI space to large organisations
> b) be limited by the 16-bit ASN space (and may create a land rush)
> c) be useless to the small end site that wants to use unique ULAs
> 
> But I may have misunderstood the ARIN proposal :)

Following up to myself, the proposal in fact says 'sites who could qualify 
for an ASN'.   But that does limit who could use this source for PI.

-- 
Tim/::1



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr 15 08:56:11 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27181
	for <ipngwg-archive@lists.ietf.org>; Fri, 15 Apr 2005 08:56:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMQ9n-0008NK-1b; Fri, 15 Apr 2005 08:42:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQ9k-0008LF-Tj
	for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 08:42:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26476
	for <ipv6@ietf.org>; Fri, 15 Apr 2005 08:42:43 -0400 (EDT)
Received: from web61102.mail.yahoo.com ([216.155.196.104])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMQJv-0004ca-Gi
	for ipv6@ietf.org; Fri, 15 Apr 2005 08:53:17 -0400
Received: (qmail 4570 invoked by uid 60001); 15 Apr 2005 12:42:33 -0000
Message-ID: <20050415124233.4568.qmail@web61102.mail.yahoo.com>
Received: from [192.116.98.51] by web61102.mail.yahoo.com via HTTP;
	Fri, 15 Apr 2005 13:42:33 BST
Date: Fri, 15 Apr 2005 13:42:33 +0100 (BST)
From: Doo Timbir <doo090@yahoo.ie>
To: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 8bit
Cc: ipv6@ietf.org
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 8bit

Dear All,

I totally agree with Tim Chown's observation.The issue
of ostracisation or betterstil limitations to who
gains access to the afore-mentioned should be
citically looked into.

Sincerely,

Doo Timbir.


--- Tim Chown <tjc@ecs.soton.ac.uk> wrote:
> On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown
> wrote:
> > On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen
> Sprunk wrote:
> > > 
> > > I also believe that we should be watching the
> IPv6 PI policy proposal at
> > > ARIN et al; if the ARIN proposal is approved
> (and other RIRs follow suit), I
> > > see little reason to continue work on
> centrally-assigned ULAs.
> > 
> > I disagree.  The ARIN proposal seems to be 'PI for
> any ASN holder' in which
> > case
> > 
> > a) this will limit who gets the PI space to large
> organisations
> > b) be limited by the 16-bit ASN space (and may
> create a land rush)
> > c) be useless to the small end site that wants to
> use unique ULAs
> > 
> > But I may have misunderstood the ARIN proposal :)
> 
> Following up to myself, the proposal in fact says
> 'sites who could qualify 
> for an ASN'.   But that does limit who could use
> this source for PI.
> 
> -- 
> Tim/::1
> 
> 
> 
>
--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
>
--------------------------------------------------------------------
> 

Send instant messages to your online friends http://uk.messenger.yahoo.com 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr 15 09:04:53 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28159
	for <ipngwg-archive@lists.ietf.org>; Fri, 15 Apr 2005 09:04:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMQBw-0000NM-1r; Fri, 15 Apr 2005 08:45:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQBu-0000N1-2f
	for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 08:44:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26607
	for <ipv6@ietf.org>; Fri, 15 Apr 2005 08:44:49 -0400 (EDT)
Received: from web61109.mail.yahoo.com ([216.155.196.111])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMQLx-0004i6-FX
	for ipv6@ietf.org; Fri, 15 Apr 2005 08:55:22 -0400
Received: (qmail 40906 invoked by uid 60001); 15 Apr 2005 12:44:37 -0000
Message-ID: <20050415124437.40904.qmail@web61109.mail.yahoo.com>
Received: from [192.116.98.51] by web61109.mail.yahoo.com via HTTP;
	Fri, 15 Apr 2005 13:44:36 BST
Date: Fri, 15 Apr 2005 13:44:36 +0100 (BST)
From: Doo Timbir <doo090@yahoo.ie>
To: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.9 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 8bit
Cc: ipv6@ietf.org, hemanth@india.hp.com
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 8bit

Dear All,

I totally agree with Tim Chown's observation.The issue
of ostracisation or betterstil limitations to who
gains access to the afore-mentioned should be
citically looked into.

Sincerely,

Doo Timbir.
08036577004[mob.]


--- Tim Chown <tjc@ecs.soton.ac.uk> wrote:
> On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown
> wrote:
> > On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen
> Sprunk wrote:
> > > 
> > > I also believe that we should be watching the
> IPv6 PI policy proposal at
> > > ARIN et al; if the ARIN proposal is approved
> (and other RIRs follow suit), I
> > > see little reason to continue work on
> centrally-assigned ULAs.
> > 
> > I disagree.  The ARIN proposal seems to be 'PI for
> any ASN holder' in which
> > case
> > 
> > a) this will limit who gets the PI space to large
> organisations
> > b) be limited by the 16-bit ASN space (and may
> create a land rush)
> > c) be useless to the small end site that wants to
> use unique ULAs
> > 
> > But I may have misunderstood the ARIN proposal :)
> 
> Following up to myself, the proposal in fact says
> 'sites who could qualify 
> for an ASN'.   But that does limit who could use
> this source for PI.
> 
> -- 
> Tim/::1
> 
> 
> 
>
--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
>
--------------------------------------------------------------------
> 

Send instant messages to your online friends http://uk.messenger.yahoo.com 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From ipv6-bounces@ietf.org  Fri Apr 15 09:31:42 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29988
	for <ipngwg-archive@lists.ietf.org>; Fri, 15 Apr 2005 09:31:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMQf4-00078n-Cs; Fri, 15 Apr 2005 09:15:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQf0-000772-OT
	for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 09:15:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28921
	for <ipv6@ietf.org>; Fri, 15 Apr 2005 09:14:53 -0400 (EDT)
Received: from mtagate1.uk.ibm.com ([195.212.29.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMQp3-0005s7-Rf
	for ipv6@ietf.org; Fri, 15 Apr 2005 09:25:27 -0400
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j3FDDSXJ211070
	for <ipv6@ietf.org>; Fri, 15 Apr 2005 13:13:30 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com
	[9.149.37.216])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j3FDDSVj279612 for <ipv6@ietf.org>; Fri, 15 Apr 2005 14:13:28 +0100
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	j3FDDRCs031114 for <ipv6@ietf.org>; Fri, 15 Apr 2005 14:13:27 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	j3FDDQMx031086; Fri, 15 Apr 2005 14:13:27 +0100
Received: from zurich.ibm.com (sig-9-146-219-97.de.ibm.com [9.146.219.97])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA99940;
	Fri, 15 Apr 2005 15:13:25 +0200
Message-ID: <425FBDF3.80408@zurich.ibm.com>
Date: Fri, 15 Apr 2005 15:13:23 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Tim Chown <tjc@ecs.soton.ac.uk>
References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com>	<853acce3627cabf053004a5206ffd526@innovationslab.net>	<005001c54118$e77bd4c0$6c0016ac@ssprunk>	<20050415075226.GG10920@login.ecs.soton.ac.uk>
	<20050415082609.GL10920@login.ecs.soton.ac.uk>
In-Reply-To: <20050415082609.GL10920@login.ecs.soton.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: Stephen Sprunk <stephen@sprunk.org>,
        Margaret Wasserman <margaret@thingmagic.com>,
        Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>,
        Bob Hinden <bob.hinden@nokia.com>
Subject: Re: IPv6 WG Consensus call: 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\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Tim Chown wrote:
> On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown wrote:
> 
>>On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote:
>>
>>>I also believe that we should be watching the IPv6 PI policy proposal at
>>>ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I
>>>see little reason to continue work on centrally-assigned ULAs.
>>
>>I disagree.  The ARIN proposal seems to be 'PI for any ASN holder' in which
>>case
>>
>>a) this will limit who gets the PI space to large organisations
>>b) be limited by the 16-bit ASN space (and may create a land rush)
>>c) be useless to the small end site that wants to use unique ULAs
>>
>>But I may have misunderstood the ARIN proposal :)
> 
> 
> Following up to myself, the proposal in fact says 'sites who could qualify 
> for an ASN'.   But that does limit who could use this source for PI.

Well yes, but ULAs aren't actually PI space anyway (in the sense of
routeable PI space), so I think this is all a bit orthogonal to
the proposal to simply watch what happens with locally assigned ULAs.

    Brian


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From rodiguez@mailAccount.com  Fri Apr 15 17:43: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 RAA01145;
	Fri, 15 Apr 2005 17:43:37 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYlT-0003Wd-KO; Fri, 15 Apr 2005 17:54:16 -0400
Received: from c529c6215.cable.wanadoo.nl ([82.156.98.21])
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1DMYb7-0006Nf-S1; Fri, 15 Apr 2005 17:43:34 -0400
X-Apparently-To: ipngwg-archive@ietf.org
X-Sieve: CMU Sieve 2.2
Received: from burial.psychopathic.pochta.ru ([unix socket])
         by beauregard.sadist.pochta.ru (Cyrus v2.2.1) with LMTPA;
         Fri, 15 Apr 2005 19:41:00 -0300
Date: Sat, 16 Apr 2005 04:34:00 +0600
From: "John Mora" <rodiguez@mailAccount.com>
Message-Id: <CFE0.AA79.9A61-003001298B8C@mac.com>
X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru
To: ipngwg-archive@ietf.org
Cc: ipo-archive@ietf.org, iporpr@ietf.org, iporpr-admin@ietf.org,
        iporpr-web-archive@ietf.org, ipoverib@ietf.org,
        ipoverib-admin@ietf.org, ipoverib-web-archive@ietf.org,
        ipping@ietf.org, ippm@ietf.org, ippm-admin@ietf.org,
        ippm-archive@ietf.org, ippm-web-archive@ietf.org, ipr@ietf.org,
        ipr-wg@ietf.org
Subject: Notification: We offer low rates
X-Mailer: Forte Agent 1.91/32.564
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.n0wwewillsave.com/sign.asp



 Best Regards,

 Chasity Cooper
 
 to be remov(ed:	http://www.n0wwewillsave.com/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.