From owner-v6ops@ops.ietf.org  Thu Apr  1 06:02:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05962
	for <v6ops-archive@lists.ietf.org>; Thu, 1 Apr 2004 06:02:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B8zvA-000FAd-QE
	for v6ops-data@psg.com; Thu, 01 Apr 2004 10:59:40 +0000
Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B8zv8-000FAH-QC
	for v6ops@ops.ietf.org; Thu, 01 Apr 2004 11:59:38 +0100
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31AxcqY012648
	for <v6ops@ops.ietf.org>; Thu, 1 Apr 2004 12:59:38 +0200 (MEST)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 1 Apr 2004 12:59:37 +0200
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id H8F44MRG; Thu, 1 Apr 2004 12:59:37 +0200
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY90D84>; Thu, 1 Apr 2004 12:59:37 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E39A@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 548f5213 2c4885b5 c2dda0f6 00000138
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Fred Templin'" <osprey67@yahoo.com>
Cc: "'Pekka Savola'" <pekkas@netcore.fi>,
        IPv6 Operations
	 <v6ops@ops.ietf.org>
Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a
	  lter natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-
	0 9 .txt] ]
Date: Thu, 1 Apr 2004 12:59:07 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C417D8.5A696512"
X-OriginalArrivalTime: 01 Apr 2004 10:59:37.0951 (UTC) FILETIME=[6CD54EF0:01C417D8]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C417D8.5A696512
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Fred Templin [mailto:osprey67@yahoo.com]
Sent: 31. marts 2004 16:48
To: Karen E. Nielsen (AH/TED); 'Fred Templin'
Cc: 'Pekka Savola'; IPv6 Operations; 'JORDI PALET MARTINEZ'
Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ]


Karen,
 
OK, if you must know it then I believe it is possible to run both 6to4 and
ISATAP from a single interface. Let's say a node wants to send a packet
to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that
is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting
for the moment that 192.1.2.3 is non-global and used only as example).
If the node has, e.g., a route in its routing table such as:
 
   2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0)
 
then the packet will go out the isatap0 interface using ISATAP encapsulation
based on the link-local ISATAP address from the routing table as the next-hop
toward the 6to4 router, and the 6to4 router will be unable to tell whether the
encapsulator used 6to4 or ISATAP.
 
In other words, if we view each 6to4 router as also an ISATAP router with a
link-local address on the "site" that includes the global IPv4 Internet, then it
really makes no difference whether we use a 6to4 interface or an ISATAP
interface for sending the packet.
 
In terms of receiving packets, if we view every global IPv4 address as a
"Potential Router", then the ISATAP decapsulation checks amount to
exactly the same (optional) checks suggested for 6to4 and, again, either
interface could be used to receive the packet with no differences.
 
This however takes us away from the simple and "secure" host-to-router usage of Isatap
in which IPv6 ingress filtering is achieved from networks where Ipv4 spoofing is prevented (of
which 3G is a prime example).
 
The fact that Isatap in host-router usage scenarios doesn't have the "relay-spoofing"/Ipv6 ingress filtering problems that 6to4 has, is one of the beauties of this simplitic usage
of Isatap and is in my opinion a strenght that should not be weakened.
 
I think that I would rather see good mechs with a set of, perhaps rigid, rules for how 
the various mechsnism should interact, than lowering the mechs to the lowest denominator in order
to make them all interact - but yes I also understand why this standpoint is arguable.
 
BR, Karen


------_=_NextPart_001_01C417D8.5A696512
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Fred Templin 
  [mailto:osprey67@yahoo.com]<BR><B>Sent:</B> 31. marts 2004 16:48<BR><B>To:</B> 
  Karen E. Nielsen (AH/TED); 'Fred Templin'<BR><B>Cc:</B> 'Pekka Savola'; IPv6 
  Operations; 'JORDI PALET MARTINEZ'<BR><B>Subject:</B> RE: ISATAP, v6inv4 and 
  6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments 
  on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ]<BR><BR></FONT></DIV>
  <DIV>Karen,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>OK, if you must know it then I believe it is possible to run both 6to4 
  and</DIV>
  <DIV>ISATAP from a single interface. Let's say a node wants to send a 
  packet</DIV>
  <DIV>to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node 
  that</DIV>
  <DIV>is reached via a 6to4 router with unicast IP address 192.1.2.3 
  (neglecting</DIV>
  <DIV>for the moment that 192.1.2.3 is non-global and used only as 
  example).</DIV>
  <DIV>If the node has, e.g.,&nbsp;a route in its routing table such as:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp; 2002:C001:0203::/48 -&gt; fe80::0200:5EFE:C001:0203 (via 
  isatap0)</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>then the packet will go out the isatap0 interface using ISATAP 
  encapsulation</DIV>
  <DIV>based on the link-local ISATAP address from the routing table as the 
  next-hop</DIV>
  <DIV>toward the 6to4 router, and the 6to4 router will be unable to tell 
  whether the</DIV>
  <DIV>encapsulator used 6to4 or ISATAP.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In other words, if we view each 6to4 router as also an ISATAP router with 
  a</DIV>
  <DIV>link-local address on the "site" that includes the global IPv4 Internet, 
  then it</DIV>
  <DIV>really makes no difference whether we use a 6to4 interface or an 
  ISATAP</DIV>
  <DIV>interface for sending the packet.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In terms of receiving packets, if we view every global IPv4 address as 
  a</DIV>
  <DIV>"Potential Router", then the ISATAP decapsulation checks amount to</DIV>
  <DIV>exactly the same (optional) checks suggested for 6to4 and, again, 
  either</DIV>
  <DIV>interface could be used to receive the packet with no differences.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>This 
  however takes us away from the simple and "secure" host-to-router usage of 
  Isatap</FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>in 
  which IPv6 ingress filtering is achieved from networks where Ipv4 spoofing is 
  prevented (of</FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff 
  size=2>which 3G is a prime example).</FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>The 
  fact that Isatap in host-router usage scenarios doesn't have the 
  "relay-spoofing"/Ipv6 ingress filtering problems&nbsp;</FONT></SPAN><SPAN 
  class=411051610-01042004><FONT face=Arial color=#0000ff size=2>that 6to4 has, 
  is&nbsp;one of&nbsp;the beauties of this simplitic usage</FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>of 
  Isatap and is in my opinion a strenght that should not be 
  weakened.</FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>I 
  think that I would rather see good mechs with a set of, perhaps rigid, rules 
  for how </FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>the 
  various mechsnism should interact, than lowering the mechs to the lowest 
  denominator in order</FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>to 
  make them all interact - but yes I also understand why this standpoint is 
  arguable.</FONT></SPAN></DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=411051610-01042004><FONT face=Arial color=#0000ff size=2>BR, 
  Karen</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C417D8.5A696512--



From owner-v6ops@ops.ietf.org  Thu Apr  1 09:10:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14001
	for <v6ops-archive@lists.ietf.org>; Thu, 1 Apr 2004 09:10:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B92rF-000Myb-H1
	for v6ops-data@psg.com; Thu, 01 Apr 2004 14:07:49 +0000
Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B92r2-000Mxh-Eh
	for v6ops@ops.ietf.org; Thu, 01 Apr 2004 15:07:36 +0100
Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1B92r1-0003Oe-00
	for v6ops@ops.ietf.org; Thu, 01 Apr 2004 15:07:35 +0100
Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1B92r1-0003OZ-00
	for v6ops@ops.ietf.org; Thu, 01 Apr 2004 15:07:35 +0100
Received: from zurich.ibm.com (sig-9-145-243-141.de.ibm.com [9.145.243.141])
	by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i31E7ZF97130
	for <v6ops@ops.ietf.org>; Thu, 1 Apr 2004 15:07:35 +0100
Message-ID: <406C223B.6AB75BC5@zurich.ibm.com>
Date: Thu, 01 Apr 2004 16:07:55 +0200
From: Brian E Carpenter <brc@zurich.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: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a  lter 
 natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-0 9 
 .txt] ]
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fred Templin wrote:

> Karen,
>  
> OK, if you must know it then I believe it is possible to run both 6to4 and
> ISATAP from a single interface. Let's say a node wants to send a packet
> to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that
> is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting
> for the moment that 192.1.2.3 is non-global and used only as example).
> If the node has, e.g., a route in its routing table such as:
>  
>    2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0)
>  
> then the packet will go out the isatap0 interface using ISATAP encapsulation
> based on the link-local ISATAP address from the routing table as the next-hop
> toward the 6to4 router, and the 6to4 router will be unable to tell whether the
> encapsulator used 6to4 or ISATAP.

Well, I've read this and the followups, and I am still confused.

The intended domain of utilisation of 6to4 is for giving sites that don't
have an IPv6 SP a backdoor into the IPv6 world (and a free /48 to go with it).
[In the degenerate case, the site is a single host connected to an IPv4 SP.]

As I understand it, the intended domain of utilisation of ISATAP is
to provide internal connectivity within a site that has an IPv6 SP but
doesn't have a dual stack internal network.

That being so, I just can't see a useful scenario where what Fred describes
can happen. Can somebody draw me a picture? [Emphasis on the word "useful."]

   Brian

>  
> In other words, if we view each 6to4 router as also an ISATAP router with a
> link-local address on the "site" that includes the global IPv4 Internet, then it
> really makes no difference whether we use a 6to4 interface or an ISATAP
> interface for sending the packet.
>  
> In terms of receiving packets, if we view every global IPv4 address as a
> "Potential Router", then the ISATAP decapsulation checks amount to
> exactly the same (optional) checks suggested for 6to4 and, again, either
> interface could be used to receive the packet with no differences.
>  
> The difference comes when operational deployments will begin to use
> non-6to4 global IPv6 prefixes, in which case sending nodes will need to,
> e.g., add routes such as:
>  
>    3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0)
>  
> Then, the ISATAP router at 192.1.2.3 will appear the same as
> if it were a 6to4 relay router that relays from the 6to4 domain to the
> 3FFE:EXAMPLE::/48 prefix space. Sending nodes will most likely use
> the DNS to discover the IPv6 prefix to global IPv4 address mappings for
> destinations of interest, and so there really would be no need for running
> a BGP-style routing protocol between the ISATAP routers (that are really
> acting as 6to4 relay router equivalents). In this case, however, the only
> choice would be to use an ISATAP interface, since 6to4 interfaces only
> encapsulate packets sent to a 2002:EXAMPLE::48 prefix.
>  
> So, I guess that would make the ISATAP interface as the LCD that
> needs to be there in any case, and configuring a 6to4 interface also
> on the same node (and over the same IPv4 address) could be viewed
> as optional. This is not by way of saying that ISATAP is in any way
> obsoleting 6to4, but rather the 6to4 and non-6to4 prefix space can
> be consolidated into a single automatic tunnel interface footprint
> (instead of two) if desired.
>  
> Fred



-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM



From owner-v6ops@ops.ietf.org  Thu Apr  1 13:35:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25177
	for <v6ops-archive@lists.ietf.org>; Thu, 1 Apr 2004 13:35:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B96xw-0005y3-Fp
	for v6ops-data@psg.com; Thu, 01 Apr 2004 18:31:00 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B96xR-0005tL-Ma
	for v6ops@ops.ietf.org; Thu, 01 Apr 2004 19:30:29 +0100
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i31ITmB15502;
	Thu, 1 Apr 2004 21:29:48 +0300
Date: Thu, 1 Apr 2004 21:29:48 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: david.kessens@nokia.com
cc: bwijnen@lucent.com, <iesg-secretary@ietf.org>, <v6ops@ops.ietf.org>
Subject: Request to Advance "Application Aspects of IPv6 Transition"
Message-ID: <Pine.LNX.4.44.0404012123430.15222-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

David,

On behalf of the v6ops WG, we'd like to request that the following
document be published as Informational RFC:

Application Aspects of IPv6 Transition
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-02.txt

The working group last call for this document was completed on 20th
March, and the raised issues (only few) have been resolved.  Many WG
participants have stated that this is important work that is already
in good condition and needs to go forward.

Thanks,
 Pekka & Jonne
 v6ops WG co-chairs




From owner-v6ops@ops.ietf.org  Thu Apr  1 15:19:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29497
	for <v6ops-archive@lists.ietf.org>; Thu, 1 Apr 2004 15:19:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B98cW-000MAl-N7
	for v6ops-data@psg.com; Thu, 01 Apr 2004 20:17:00 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B98cB-000M8g-7c
	for v6ops@ops.ietf.org; Thu, 01 Apr 2004 21:16:39 +0100
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i31KGU302467;
	Thu, 1 Apr 2004 12:16:30 -0800
X-mProtect: <200404012016> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdbgxzhb; Thu, 01 Apr 2004 12:16:28 PST
Message-ID: <406C78AA.3010104@iprg.nokia.com>
Date: Thu, 01 Apr 2004 12:16:42 -0800
From: Fred 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: Pekka Savola <pekkas@netcore.fi>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a
  lter natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-0
 9 .txt] ]
References: <Pine.LNX.4.44.0404010752420.1681-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



Pekka Savola wrote:

>On Wed, 31 Mar 2004, Fred Templin wrote:
>  
>
>>>But it should be obvious that this doesn't really provide much of 
>>>practical mitigation, as v4 addresses can be spoofed, or you could 
>>>just use a real v4 address.  This check is most attractive inside a 
>>>site, where it's reasonable to assume that ingress filtering is in 
>>>place .. and the "everyone in PRL list" is definitely not that case.
>>>      
>>>
>>I didn't quite catch what you meant by "a real v4 address"?
>>    
>>
>
>The check only protects from someone spoofing their v4 address.  If 
>the use of link-locals by strangers (remember that these have TTL=255 
>and are allowed to do anything Neighbor Discovery -wise) is 
>categorically thought to be harmful (I certainly think so), this 
>doesn't really help.
>

Right, but this is an issue for the upper layers (e.g., ND handling code).

>>>(The only difference, still, with 6to4 is that the similar abuse of 
>>>6to4 is limited to global addresses -- not link-locals, even if the 
>>>v4addr matched.)
>>>      
>>>
>>In terms of link-locals, the first-pass filtering by the ISATAP decapsulator
>>is only for the purpose of determining whether the IPv4 source address in
>>the encapsulating header is acceptable for the IPv6 source address in the
>>encapsualted packet. Higher layers up the stack will also likely use other
>>mitigations in determining whether/not to accept link-local packets, but
>>this is beyond the scope of our discussion on decapsulation.
>>    
>>
>
>Of course, but as LL's are treated specially e.g. by ND code, this 
>makes the ISATAP decapsulation non-equivalent to 6to4 decapsulation.
>  
>
I'm not sure what you mean by this; ND handling code comes *after*
decapsulation; not during - correct? The only mitigations specified
by 6to4 for decapsulation are found in the second paragraph of
([RFC3056], section 10) and these are optional.

The final sentence of that paragraph says: "2002:: traffic must also
be excepted from checks applied to prevent spoofing of "6 over 4"
traffic [6OVER4]." Perhaps a similar sentence with
s/6over4/ISATAP is needed somewhere?

Fred
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Thu Apr  1 18:03:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06518
	for <v6ops-archive@lists.ietf.org>; Thu, 1 Apr 2004 18:03:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9B9l-000JGt-Ro
	for v6ops-data@psg.com; Thu, 01 Apr 2004 22:59:29 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9B9k-000JGW-KT
	for v6ops@ops.ietf.org; Thu, 01 Apr 2004 23:59:28 +0100
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i31MxC006433;
	Thu, 1 Apr 2004 14:59:12 -0800
X-mProtect: <200404012259> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdOpirvf; Thu, 01 Apr 2004 14:59:11 PST
Message-ID: <406C9ECD.3080000@iprg.nokia.com>
Date: Thu, 01 Apr 2004 14:59:25 -0800
From: Fred 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: Ralph Droms <rdroms@cisco.com>
CC: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
Subject: Re: DHCP auth in unmanaged [Re: WG Last Call:  draft-ietf-v6ops-unmaneval-01.txt]
References: <4.3.2.7.2.20040324164856.02993b18@flask.cisco.com> <4.3.2.7.2.20040325084437.027e9520@flask.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Ralph,

Ralph Droms wrote:

> 4.1.2   Explicit prefix delegation
>
>    Several networks have already started using an explicit prefix
>    delegation mechanism using DHCPv6 [RFC3633]. In this mechanism, the
>    gateway uses a DHCP request to obtain a prefix from a DHCP server
>    managed by the ISP. The DHCP server identifies the gateway, for
>    example, through identification information provided by the gateway
>    in the DHCP request message or by the port or circuit through which
>    the DHCP request message is received.  The server can implement
>    prefix delegation policies based on the identity of the requesting
>    gateway.  According to the recommendations in RFCxxxx the ISP
>    assigns a /48 to the customer. The gateway then automatically
>    assign /64s out of this /48 to its internal links.
>
> (Editorial notes:
>  * I don't think the acronym "ISP" is defined anywhere in the document
>  * There doesn't seem to be a citation of RFC 3315 anywhere in the 
> document
>  * There should be citations of RFC 2131 and RFC 2132 for DHCPv4)
>
>    Security issues associated with DHCP and prefix delegation are
>    addressed in the "Security Considerations" section of RFC 3315
>    and RFC 3633, respectively.


No problem from my end with these suggestions; I believe RFC3177
may be the one you were looking for where you say: "RFCxxxx"?

> 4.1.3   Recommendation
>
>    The ND proxy and DHCP methods appear to have different domains of
>    application. ND proxy is a simple method that corresponds well to
>    "informal sharing" of a link, while explicit delegation provides
>    strong administrative control. The ND proxy mechanism has not yet
>    been accepted as an Internet Standard and the interaction
>    between neighbor discovery and ND proxy needs to be specified.


The thing that causes me to scratch my head and wonder is whenever I see
ND proxy and DHCP presented as competing (rather than complimentary)
functions.

I can see how a node that boots up in administrative domain A
will need to obtain autoconfiguration info; possibly to include prefix
delegtions from DHCPv6, etc. (After all, the node may very well have
an entourage of associated hosts for which it needs to provide packet
forwarding, address configuration, and possibly other services.) Then,
the collection of all such nodes and their associated hosts within
administrative domain A would form an arrangement of logical IPv6
subnets, and we have the delegated L3 prefix information to steer
intra-domain communications.

But, to enable peer-to-peer communications between a node within
administrative domain A and a remote node in administrative
domain B, I see the value of NDProxy. Put in loose english terms, I
think it makes sense to do NDProxy from a path that originates within
administrative domain A up to the edge of administrative domain B,
then use the delegated L3 prefix information within administrative
domain B to steer the remainder of the path to the final destination.

There seems to be elements of both routing and bridging mixed up
in this. But, I think it's more from a: "both/and" and not: "either/or"
perspective. In other words, I think this notion of a "brouter" or
"Rbridge" could be a good fit for your DHCPv6 prefix delegation
clients in this scenario.

Fred
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Thu Apr  1 19:03:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11485
	for <v6ops-archive@lists.ietf.org>; Thu, 1 Apr 2004 19:03:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9C7W-0000qG-KO
	for v6ops-data@psg.com; Fri, 02 Apr 2004 00:01:14 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9C7V-0000pz-1W
	for v6ops@ops.ietf.org; Fri, 02 Apr 2004 01:01:13 +0100
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i32011B15450;
	Thu, 1 Apr 2004 16:01:01 -0800
X-mProtect: <200404020001> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd6rPerI; Thu, 01 Apr 2004 16:00:58 PST
Message-ID: <406CAD48.1070301@iprg.nokia.com>
Date: Thu, 01 Apr 2004 16:01:12 -0800
From: Fred 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 <brc@zurich.ibm.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a
  lter  natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-0
 9  .txt] ]
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com> <406C223B.6AB75BC5@zurich.ibm.com>
Content-Type: multipart/mixed;
 boundary="------------050504080802020602080102"
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------050504080802020602080102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Brian E Carpenter wrote:

> Can somebody draw me a picture? [Emphasis on the word "useful."]
>  
>
Brian,

Attached, please find a rough-cut and incomplete picture. It depicts
two administrative domains (A and B), each with a node that is
engaged in a peer-to-peer session (a.com and b.com). Domain A
uses a native IPv6 prefix space and has delegated a portion of the
space to a (b)router upstream from the node "a.com". Domain B
uses a 6to4 prefix space and has delegated portions of the space
to a hierarchically nested pair of (b)routers upstream from node
"b.com".

If the DNS entries for 'a.com' and 'b.com' are populated with AAAA
resource records as shown in the picture, one could view the presence
of the ISATAP-format link local addresses as an unambiguous
indication that the nodes "support the protocol", and could use
the ISATAP link-local address as the IPv6 next-hop toward
the final destination.

The picture shows a stream of packets emanating from a.com towards
b.com (and, similarly, for packets emanating from b.com towards
a.com). These outbound packets would be encapsulated using ISATAP
and it would appear from IPv6's perspective that they are being
"bridged" up to the edge of the remote peer's domain (although there
would still need to be some flavor of NDproxy in operation). Once the
inbound packets hit the edge of the remote peer's domain, the packets
would be decapsulated and steered towards the final destination
within the domain via the delegated IPv6 prefix information.

The question comes when we consider the inbound packets
arriving at the edge of administrative domain B. Does the edge
node use 6to4 or ISATAP to decapsulate the packets. (And, does
it even matter?)

Fred
ftemplin@iprg.nokia.com

--------------050504080802020602080102
Content-Type: application/powerpoint;
 name="6to4tap.ppt"
Content-Disposition: inline;
 filename="6to4tap.ppt"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAQAAAAAA
AAAAEAAAAgAAAAEAAAD+////AAAAAAAAAABdAAAA////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////9////WwAAAP7///8NAAAABQAAAAYAAAAHAAAA
CAAAAAkAAAAKAAAACwAAAAwAAAD+////DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA
AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA
IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAA
AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA
PgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA
AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAA
WQAAAFoAAAD+/////v///4UAAAD9////XwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYA
AABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAA
dAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAFIA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAWAAUA//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAMAk
HnNCGMQBXAAAAIACAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH/////BQAAAP////8AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABREAAAAAAABQAG8AdwBlAHIAUABvAGkA
bgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf//
//8EAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAD5nQAA
AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAoAAIBAQAAAAIAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAXgAAAJxNAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA
AAD+/////v//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////8PAOgD
EQoAAAEA6QMoAAAAYBgAAOAQAACvEAAAYxgAAAUAAAAKAAAAAgAAAAMAAAABAAIAAAAAAQ8A
8gNQAwAALwDID+oAAAAwANIPBAAAAAIAAAAAALoPKAAAABggHCAI/xQwO/9b/wgwCjAMMA4w
EDDl/wT/JAAoAFsAXAB7AGL/4f8QALoPpgAAAAEwAjAM/w7/+zAa/xv/H/8B/5swnDD9MP4w
nTCeMAUw/DAZIB0gCf8VMD3/Xf8JMAswDTAPMBEwsAAwIDIgMyADIeD/Bf9BMEMwRTBHMEkw
YzCDMIUwhzCOMKEwozClMKcwqTDDMOMw5TDnMO4w9TD2MCEAJQApACwALgA6ADsAPwBdAH0A
Yf9j/2T/Zf9n/2j/af9q/2v/bP9t/27/b/9w/57/n/8PANUHfAEAAAAAtw9EAAAAVABpAG0A
ZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA0NOYAdNoSAFzaEgAgKQgwCAAAAAAAAAB02hIA
WccLMAAABAAQALcPRAAAAE4AbwBrAGkAYQAgAFMAYQBuAHMAIABUAGkAdABsAGUAIABTAGUA
bQBpAEIAbwBsAGQAAAAAAAAAdNoSAFnHCzAAaAYiIAC3D0QAAABOAG8AawBpAGEAIABTAGEA
bgBzAAAAVABpAHQAbABlACAAUwBlAABuHvD9EAAAXWZfPvGNeQAzzsBGvhhW/f+JUE5HDQoa
CgAAAA1JSERSAAAAgwAAAFoIAwAAAKxyFbMAAAMAUExURcDAwFpaWmNjY2tra3Nzc4SEhIyM
jJyclOfv3pScjK29nNbnxpy1hMbnrcbetd73zpSthHOMY+f33mNzWkJSOcbnta3OnKXGlISl
c+//597v1s7extbnzrXGrb3erbXWpVJjSpS1hN731tbvzr3Wta3GpXuUc1pzUq3OpZy9lPf/
95ylnOf35+//797v3mNrY8bWxqW1pXuMe2t7a1JjUr3exsbWzq29tYyclMbe1ufv73N7e87e
3sbW1r3W1rXOzqW9vSkxMQAICLXO1q3Gzsbe56W9xtbn75yttc7e54yUnL3O55ytxsbW7629
1qW1zjlCUrXG56293kJKWnOEpSEpOcbW/73O962953uMtXOErb3O/5yt3jlCWq2975yt50JK
YzE5Uq2991pjhHuErWNrjKW191Jae0pSc1pjjEJKa5ScxoyUvXN7pWtznGNrlMbO/62155Sc
zoyUxpyl3oSMvXuEtXuEvWNrnLW995Sc1pyl54SMxnN7tbW9/62196Wt7621/4yU1pyl7+fn
7+/v9/f3/87O1t7e56Wlrb29xpycpXNze+fn997e78bG1r29zqWltYyMnISElL291mtre9bW
9zExOZSUrYSEnLW11lpaa62tzpSUtUJCUqWlzsbG93NzlDExQikpOVJSc0pKayEhMRAQGEJC
Y4yM1oyM3hgYKQgIEAAACHtzxpSMtXNjrWNSpc7G597W787G3tbO52tje1JKYzkxSlJCc1pC
jIRzpWNKlEoxe8a91nNanGNKjFpChCEYMUophL2t1rWlzq2cxkopeykIWqWUvXtjnIxzrYRr
pXNalGtSjFo5hFIxe0opc0IhazkYYzEIY97W5721xpyUpXtzhFpSYxgQIe/n9/fv/9bO3rWt
va2ltZSMnIyElGtjc72tzlJKWjEpOZR7rYxzpSkhMRAIGMa11qWMvefe78a9zqWcrYR7jGNa
a0I5SiEYKUpCSjkxOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5cxjIAAAAB
dFJOUwBA5thmAAAAAWJLR0T/pQfyxQAADY1JREFUeJy1Wn1cU9cZjtaPOutHWTeHdLW1bt2w
MNt1zqKtSNd1thaxSCsECJGaEJRkRqgIMebDYCHQqquzGxVrsiZuwdkVBdwsii0W2oIiHwoB
VAoKCAih/L/zde89N7kJEOj58Qc/OLnnuc/zvM/73iQikf8rGPyEBIMfEfjJmcSFJn6yKSx0
/csvv7ZpU+KWRLh0O3W6LVvi34iMfGnt82tCAZ4fcJnCXln/+mt7tup9LaMufuMf1r4QOtVI
TGHrX//4La3Ps/lLJpOkb9zwx5VrpgZA6PpNvu/c15Kkh68NmSQBr7y4x+/zGUqyN4T7S0dO
6JpNiZMFQJZke/jKsAkjeOUl3RSdT5YsfkfehBCs2SmbWgR6PXS0OnzcCF6YcgRiY3Ic+sXw
+/Fk2ZpICdycrZ46HPEqqX101JEUB8lIH1OSsEhytNEWY1FmxhvFkwUgliQXj5JlU8G/yLY/
7wvCi+nsaw3wRRE2aaZSAojxF4pYIrePssumwDkn8e6LNR/R/Mcx8O2OaHmmRiMxju9YQ4LK
QH5N1HzSygKwS9N2slGrXimIIHgj3wFaQ/EovYpbLSkKg2EsTtIdgL6YtERIAXUBa9oWftar
BeLTdNz9atp3Rj1WRLE0NVNjcN/KLYkNb4w5kdJKI0j06Dbpoe4QQtQCF5R7gkBARqXJ3qrm
pMB+q3KfUL+TuCX4++kCm/R6lSAGR0pctjAGY4IHXsu2Xd7U063luTFbeJdWgAmLQuKti3tC
GLXo3vTuHxnlzLAsr9s8r5qaqPWGQeGJ2G7N9FFPOlaOMCEvMCvF47LF0m0SoXuTpUQISmeP
UnrNXB1jzA0+IFBMUD63ywVQJAsiKLZZ5ZlepAYrPtinGZjbc6Br2RSSNJsPFOK9xe7HR9gs
8jiNTOZzCES5HbzdJwSUOnapKlsPbKCMslModtNKx1IQIhwuaZJ8rwZI4NU7zEJEjEEDWEZl
NrmUVruVR0YKiyKOeKHYGq3SGLbCreOcgSERfxq7SWt5v1MoHG+Tv2oAhOKYJMUOwzhunb8i
AYbdE3oFjcIax1hCIk2Q78iC9z6x8+HaCRqHZsKvAijUKus2AzXyy/w5nbw0VGT6l1+vFOvF
/h7qjmGl6Ol/Ts2l/MYk+50odEowiPU7VCmx45xy+GsfwPBvf06UxccqFNwfdNticK3GT3zo
0z0mCv3PxI9XJVhaR+2smcUKB5vMKfETlSQeYPhq3EO82AiOj7aSvpHG/UNF5RZAMTEMxwGG
xr1jHQ1GwyylIloaY+fyuDWWtyNLaeWS2ipPF2PMyijHWPGjywUYqr/webxRnSaXtrr3o4g0
rfvOdzgUgIx0sdiI6CkWntDYtSF3CcBQ7c2Vst2bU6PsHu0QLrnnbq0+lodCQQSy+dTaaF4+
T/RgdfVXXrqWOrVV6HzAQorgfq0+LsnhuVvqq2SPzV6+BGKo/sIbVGNc+ThZICi0+nekHtt9
MHFs1mzAA9CiscFrfWr1uz25SPDx3pD2TZ3F8wXedqtnzppthp6srm5o+FQYqliy+RO7+xWj
fAxGsgy5S8BAwtrpNfefnUW0aADrvIBoYk2UBwBwU96ZjVcI7PfOxOYHVgMecrEfGhuu1buD
EOt3JXF3FCFlZLbs8wpBb1Qlx1iFQSR7Uvb29BkzVs+cjeuisaHh2rX6//KqQ5bxCTepF1ti
gefL4R8cPp41oSf3yXYp5eXWCI8xP84d74mW6Q/kYx5CMYb6+s+vfMqi0CSt4wBEpZFxMktp
sY6ROBgImIOzMpSqKOkpCoqKhyCtrGga4GEm4wdoiPr6q59fvYhvUkw9XJ0qj9WyvVArM467
I8HBSpul2ZZqKSZAqAajKbSMTJsGeFjN+KGxEWpx9Upl5cW9yBUZLAhpxuTGJciJ2iBPiYEV
zjzOSTLLLcNFXdOGkBacH+rr689dqbxYd0EDBdGq5dZTETGFGr+nRHcgWbu2KXC0GTITbEe/
Hx55jvCwfAnJB8gDIKKurq72wjdZ6HXqDO2k3xBzR6LX70519Dp6ugGGrpbpMyAP5nmMFsAP
VysrK+tqay98/e0O5LwpmlnppUnpPdXb6nIdtVA8zKM8eRVqUVf79dff3v3mdPqUv1GrN+49
2doLVqsL8lAEeOhEdfEY5wcKw/++uXP6Xs1xyRQC0ChOWlsdAAHgwdFjhVoAHmZgLYAfGlBd
1BMtCAYA4vLlN6bkjXOJJjPBesnlcCAaIIZ1SAtSF0w+QAhXoCfPIy3u3rlzD2Ko+u7LTYn+
f4ICV/Zu1UmL1dpjswEQiAeHC3uSZBTJB4zhHOahFvEAiKi5XAUw9FV89tnHb/mTEtnpmjhl
ctKwxWLptvb0XHK1IhDADzZSF5QnG5navFJH/HCXaFH13Xd9Z86cPdtUUlDQVvDmn8dXrDJj
+q5YVec/oqOLioaHy8st3QCDzcXwQLQAPHQCLebgfoH9wNRmLawLrMXNquYvKyoghv5+Z1tb
m8lZ8N5fX39rz56tQvoYZUZJljojdvOJG52FhS1lXV1dRRAE5uES0IL4AdcF9APXL0hOAgx1
XF0wPFScOdPeVNJfUGDKaTMV9Pe/+25Te/uZA+9/8MHfD0ZGfrTx+PENxzds337sww9fPfy3
+zdu5Ofnd3YWDg21tHSVdUEiyi2W763AEC6HCxYG4oH4geoXJCevwNqsZTwJMVRVVfX19Z1p
P1uCeDCZnPv39ze9e7b9wIEDAwN5zc0dHR03b+aar1+/fuv24dt/uX8fgCgFGDqHClsgEZAG
xAOwwyWsBfLD0e+F+8VV0C8qPXmAfmhq6i9wmqAW+zEP7QhDHsJwaHBwEGC4dRtiuAGIKIUY
IA+0FkAMoAXLA5eTxA90vziP/AA8SfzQh/1Q0u905rQ5AYb+piYIoWJg4CCm4WbuoBlAuHX4
9m3IQ35+6RFAw1AhoCG6iGjRjSBwfuhBWgzNIDyE8T3J8HCH4gH5gWjhhQczhODGQxnPk7ZL
2JMgHxw9qG+S2jT/RBTcwGQU4oHxw+k7NTU1IB+gH1BdFLRhLRAI5IeDeR3N4YSH65CH+5Qf
KC2GcT7A2iT54Oo+OlxUNA3PcssXiEQn2XyopPoF4qGD46Ef+gFpwfHQzPBg5vkBEDHEehJp
QXhodcuHIZxRgSLRagoDl5OnSVYP9HH5gLXg/AC1QDwMQhpIXeSXlpbC4kQ8cLUJeKD8gDzZ
grP6RyEi0QpqfqD6BeHhS5yTsC5yhHmAEMzCPAAII9gP3SijHIwfSD50Qh7mwfeKhxrx/HCO
y2qYk8dqamDPYvPBxPDA+CGP4gH5AeeDF09y/aIX5QPqF4CHOYHwDetlDY2MJ7msPo0zCmiB
8qGkwMl6EvEwAGtT0A+l+UeojCoqh5ZEtcn2CxebDwDDEvzZQWfjNeIHrmeR2mwGfZOXk7g2
CQ8dzZgHkJOvAgyzWB6GCof4WkAeGD9gLYpQVs+cE4AxBKUy/aKSmeWwJztwv0B+KOD7oYL4
4WYH4QHnwwlkB8xDVxcOayofcE7i3o3yYeY85oOcoGsNzAxTx8wPd+5BP6B+gbO6zdRG+gXi
4X0IAvvBzPkBaVFK+WGYaGHtcXH9AmYUyAfQN5dwH2g9A7U4R/csMMIgP6B8IJ6k+8UAlw+H
KD/cp+rCrXdDLUi/sIGMGpkGeHiI/ubOcmamPc+fYdh+gbLa6ezHWjB1Af3AaIFyEtoBagH8
UEb8QPoFnGHYeZLU5kOBvA84V5xj+gU1w3RcJnMU7hdIC5BRTTgfUF0ALQZRRlE8dPJykqtN
wgOcJ4/Cuvip+we98y+eY/sF4uE0ysk+WBdNMCdNOSanW100d4Sj+cHM9wPXL7rI/GDFWmA/
9JL5YZE7BJFocT71jINqs6aqiuWB6VnAk4gHti4E5gfsybKusmjCQzfISehJdn4AzxfPLfGE
AAJz2Q1IxAXMwz1mlqsgGUV6FsfDQWaOgvkAa3MWwnAEalHIaDFC9SwmH4AWjzyxWAgC/LB1
FakLrm/2sXXRloMyCs0wmIc8Hg9cVpe6z1FohmHnB/DM+/gKLwiQNU+wfqhh+8VZNMOg2uzf
/x5snPQ8eShXOKvLWqJZPxBPkvlh3c8e9AFBJAr8+apv2fmhinq+8DJHobrgeRLXBQDBzwcb
tkNv77qH5/tEgM25/C47P5DnC6iFk8pqMk9iLXKZrL6NeSiFGeWRD6g2ex2PPDHOLxQufobj
AT1fNLH5gGcYen7g8UByshP3LLpfoNn+kYXjA4DW0mW5xyAPuF+cLSlB84MT1ibrB9g4EQ/m
Qb4feJ4sZ/xgW/fULyaAAK7ggKBlHVQ+sDzw5qhwlgdurj7SSfUL4snupxYu821Ebytk7vyD
bD4QT3LPFySjyBx1+Baeq4/kl7JakOeLkR8vDJrM10oDA4KC2lG/IPMD1zcPYhC8+WE11zfL
0EPOyHMPL3p08t9rDQ5cumDp4qdNJub5AuXkATarcwcF+8X03/z2lwsXzfdPAS9IQgIDlwY8
uJ/UxQD7nHXTvV/k5894Fhy++If6fnFICCBlwZNBQSuDVjTn4XZxyAx796urVs2ZNefXi371
2LJHA37QrzczKzgwJCAwYMGCpXPnLpgbNPfJuU8uDggICPTv7P8DkOSQ4ZkhxTUAAAAASUVO
RK5CYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG0AaQBCAG8AbABkAAAA
AAAAAHTaEgBZxwswAGgGIjAAtw9EAAAATgBvAGsAaQBhACAAUwBhAG4AcwAgAFcAaQBkAGUA
AAAgAFMAZQBtAGkAQgBvAGwAZAAAAAAAAAB02hIAWccLMABoBiJAALcPRAAAAEEAcgBpAGEA
bAAAAFMAYQBuAHMAIABXAGkAZABlAAAAIABTAGUAbQBpAEIAbwBsAGQAAAAAAAAAdNoSAFnH
CzAAaAYiAACkDw4AAACAAGMAAAADAP////8UAAAApQ8OAAAAAAAAGC4AAABaAAIAAAAAAKsP
HgAAAP8fAAAFAOABAAAAAAAAaAFoAdAC0AI4BDgEoAWgBQAAqQ8KAAAABwAAAAIACQQAAEAA
ow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA
////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAA
gASABAAAAAAPAAsE1AMAAA8AAPDMAwAAAAAG8OgCAAACcAEAXAAAAKcAAAAEAAAAAAAAAAkA
AAAEAAAABAAAAAMAAAACAAAAAAAAAAkAAAAAAAAADAAAAAAAAAALAAAAAAAAABcAAAAAAAAA
CAAAAAAAAAAGAAAAAAAAACgAAAAAAAAAIwAAAAAAAAAHAAAAAAAAAA0AAAAAAAAAFgAAAAAA
AAAKAAAAAAAAACgAAAAAAAAAHgAAAAAAAACFAAAAAAAAAB8AAAAAAAAABgAAAAAAAAAbAAAA
AAAAAAYAAAAAAAAABQAAAAAAAAAKAAAAAAAAAAIAAAAAAAAADgAAAAAAAAApAAAAKgAAAAQA
AAAAAAAABAAAACgAAAAEAAAAJwAAAAQAAAAmAAAABAAAACUAAAAEAAAAJAAAAAQAAAAjAAAA
BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA
AAAEAAAAAAAAAAsAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAcAAAAAAAAAQgAAAAAAAAAGAAAA
AAAAAAgAAAAAAAAABgAAAAAAAAApAAAAAQAAABEAAAAAAAAAIwAAAAAAAAASAAAAAAAAAAIA
AAAAAAAAHwAAAAAAAAA5AAAAKQAAAAQAAAAAAAAABgAAAAAAAAAYAAAAAAAAABsAAAAAAAAA
IAAAAAAAAAAUAAAAAAAAABEAAAAAAAAAFgAAAAAAAABjAAAAAAAAADAAAAACAAAAdwAAAAAA
AAAEAAAAAAAAAAcAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAA
AgAAAAgAAAAAAAAACAAAAAAAAAAFAAAAAAAAAAQAAAAVAAAADgAAAAAAAAAEAAAAAAAAAA4A
AAAAAAAACwAAAAAAAAAJAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA
BgAAAAAAAAAFAAAAAAAAAAQAAAAfAAHwLAAAAGIAB/AkAAAABgZdZl8+8Y15ADPOwEa+GFb9
/wAFEQAABQAAAAAAAAAAADYBAwEL8GAAAACAAQAAAACBAQAAAAiDAQAAAAi/ARAAEADAAQEA
AAjBAQAAAQDEAQAAAADLAZwxAADNAQAAAADOAQAAAADQAQAAAADRAQAAAADXAQIAAAD/AQgA
CAABAgIAAAg/AgAAAgCAABrxIAAAAAV07wBnZ2cAqampAPz+uQAGPegAosH+APr9AADA/vkA
QAAe8RAAAAAGPegABgAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAEEAAAAEAAAAAAAAAAIA
AIAAAAAADwDQB9QBAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwD6A2cAAAAAAP4D
AwAAAAAAAAAA/QM0AAAAcAAAAGQAAABwAAAAZAAAACApCDAIAAAAAAAAAGjaEgAAAAAAAAAA
AED///+4////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAAAwDAAAHwD6A0cAAAAA
AP4DAwAAAAABAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAACApCDAIAAAAAAAAAGjaEgAAAAAA
AAAAAAAAAAAAAAAAAQAAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaO6lOzckAypo7AAIAAR8A
BwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAlNoSABviCzCA2hIAFAAAAAAAAAAAAAAA
AAAAAAAAAAAAARIAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAACU2hIAG+ILMIDa
EgAUAAAAAAAAAAAAAAAAAAAAAAAAAAABEgAPAIgTRgAAAA8AihM+AAAAAAC6Dw4AAABfAF8A
XwBQAFAAVAA5AAAAixMgAAAALwDIDwwAAAAwANIPBAAAAIAAAAAAAHoXBAAAAAAEAAA/ANkP
DAAAAAAA2g8EAAAAAAAlAA8A8A8xAAAAAADzAxQAAABTAAAABgAAAAEAAAAVAQAAAAAAAAAA
nw8EAAAAAAAAAAAAqA8BAAAAIAEAAQRQAAAAAAAAAf///38AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAA
AOoDAAAAAA8A+ANqCQAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAAAABgAPAHIAAA
AP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAYADwByAAAAAAAP8A////AAAAAAD/
/wAA/5kAAAD//wD/AAAAlpaWAGAA8AcgAAAA///MAAAAAABmZjMAgIAAADOZMwCAAAAAADPM
AP/MZgBgAPAHIAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICAAE1NTQDq6uoAYADwByAAAAD/
//8AAAAAAICAgAAAAAAA/8xmAAAA/wDMAMwAwMDAAGAA8AcgAAAA////AAAAAACAgIAAAAAA
AMDAwAAAZv8A/wAAAACZAABgAPAHIAAAAP///wAAAAAAgICAAAAAAAAzmf8Amf/MAMwAzACy
srIAAACjDz4AAAABAP/9PwAAACIgAgBkAAAAAAABAFoAAAAAAAAAAADgAQAAAAACAAAA///v
AAAAAQD///////8iAAAAAAEAABAAow+GAAAABQD//T8ABQAiIAIAZAAAAAAEAABaACgAAACx
AAAA4AEAAAAAAgAAAP//7wAAAAMA////////FAAAAAABAABIJQAADQBLAAAApAEpAQAAAAAA
BQAA0wJYAgAAAADsNQAAAQATIGQAAAAAAGQAFABxBMIDAAABAAIAgAUAALsAoAXvBAAAAAAg
AKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAWgAoAAAAAAAAAOABAAAAAAIAAAD//+8AAAAE
AP///////woAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUA
AIAEgAQAAAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAAC
AAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABg
A2ADAAAAAAAFAACABIAEAAAAAFAAow9OAAAABQAAAAEJAAAEAAEAAAAAAAAAAQAACQAAAQAg
AQAAAAACAAAJAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACj
DwwAAAABAAAAAAAAAAAAAABwAKMPQgAAAAUAAAAAAAAAAAACABIAAQAAAQAAKQEAAAIAEgAC
AAABAABYAgAAAgASAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow9CAAAABQAAAAAAAAAA
AAIAEAABAAABAAApAQAAAgAQAAIAAAEAAFgCAAACABAAAwAAAAAAAAACABAABAAAAAAAAAAC
ABAAAAD5AxAAAAAAAAAAAAAAAAALAQAC+QswDwAMBAAFAAAPAALw+AQAABAACPAIAAAABAAA
ABDQAAAPAAPwlgQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA
0AAABQAAAA8ABPAsAQAAEgAK8AgAAAAC0AAAAAoAAAMBC/BgAAAAfwABAAEAgAA0c+YAgQB4
YQEAggCirQAAgwB4YQEAhACirQAAhwABAAAAvwAQAB8AgQEAAAAIgwEAAAAIvwEBABEAwAEB
AAAIywGcMQAA/wEBAAkAAQICAAAIPwIAAAIAEwAi8QYAAAC/AwAAAAQAABDwCAAAAJAAIAEs
F0ACDwAR8BAAAAAAAMMLCAAAAAAAAAABAOYADwAN8HYAAAAAAJ8PBAAAAAAAAAAAAKgPLgAA
AFRpdGxlOiAzNCBwdCBOb2tpYSBTYW5zIFRpdGxlIFNlbWlCb2xkIHJlZ3VsYXIAAKIPBgAA
AC8AAAAAAAAApw8MAAAAAAAAAC8AAAABAAAAAACqDwoAAAAvAAAAAQAAAAAADwAE8EgAAAAS
AArwCAAAAAPQAAAACgAAMwAL8BIAAACBAQBw/wC/AQAAEAD/AQAACAATACLxBgAAAL8DAAAA
BAAAEPAIAAAAEg8gE14XPxAPAATw2gIAABIACvAIAAAABdAAAAAKAADzAAvwWgAAAH8AAQAB
AIAAHHbmAIEAeGEBAIIAoq0AAIMAeGEBAIQAoq0AAL8AEAAfAIEBAAAACIMBAAAACL8BAQAR
AMABAQAACMsBnDEAAP8BAQAJAAECAgAACD8CAAACABMAIvEGAAAAvwMAAAAEAAAQ8AgAAADQ
AiABQBeQDw8AEfAQAAAAAADDCwgAAAABAAAAAgDmAA8ADfAqAgAAAACfDwQAAAABAAAAAACg
D94BAABOAG8AawBpAGEAIABQAG8AdwBlAHIAUABvAGkAbgB0ACAAMgAwADAAMgAgAFQAZQBt
AHAAbABhAHQAZQAgABMgIABKAHUAbAB5ACAAMgAwADAAMgALAEYAbwBuAHQAOgAgAE4AbwBr
AGkAYQAgAFMAYQBuAHMAIABXAGkAZABlACAAMgAwACAAcAB0ACAAKAByAGUAZwB1AGwAYQBy
ACwAIABiAG8AbABkACAAYQBuAGQAIABpAHQAYQBsAGkAYwApAA0AMQBzAHQAIABMAGUAdgBl
AGwAIABCAHUAbABsAGUAdAANADIAbgBkACAATABlAHYAZQBsACAAQgB1AGwAbABlAHQADQAz
AHIAZAAgAEwAZQB2AGUAbAAgAEIAdQBsAGwAZQB0AA0ADQANAA0ADQBDAEgAQQBOAEcARQAg
AFQASABFACAAQwBPAEQARQAgAD0AIABGAGkAbABlACAAbgBhAG0AZQALACgATgBvAGsAaQBh
ACAAUwBhAG4AcwAgAFcAaQBkAGUAIAA4ACAAcAB0ACkAIAALADgAIABjAGgAYQByAGEAYwB0
AGUAcgBzAC4AUABQAFQACwBEAEEAVABFADoAIABkAGQALgBtAG0ALgB5AHkAeQB5AAsAAACi
Dx4AAABzAAAAAAARAAAAAQASAAAAAgABAAAAAQBZAAAAAAAAAKoPCgAAAPAAAAABAAAAAAAP
AATwQgAAABIACvAIAAAAAdAAAAAMAABzAAvwKgAAAIEBAAAACJMBHkCXAJQB3r1oAL8BHgAf
AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACRkZEAAAAAAGGP/QAArgAA/AEo
AM7OzgAgALoPJAAAAEIAbABhAG4AawAgAFAAcgBlAHMAZQBuAHQAYQB0AGkAbwBuAA8A8AOD
AgAAAQDxAwgAAAACAACAAAAMMA8ADARDAgAADwAC8DsCAABAAAjwCAAAAAMAAAADCAAADwAD
8NkBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgAAAUAAAAP
AATwKQEAABIACvAIAAAAAggAAAAKAADzAAvwWgAAAH8AAQABAIAARLD/AYEAEmIBAIIA7a0A
AIMAEmIBAIQA7a0AAL8AEAAfAIEBAAAACIMBAAAACL8BAQARAMABAQAACMsBnDEAAP8BAQAJ
AAECAgAACD8CAAACAAAAEPAIAAAAnws6AnUOphYPABHwEAAAAAAAwwsIAAAAAwAAAAYC/wEP
AA3whwAAAAAAnw8EAAAAAgAAAAAAqA87AAAAQm9keSBUZXh0DVNlY29uZCBMZXZlbA1UaGly
ZCBMZXZlbA1Gb3VydGggTGV2ZWwNRmlmdGggTGV2ZWwAAKIPHgAAAAoAAAAAAA0AAAABAAwA
AAACAA0AAAADAAwAAAAEAAAAqg8KAAAAPAAAAAEAAAAAAA8ABPBwAAAAEgAK8AgAAAADCAAA
AAoAAIMAC/AwAAAAfwAEAAQAhwABAAAAfwEAAAEAvwEBABEAwAEBAAAIywGcMQAA/wEIAAkA
PwIBAAMAAAAQ8AgAAAAfAiwCgg6qCg8AEfAQAAAAAADDCwgAAAACAAAABQD/AQ8ABPBCAAAA
EgAK8AgAAAABCAAAAAwAAHMAC/AqAAAAgQEAAAAIkwEDjmcAlAG5UpcAvwESABIA/wEAAAgA
BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJGRkQAAAAAAYY/9AACuAAD8ASgAzs7OAA8A
yQ/KAAAADwAMBJoAAAAPAALwkgAAADAACPAIAAAAAQAAAAEMAAAPAAPwMAAAAA8ABPAoAAAA
AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAFgAAgAK8AgAAAAADAAABQAAAA8ABPBCAAAAEgAK8AgA
AAABDAAAAAwAAHMAC/AqAAAAgQEAAAAIkwEDjmcAlAG5UpcAvwESABIA/wEAAAgABAMJAAAA
PwMBAAEAEADwByAAAAD///8AAAAAAJGRkQAAAAAAYY/9AACuAAD8ASgAzs7OAA8A7gO9hgAA
AgDvAxgAAAAHAAAADQAAAAAAAAACAACAAAAAAAcAAAAAAPkDEAAAAAAAAAAAAAAAAAsBAAIA
AAAPAAwEVYYAAA8AAvBNhgAAIAAI8AgAAABoAAAAdhABAA8AA/DlhQAADwAE8CgAAAABAAnw
EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAQAQAFAAAADwAE8HgAAAASAArwCAAAAAkQ
AQAgAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAAPCi5gC/AQAAAQD/AQAAAQABAwLQAAAAABDw
CAAAAJAAIAEsF0ACDwAR8BAAAAAAAMMLCAAAAAAAAAANAOYADwAN8AwAAAAAAJ4PBAAAAAAA
AAAPAAPwQhMAAA8ABPB4AAAAAQAJ8BAAAAD1DwAANQwAADUSAAC1DQAAAgAK8AgAAAAPEAEA
AQIAAGMAC/AkAAAABAAAAAAAfwAAAAQAgAEAAAAAgQHM//8AvwEQABAAiAMAAAAAIwAi8QwA
AACPAwAAAACRAwAAAAAAABDwCAAAAAoHOAeIDzgODwAE8CoFAAACAArwCAAAABAQAQACCgAA
8wAL8PoEAABCAUACAABDAYABAABEAQQAAABFwUgCAABGwVICAAB/AQEAAQCAAQAAAACBAfz+
uQCCAQCAAAC/AQAAEADLAWpKAADNAQAAAAD/ARgAGAA/AwAAEACIAwAAAACSAJIA8P80AIAA
KQCCAB8AhQAWAIoADwCRAAkAmAAEAKEAAQCqAAAAtAABALsAAgDCAAgAzgARANkAHQDiABwA
4QAVAOkAEQDyAA4A+wANAAUBDgAQARIAGgEXACMBHgAqAScAMQEwADYBOwA5AUcAOgFKADoB
TgA5AU0AOgFVAEQBXgBOAWgAVgFzAFwBfwBiAYwAZgGZAGgBpwBpAbUAaAHCAGUB0ABhAdwA
WwHbAFwB4gBkAeoAawHyAHEB/AB2AQYBegEQAX4BGwF/ASYBgAE1AX8BQwF8AVABdwFcAXAB
ZwFnAXABXQF3AVIBfAFGAX0BRgGGAUsBkAFOAZsBUAGlAVEBtQFQAcMBTAHQAUUB3AE9AeUB
MgHsASYB8QEZAfMBCwHyAQsBAgIIARECAgEeAvoAKgLwADMC5AA6AtcAPwLJAEACugA/Aq0A
OwKgADUClAAtAogALQKIADICfAAzAm8AMgJkAC8CWgAqAlAAJAJIABwCQAATAjkACQI0AP4B
MAD/ATAA/AEmAPcBHQDwARUA6AEOAN8BCADVAQQAygEBAL8BAACxAQEApAEGAJgBDACNARUA
jgEVAIUBDAB5AQYAbAEBAF8BAABXAQEATwECAEEBCAA0AREAKwEdACsBHgAgARYAFAERAAcB
DQD6AAwA8AANAOYADgDdABEA1QAVAMYAIADAACcAuwAuALsALgCwACkApQAmAJkAJACNACMA
ewAlAGoAKgBbADEATQA7AEIARwA6AFUANQBlADMAdQAzAHoANACAACYBKAECAABAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9Q8AADUM
AAA1EgAAtQ0AAA8ABPA8BQAAAgAK8AgAAAAREAEAAgoAACMBC/AMBQAAQgFAAgAAQwGAAQAA
RAEEAAAARcFIAgAARsFSAgAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAA
xAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAAkgCSAPD/NACAACkA
ggAfAIUAFgCKAA8AkQAJAJgABAChAAEAqgAAALQAAQC7AAIAwgAIAM4AEQDZAB0A4gAcAOEA
FQDpABEA8gAOAPsADQAFAQ4AEAESABoBFwAjAR4AKgEnADEBMAA2ATsAOQFHADoBSgA6AU4A
OQFNADoBVQBEAV4ATgFoAFYBcwBcAX8AYgGMAGYBmQBoAacAaQG1AGgBwgBlAdAAYQHcAFsB
2wBcAeIAZAHqAGsB8gBxAfwAdgEGAXoBEAF+ARsBfwEmAYABNQF/AUMBfAFQAXcBXAFwAWcB
ZwFwAV0BdwFSAXwBRgF9AUYBhgFLAZABTgGbAVABpQFRAbUBUAHDAUwB0AFFAdwBPQHlATIB
7AEmAfEBGQHzAQsB8gELAQICCAERAgIBHgL6ACoC8AAzAuQAOgLXAD8CyQBAAroAPwKtADsC
oAA1ApQALQKIAC0CiAAyAnwAMwJvADICZAAvAloAKgJQACQCSAAcAkAAEwI5AAkCNAD+ATAA
/wEwAPwBJgD3AR0A8AEVAOgBDgDfAQgA1QEEAMoBAQC/AQAAsQEBAKQBBgCYAQwAjQEVAI4B
FQCFAQwAeQEGAGwBAQBfAQAAVwEBAE8BAgBBAQgANAERACsBHQArAR4AIAEWABQBEQAHAQ0A
+gAMAPAADQDmAA4A3QARANUAFQDGACAAwAAnALsALgC7AC4AsAApAKUAJgCZACQAjQAjAHsA
JQBqACoAWwAxAE0AOwBCAEcAOgBVADUAZQAzAHUAMwB6ADQAgAAmASgBAgAAQACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs
AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAPUPAAA1DAAA
NRIAALUNAAAPAATw2gAAAAIACvAIAAAAEhABAAIKAAAjAQvwqgAAAEIBIQAAAEMBBwAAAEQB
BAAAAEXBGAAAAEbBIAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAAAMQB
AAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAYABgDw/wAAAAAHAAMA
DgAFAB0ABwAfAAcAIQAHAA0AEAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArACAAAAP8BAA
AAASEAAAFw0AADMQAAAeDQAADwAE8MIAAAACAArwCAAAABMQAQACCgAAIwEL8JIAAABCAQ4A
AABDAQMAAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAA
EADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA
8P8AAAMABwACAA4AAAAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAQxAAAGsNAABREAAA
bg0AAA8ABPDCAAAAAgAK8AgAAAAUEAEAAgoAACMBC/CSAAAAQgEEAAAAQwERAAAARAEEAAAA
RcEMAAAARsEUAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAA
ywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAAAwADAPD/AAARAAIACQAEAAAA
BwAIAAIAAEAArAEAAKwBAACsAIAAAA/wEAAAAHERAABqDQAAdREAAHsNAAAPAATw+gAAAAIA
CvAIAAAAFRABAAIKAAAjAQvwygAAAEIBLAAAAEMBPwAAAEQBBAAAAEXBKAAAAEbBMAAAAH8B
AQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAAAMsBakoAAM0BAAAAAM4B
AAAAAP8BGAAYAD8DAAAQAIgDAAAAAAoACgDw/ywAPwAsAD8AKwA1ACkAKwAlACIAIAAaABoA
EgASAAsACgAFAAAAAAAVABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA
AKwBAACsAIAAAA/wEAAAALwRAAABDQAA6BEAAEANAAAPAATw0gAAAAIACvAIAAAAFhABAAIK
AAAjAQvwogAAAEIBEwAAAEMBGAAAAEQBBAAAAEXBFAAAAEbBHAAAAH8BAQABAIABAAAAAIEB
/P65AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8D
AAAQAIgDAAAAAAUABQDw/wAAGAAGABMACwANABAABwATAAAACwAMAAIAAEAArAEAAKwBAACs
AQAArAEAAKwAgAAAD/AQAAAADxIAAL0MAAAiEgAA1QwAAA8ABPDKAAAAAgAK8AgAAAAXEAEA
AgoAACMBC/CaAAAAQgEBAAAAQwELAAAARAEEAAAARcEQAAAARsEYAAAAfwEBAAEAgAEAAAAA
gQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgA
PwMAABAAiAMAAAAABAAEAPD/AQALAAEACwABAAYAAAAAAAkADAACAABAAKwBAACsAQAArAEA
AKwAgAAAD/AQAAAA9BEAAGUMAAD1EQAAcAwAAA8ABPDCAAAAAgAK8AgAAAAYEAEAAgoAACMB
C/CSAAAAQgEJAAAAQwEOAAAARAEEAAAARcEMAAAARsEUAAAAfwEBAAEAgAEAAAAAgQH8/rkA
ggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAA
iAMAAAAAAwADAPD/CQAAAAQABwAAAA4ABwAIAAIAAEAArAEAAKwBAACsAIAAAA/wEAAAAHkR
AABKDAAAghEAAFgMAAAPAATwwgAAAAIACvAIAAAAGRABAAIKAAAjAQvwkgAAAEIBBQAAAEMB
DQAAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMAB
AAAAAMQBAAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/wUA
AAACAAYAAAANAAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAAAbEQAAUgwAACARAABfDAAA
DwAE8MIAAAACAArwCAAAABoQAQACCgAAIwEL8JIAAABCAREAAABDAQwAAABEAQQAAABFwQwA
AABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpK
AADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8RAAwACQAGAAAAAAAHAAgA
AgAAQACsAQAArAEAAKwAgAAAD/AQAAAAsBAAAGMMAADBEAAAbwwAAA8ABPDCAAAAAgAK8AgA
AAAbEAEAAgoAACMBC/CSAAAAQgEDAAAAQwEMAAAARAEEAAAARcEMAAAARsEUAAAAfwEBAAEA
gAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA
/wEYABgAPwMAABAAiAMAAAAAAwADAPD/AAAAAAEABgADAAwABwAIAAIAAEAArAEAAKwBAACs
AIAAAA/wEAAAACkQAAC1DAAALBAAAMEMAAAPAATw3QAAAKIMCvAIAAAAHBABAAAKAADDAAvw
SAAAAIAAWLXmAIUAAgAAAIcABgAAAL8AAgACAIEBAAAACIMBAAAACL8BAAAQAMABAQAACMsB
nDEAAP8BAAAIAAECAgAACD8CAAACAAAAEPAIAAAA1AkgCGUOuwoPAA3wZQAAAAAAnw8EAAAA
BAAAAAAAqA8TAAAASVB2NCBiYWNrYm9uZSAoREZaKQAAoQ8YAAAAFAAAAAAAABAAAFoAFAAA
AAAAAwADABQAAACmDxYAAADxHgAA4AFoAWgB0ALQAjgEOASgBaAFDwAE8NAAAAASAArwCAAA
AB0QAQAACgAAswAL8EIAAACAAIS95gCFAAIAAACHAAEAAACBAQAAAAiDAQAAAAi/ARAAEADA
AQEAAAjLAWpKAAD/AQgACAABAgIAAAg/AgAAAgAAABDwCAAAAOADnwfPD8QFDwAN8F4AAAAA
AJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAAAAYAAABAFoAAQAAAAAAAwADABQAAACqDwoAAAAB
AAAAAQAAAAAAAACmDxYAAADxHgAA4AFoAWgB0ALQAjgEOASgBaAFDwAE8NQAAACiDArwCAAA
AB8QAQAACgAAwwAL8EgAAACAAIDG5gCFAAIAAACHAAYAAAC/AAIAAgCBAQAAAAiDAQAAAAi/
AQAAEADAAQEAAAjLAZwxAAD/AQAACAABAgIAAAg/AgAAAgAAABDwCAAAAOMCoQksDcoDDwAN
8FwAAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAEdsb2JhbCBETlMAAKEPGAAAAAsAAAAAAAAQAABa
AAsAAAAAAAMAAwAUAAAApg8WAAAA8R4AAOABaAFoAdAC0AI4BDgEoAWgBQ8AA/BCEwAADwAE
8HgAAAABAAnwEAAAAPUPAAA1DAAANRIAALUNAAACAArwCAAAACAQAQABAgAAYwAL8CQAAAAE
AAAAAAB/AAAABACAAQAAAACBAcz//wC/ARAAEACIAwAAAAAjACLxDAAAAI8DAAAAAJEDAAAA
AAAAEPAIAAAAygnXAc0GIw4PAATwKgUAAAIACvAIAAAAIRABAAIKAADzAAvw+gQAAEIBQAIA
AEMBgAEAAEQBBAAAAEXBSAIAAEbBUgIAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQ
AMsBakoAAM0BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAJIAkgDw/zQAgAApAIIAHwCFABYAigAP
AJEACQCYAAQAoQABAKoAAAC0AAEAuwACAMIACADOABEA2QAdAOIAHADhABUA6QARAPIADgD7
AA0ABQEOABABEgAaARcAIwEeACoBJwAxATAANgE7ADkBRwA6AUoAOgFOADkBTQA6AVUARAFe
AE4BaABWAXMAXAF/AGIBjABmAZkAaAGnAGkBtQBoAcIAZQHQAGEB3ABbAdsAXAHiAGQB6gBr
AfIAcQH8AHYBBgF6ARABfgEbAX8BJgGAATUBfwFDAXwBUAF3AVwBcAFnAWcBcAFdAXcBUgF8
AUYBfQFGAYYBSwGQAU4BmwFQAaUBUQG1AVABwwFMAdABRQHcAT0B5QEyAewBJgHxARkB8wEL
AfIBCwECAggBEQICAR4C+gAqAvAAMwLkADoC1wA/AskAQAK6AD8CrQA7AqAANQKUAC0CiAAt
AogAMgJ8ADMCbwAyAmQALwJaACoCUAAkAkgAHAJAABMCOQAJAjQA/gEwAP8BMAD8ASYA9wEd
APABFQDoAQ4A3wEIANUBBADKAQEAvwEAALEBAQCkAQYAmAEMAI0BFQCOARUAhQEMAHkBBgBs
AQEAXwEAAFcBAQBPAQIAQQEIADQBEQArAR0AKwEeACABFgAUAREABwENAPoADADwAA0A5gAO
AN0AEQDVABUAxgAgAMAAJwC7AC4AuwAuALAAKQClACYAmQAkAI0AIwB7ACUAagAqAFsAMQBN
ADsAQgBHADoAVQA1AGUAMwB1ADMAegA0AIAAJgEoAQIAAEAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAD1DwAANQwAADUSAAC1DQAADwAE
8DwFAAACAArwCAAAACIQAQACCgAAIwEL8AwFAABCAUACAABDAYABAABEAQQAAABFwUgCAABG
wVICAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADN
AQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAACSAJIA8P80AIAAKQCCAB8AhQAWAIoADwCR
AAkAmAAEAKEAAQCqAAAAtAABALsAAgDCAAgAzgARANkAHQDiABwA4QAVAOkAEQDyAA4A+wAN
AAUBDgAQARIAGgEXACMBHgAqAScAMQEwADYBOwA5AUcAOgFKADoBTgA5AU0AOgFVAEQBXgBO
AWgAVgFzAFwBfwBiAYwAZgGZAGgBpwBpAbUAaAHCAGUB0ABhAdwAWwHbAFwB4gBkAeoAawHy
AHEB/AB2AQYBegEQAX4BGwF/ASYBgAE1AX8BQwF8AVABdwFcAXABZwFnAXABXQF3AVIBfAFG
AX0BRgGGAUsBkAFOAZsBUAGlAVEBtQFQAcMBTAHQAUUB3AE9AeUBMgHsASYB8QEZAfMBCwHy
AQsBAgIIARECAgEeAvoAKgLwADMC5AA6AtcAPwLJAEACugA/Aq0AOwKgADUClAAtAogALQKI
ADICfAAzAm8AMgJkAC8CWgAqAlAAJAJIABwCQAATAjkACQI0AP4BMAD/ATAA/AEmAPcBHQDw
ARUA6AEOAN8BCADVAQQAygEBAL8BAACxAQEApAEGAJgBDACNARUAjgEVAIUBDAB5AQYAbAEB
AF8BAABXAQEATwECAEEBCAA0AREAKwEdACsBHgAgARYAFAERAAcBDQD6AAwA8AANAOYADgDd
ABEA1QAVAMYAIADAACcAuwAuALsALgCwACkApQAmAJkAJACNACMAewAlAGoAKgBbADEATQA7
AEIARwA6AFUANQBlADMAdQAzAHoANACAACYBKAECAABAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9Q8AADUMAAA1EgAAtQ0AAA8ABPDa
AAAAAgAK8AgAAAAjEAEAAgoAACMBC/CqAAAAQgEhAAAAQwEHAAAARAEEAAAARcEYAAAARsEg
AAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEA
AAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAABgAGAPD/AAAAAAcAAwAOAAUAHQAHAB8ABwAh
AAcADQAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAIAAAA/wEAAAABIQAAAXDQAAMxAA
AB4NAAAPAATwwgAAAAIACvAIAAAAJBABAAIKAAAjAQvwkgAAAEIBDgAAAEMBAwAAAEQBBAAA
AEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAA
AMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/wAAAwAHAAIADgAA
AAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAABDEAAAaw0AAFEQAABuDQAADwAE8MIAAAAC
AArwCAAAACUQAQACCgAAIwEL8JIAAABCAQQAAABDAREAAABEAQQAAABFwQwAAABGwRQAAAB/
AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADO
AQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8AABEAAgAJAAQAAAAHAAgAAgAAQACsAQAA
rAEAAKwAgAAAD/AQAAAAcREAAGoNAAB1EQAAew0AAA8ABPD6AAAAAgAK8AgAAAAmEAEAAgoA
ACMBC/DKAAAAQgEsAAAAQwE/AAAARAEEAAAARcEoAAAARsEwAAAAfwEBAAEAgAEAAAAAgQH8
/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMA
ABAAiAMAAAAACgAKAPD/LAA/ACwAPwArADUAKQArACUAIgAgABoAGgASABIACwAKAAUAAAAA
ABUAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwAgAAAD/AQ
AAAAvBEAAAENAADoEQAAQA0AAA8ABPDSAAAAAgAK8AgAAAAnEAEAAgoAACMBC/CiAAAAQgET
AAAAQwEYAAAARAEEAAAARcEUAAAARsEcAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEA
ABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAABQAF
APD/AAAYAAYAEwALAA0AEAAHABMAAAALAAwAAgAAQACsAQAArAEAAKwBAACsAQAArACAAAAP
8BAAAAAPEgAAvQwAACISAADVDAAADwAE8MoAAAACAArwCAAAACgQAQACCgAAIwEL8JoAAABC
AQEAAABDAQsAAABEAQQAAABFwRAAAABGwRgAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/
AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAAE
AAQA8P8BAAsAAQALAAEABgAAAAAACQAMAAIAAEAArAEAAKwBAACsAQAArACAAAAP8BAAAAD0
EQAAZQwAAPURAABwDAAADwAE8MIAAAACAArwCAAAACkQAQACCgAAIwEL8JIAAABCAQkAAABD
AQ4AAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADA
AQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8J
AAAABAAHAAAADgAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAeREAAEoMAACCEQAAWAwA
AA8ABPDCAAAAAgAK8AgAAAAqEAEAAgoAACMBC/CSAAAAQgEFAAAAQwENAAAARAEEAAAARcEM
AAAARsEUAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFq
SgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAAAwADAPD/BQAAAAIABgAAAA0ABwAI
AAIAAEAArAEAAKwBAACsAIAAAA/wEAAAABsRAABSDAAAIBEAAF8MAAAPAATwwgAAAAIACvAI
AAAAKxABAAIKAAAjAQvwkgAAAEIBEQAAAEMBDAAAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQAB
AIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAAAMsBakoAAM0BAAAAAM4BAAAA
AP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/xEADAAJAAYAAAAAAAcACAACAABAAKwBAACsAQAA
rACAAAAP8BAAAACwEAAAYwwAAMEQAABvDAAADwAE8MIAAAACAArwCAAAACwQAQACCgAAIwEL
8JIAAABCAQMAAABDAQwAAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCC
AQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACI
AwAAAAADAAMA8P8AAAAAAQAGAAMADAAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAKRAA
ALUMAAAsEAAAwQwAAA8AA/BCEwAADwAE8HgAAAABAAnwEAAAAPUPAAA1DAAANRIAALUNAAAC
AArwCAAAAC0QAQABAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAAQAAAACBAcz//wC/ARAAEACI
AwAAAAAjACLxDAAAAI8DAAAAAJEDAAAAAAAAEPAIAAAA+gYXEA0VUwsPAATwKgUAAAIACvAI
AAAALhABAAIKAADzAAvw+gQAAEIBQAIAAEMBgAEAAEQBBAAAAEXBSAIAAEbBUgIAAH8BAQAB
AIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMsBakoAAM0BAAAAAP8BGAAYAD8DAAAQAIgDAAAA
AJIAkgDw/zQAgAApAIIAHwCFABYAigAPAJEACQCYAAQAoQABAKoAAAC0AAEAuwACAMIACADO
ABEA2QAdAOIAHADhABUA6QARAPIADgD7AA0ABQEOABABEgAaARcAIwEeACoBJwAxATAANgE7
ADkBRwA6AUoAOgFOADkBTQA6AVUARAFeAE4BaABWAXMAXAF/AGIBjABmAZkAaAGnAGkBtQBo
AcIAZQHQAGEB3ABbAdsAXAHiAGQB6gBrAfIAcQH8AHYBBgF6ARABfgEbAX8BJgGAATUBfwFD
AXwBUAF3AVwBcAFnAWcBcAFdAXcBUgF8AUYBfQFGAYYBSwGQAU4BmwFQAaUBUQG1AVABwwFM
AdABRQHcAT0B5QEyAewBJgHxARkB8wELAfIBCwECAggBEQICAR4C+gAqAvAAMwLkADoC1wA/
AskAQAK6AD8CrQA7AqAANQKUAC0CiAAtAogAMgJ8ADMCbwAyAmQALwJaACoCUAAkAkgAHAJA
ABMCOQAJAjQA/gEwAP8BMAD8ASYA9wEdAPABFQDoAQ4A3wEIANUBBADKAQEAvwEAALEBAQCk
AQYAmAEMAI0BFQCOARUAhQEMAHkBBgBsAQEAXwEAAFcBAQBPAQIAQQEIADQBEQArAR0AKwEe
ACABFgAUAREABwENAPoADADwAA0A5gAOAN0AEQDVABUAxgAgAMAAJwC7AC4AuwAuALAAKQCl
ACYAmQAkAI0AIwB7ACUAagAqAFsAMQBNADsAQgBHADoAVQA1AGUAMwB1ADMAegA0AIAAJgEo
AQIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP
8BAAAAD1DwAANQwAADUSAAC1DQAADwAE8DwFAAACAArwCAAAAC8QAQACCgAAIwEL8AwFAABC
AUACAABDAYABAABEAQQAAABFwUgCAABGwVICAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/
AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAACS
AJIA8P80AIAAKQCCAB8AhQAWAIoADwCRAAkAmAAEAKEAAQCqAAAAtAABALsAAgDCAAgAzgAR
ANkAHQDiABwA4QAVAOkAEQDyAA4A+wANAAUBDgAQARIAGgEXACMBHgAqAScAMQEwADYBOwA5
AUcAOgFKADoBTgA5AU0AOgFVAEQBXgBOAWgAVgFzAFwBfwBiAYwAZgGZAGgBpwBpAbUAaAHC
AGUB0ABhAdwAWwHbAFwB4gBkAeoAawHyAHEB/AB2AQYBegEQAX4BGwF/ASYBgAE1AX8BQwF8
AVABdwFcAXABZwFnAXABXQF3AVIBfAFGAX0BRgGGAUsBkAFOAZsBUAGlAVEBtQFQAcMBTAHQ
AUUB3AE9AeUBMgHsASYB8QEZAfMBCwHyAQsBAgIIARECAgEeAvoAKgLwADMC5AA6AtcAPwLJ
AEACugA/Aq0AOwKgADUClAAtAogALQKIADICfAAzAm8AMgJkAC8CWgAqAlAAJAJIABwCQAAT
AjkACQI0AP4BMAD/ATAA/AEmAPcBHQDwARUA6AEOAN8BCADVAQQAygEBAL8BAACxAQEApAEG
AJgBDACNARUAjgEVAIUBDAB5AQYAbAEBAF8BAABXAQEATwECAEEBCAA0AREAKwEdACsBHgAg
ARYAFAERAAcBDQD6AAwA8AANAOYADgDdABEA1QAVAMYAIADAACcAuwAuALsALgCwACkApQAm
AJkAJACNACMAewAlAGoAKgBbADEATQA7AEIARwA6AFUANQBlADMAdQAzAHoANACAACYBKAEC
AABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQ
AAAA9Q8AADUMAAA1EgAAtQ0AAA8ABPDaAAAAAgAK8AgAAAAwEAEAAgoAACMBC/CqAAAAQgEh
AAAAQwEHAAAARAEEAAAARcEYAAAARsEgAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEA
ABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAABgAG
APD/AAAAAAcAAwAOAAUAHQAHAB8ABwAhAAcADQAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwB
AACsAIAAAA/wEAAAABIQAAAXDQAAMxAAAB4NAAAPAATwwgAAAAIACvAIAAAAMRABAAIKAAAj
AQvwkgAAAEIBDgAAAEMBAwAAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEB/P65
AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQ
AIgDAAAAAAMAAwDw/wAAAwAHAAIADgAAAAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAABD
EAAAaw0AAFEQAABuDQAADwAE8MIAAAACAArwCAAAADIQAQACCgAAIwEL8JIAAABCAQQAAABD
AREAAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADA
AQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8A
ABEAAgAJAAQAAAAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAcREAAGoNAAB1EQAAew0A
AA8ABPD6AAAAAgAK8AgAAAAzEAEAAgoAACMBC/DKAAAAQgEsAAAAQwE/AAAARAEEAAAARcEo
AAAARsEwAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFq
SgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAACgAKAPD/LAA/ACwAPwArADUAKQAr
ACUAIgAgABoAGgASABIACwAKAAUAAAAAABUAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwAgAAAD/AQAAAAvBEAAAENAADoEQAAQA0AAA8ABPDSAAAAAgAK
8AgAAAA0EAEAAgoAACMBC/CiAAAAQgETAAAAQwEYAAAARAEEAAAARcEUAAAARsEcAAAAfwEB
AAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEA
AAAA/wEYABgAPwMAABAAiAMAAAAABQAFAPD/AAAYAAYAEwALAA0AEAAHABMAAAALAAwAAgAA
QACsAQAArAEAAKwBAACsAQAArACAAAAP8BAAAAAPEgAAvQwAACISAADVDAAADwAE8MoAAAAC
AArwCAAAADUQAQACCgAAIwEL8JoAAABCAQEAAABDAQsAAABEAQQAAABFwRAAAABGwRgAAAB/
AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADO
AQAAAAD/ARgAGAA/AwAAEACIAwAAAAAEAAQA8P8BAAsAAQALAAEABgAAAAAACQAMAAIAAEAA
rAEAAKwBAACsAQAArACAAAAP8BAAAAD0EQAAZQwAAPURAABwDAAADwAE8MIAAAACAArwCAAA
ADYQAQACCgAAIwEL8JIAAABCAQkAAABDAQ4AAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCA
AQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/
ARgAGAA/AwAAEACIAwAAAAADAAMA8P8JAAAABAAHAAAADgAHAAgAAgAAQACsAQAArAEAAKwA
gAAAD/AQAAAAeREAAEoMAACCEQAAWAwAAA8ABPDCAAAAAgAK8AgAAAA3EAEAAgoAACMBC/CS
AAAAQgEFAAAAQwENAAAARAEEAAAARcEMAAAARsEUAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEA
gAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMA
AAAAAwADAPD/BQAAAAIABgAAAA0ABwAIAAIAAEAArAEAAKwBAACsAIAAAA/wEAAAABsRAABS
DAAAIBEAAF8MAAAPAATwwgAAAAIACvAIAAAAOBABAAIKAAAjAQvwkgAAAEIBEQAAAEMBDAAA
AEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAA
AMQBAAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/xEADAAJ
AAYAAAAAAAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAACwEAAAYwwAAMEQAABvDAAADwAE
8MIAAAACAArwCAAAADkQAQACCgAAIwEL8JIAAABCAQMAAABDAQwAAABEAQQAAABFwQwAAABG
wRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADN
AQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8AAAAAAQAGAAMADAAHAAgAAgAA
QACsAQAArAEAAKwAgAAAD/AQAAAAKRAAALUMAAAsEAAAwQwAAA8ABPDZAAAAogwK8AgAAAA6
EAEAAAoAAMMAC/BIAAAAgAD41eYAhQACAAAAhwAGAAAAvwACAAIAgQEAAAAIgwEAAAAIvwEA
ABAAwAEBAAAIywGcMQAA/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAAAGCSYCiAbLCQ8ADfBh
AAAAAACfDwQAAAAEAAAAAACoDw8AAABBZG1pbi4gRG9tYWluIEEAAKEPGAAAABAAAAAAAAAQ
AABaABAAAAAAAAMAAwAQAAAApg8WAAAA8R4AAOABaAFoAdAC0AI4BDgEoAWgBQ8ABPDZAAAA
ogwK8AgAAAA7EAEAAAoAAMMAC/BIAAAAgADM3uYAhQACAAAAhwAGAAAAvwACAAIAgQEAAAAI
gwEAAAAIvwEAABAAwAEBAAAIywGcMQAA/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAAARBnYQ
2RTWBg8ADfBhAAAAAACfDwQAAAAEAAAAAACoDw8AAABBZG1pbi4gRG9tYWluIEIAAKEPGAAA
ABAAAAAAAAAQAABaABAAAAAAAAMAAwAQAAAApg8WAAAA8R4AAOABaAFoAdAC0AI4BDgEoAWg
BQ8AA/BCEwAADwAE8HgAAAABAAnwEAAAAPUPAAA1DAAANRIAALUNAAACAArwCAAAADwQAQAB
AgAAYwAL8CQAAAAEAAAAAAB/AAAABACAAQAAAACBAcz//wC/ARAAEACIAwAAAAAjACLxDAAA
AI8DAAAAAJEDAAAAAAAAEPAIAAAABQu4AsQErQwPAATwKgUAAAIACvAIAAAAPRABAAIKAADz
AAvw+gQAAEIBQAIAAEMBgAEAAEQBBAAAAEXBSAIAAEbBUgIAAH8BAQABAIABAAAAAIEB/P65
AIIBAIAAAL8BAAAQAMsBakoAAM0BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAJIAkgDw/zQAgAAp
AIIAHwCFABYAigAPAJEACQCYAAQAoQABAKoAAAC0AAEAuwACAMIACADOABEA2QAdAOIAHADh
ABUA6QARAPIADgD7AA0ABQEOABABEgAaARcAIwEeACoBJwAxATAANgE7ADkBRwA6AUoAOgFO
ADkBTQA6AVUARAFeAE4BaABWAXMAXAF/AGIBjABmAZkAaAGnAGkBtQBoAcIAZQHQAGEB3ABb
AdsAXAHiAGQB6gBrAfIAcQH8AHYBBgF6ARABfgEbAX8BJgGAATUBfwFDAXwBUAF3AVwBcAFn
AWcBcAFdAXcBUgF8AUYBfQFGAYYBSwGQAU4BmwFQAaUBUQG1AVABwwFMAdABRQHcAT0B5QEy
AewBJgHxARkB8wELAfIBCwECAggBEQICAR4C+gAqAvAAMwLkADoC1wA/AskAQAK6AD8CrQA7
AqAANQKUAC0CiAAtAogAMgJ8ADMCbwAyAmQALwJaACoCUAAkAkgAHAJAABMCOQAJAjQA/gEw
AP8BMAD8ASYA9wEdAPABFQDoAQ4A3wEIANUBBADKAQEAvwEAALEBAQCkAQYAmAEMAI0BFQCO
ARUAhQEMAHkBBgBsAQEAXwEAAFcBAQBPAQIAQQEIADQBEQArAR0AKwEeACABFgAUAREABwEN
APoADADwAA0A5gAOAN0AEQDVABUAxgAgAMAAJwC7AC4AuwAuALAAKQClACYAmQAkAI0AIwB7
ACUAagAqAFsAMQBNADsAQgBHADoAVQA1AGUAMwB1ADMAegA0AIAAJgEoAQIAAEAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAD1DwAANQwA
ADUSAAC1DQAADwAE8DwFAAACAArwCAAAAD4QAQACCgAAIwEL8AwFAABCAUACAABDAYABAABE
AQQAAABFwUgCAABGwVICAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADE
AQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAACSAJIA8P80AIAAKQCC
AB8AhQAWAIoADwCRAAkAmAAEAKEAAQCqAAAAtAABALsAAgDCAAgAzgARANkAHQDiABwA4QAV
AOkAEQDyAA4A+wANAAUBDgAQARIAGgEXACMBHgAqAScAMQEwADYBOwA5AUcAOgFKADoBTgA5
AU0AOgFVAEQBXgBOAWgAVgFzAFwBfwBiAYwAZgGZAGgBpwBpAbUAaAHCAGUB0ABhAdwAWwHb
AFwB4gBkAeoAawHyAHEB/AB2AQYBegEQAX4BGwF/ASYBgAE1AX8BQwF8AVABdwFcAXABZwFn
AXABXQF3AVIBfAFGAX0BRgGGAUsBkAFOAZsBUAGlAVEBtQFQAcMBTAHQAUUB3AE9AeUBMgHs
ASYB8QEZAfMBCwHyAQsBAgIIARECAgEeAvoAKgLwADMC5AA6AtcAPwLJAEACugA/Aq0AOwKg
ADUClAAtAogALQKIADICfAAzAm8AMgJkAC8CWgAqAlAAJAJIABwCQAATAjkACQI0AP4BMAD/
ATAA/AEmAPcBHQDwARUA6AEOAN8BCADVAQQAygEBAL8BAACxAQEApAEGAJgBDACNARUAjgEV
AIUBDAB5AQYAbAEBAF8BAABXAQEATwECAEEBCAA0AREAKwEdACsBHgAgARYAFAERAAcBDQD6
AAwA8AANAOYADgDdABEA1QAVAMYAIADAACcAuwAuALsALgCwACkApQAmAJkAJACNACMAewAl
AGoAKgBbADEATQA7AEIARwA6AFUANQBlADMAdQAzAHoANACAACYBKAECAABAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9Q8AADUMAAA1
EgAAtQ0AAA8ABPDaAAAAAgAK8AgAAAA/EAEAAgoAACMBC/CqAAAAQgEhAAAAQwEHAAAARAEE
AAAARcEYAAAARsEgAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEA
AAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAABgAGAPD/AAAAAAcAAwAO
AAUAHQAHAB8ABwAhAAcADQAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAIAAAA/wEAAA
ABIQAAAXDQAAMxAAAB4NAAAPAATwwgAAAAIACvAIAAAAQBABAAIKAAAjAQvwkgAAAEIBDgAA
AEMBAwAAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQ
AMABAAAAAMQBAAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw
/wAAAwAHAAIADgAAAAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAABDEAAAaw0AAFEQAABu
DQAADwAE8MIAAAACAArwCAAAAEEQAQACCgAAIwEL8JIAAABCAQQAAABDAREAAABEAQQAAABF
wQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADL
AWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8AABEAAgAJAAQAAAAH
AAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAcREAAGoNAAB1EQAAew0AAA8ABPD6AAAAAgAK
8AgAAABCEAEAAgoAACMBC/DKAAAAQgEsAAAAQwE/AAAARAEEAAAARcEoAAAARsEwAAAAfwEB
AAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEA
AAAA/wEYABgAPwMAABAAiAMAAAAACgAKAPD/LAA/ACwAPwArADUAKQArACUAIgAgABoAGgAS
ABIACwAKAAUAAAAAABUAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwAgAAAD/AQAAAAvBEAAAENAADoEQAAQA0AAA8ABPDSAAAAAgAK8AgAAABDEAEAAgoA
ACMBC/CiAAAAQgETAAAAQwEYAAAARAEEAAAARcEUAAAARsEcAAAAfwEBAAEAgAEAAAAAgQH8
/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMA
ABAAiAMAAAAABQAFAPD/AAAYAAYAEwALAA0AEAAHABMAAAALAAwAAgAAQACsAQAArAEAAKwB
AACsAQAArACAAAAP8BAAAAAPEgAAvQwAACISAADVDAAADwAE8MoAAAACAArwCAAAAEQQAQAC
CgAAIwEL8JoAAABCAQEAAABDAQsAAABEAQQAAABFwRAAAABGwRgAAAB/AQEAAQCAAQAAAACB
Afz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/
AwAAEACIAwAAAAAEAAQA8P8BAAsAAQALAAEABgAAAAAACQAMAAIAAEAArAEAAKwBAACsAQAA
rACAAAAP8BAAAAD0EQAAZQwAAPURAABwDAAADwAE8MIAAAACAArwCAAAAEUQAQACCgAAIwEL
8JIAAABCAQkAAABDAQ4AAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCC
AQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACI
AwAAAAADAAMA8P8JAAAABAAHAAAADgAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAeREA
AEoMAACCEQAAWAwAAA8ABPDCAAAAAgAK8AgAAABGEAEAAgoAACMBC/CSAAAAQgEFAAAAQwEN
AAAARAEEAAAARcEMAAAARsEUAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEA
AAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAAAwADAPD/BQAA
AAIABgAAAA0ABwAIAAIAAEAArAEAAKwBAACsAIAAAA/wEAAAABsRAABSDAAAIBEAAF8MAAAP
AATwwgAAAAIACvAIAAAARxABAAIKAAAjAQvwkgAAAEIBEQAAAEMBDAAAAEQBBAAAAEXBDAAA
AEbBFAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAAAMsBakoA
AM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/xEADAAJAAYAAAAAAAcACAAC
AABAAKwBAACsAQAArACAAAAP8BAAAACwEAAAYwwAAMEQAABvDAAADwAE8MIAAAACAArwCAAA
AEgQAQACCgAAIwEL8JIAAABCAQMAAABDAQwAAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCA
AQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/
ARgAGAA/AwAAEACIAwAAAAADAAMA8P8AAAAAAQAGAAMADAAHAAgAAgAAQACsAQAArAEAAKwA
gAAAD/AQAAAAKRAAALUMAAAsEAAAwQwAAA8AA/BCEwAADwAE8HgAAAABAAnwEAAAAPUPAAA1
DAAANRIAALUNAAACAArwCAAAAEkQAQABAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAAQAAAACB
Acz//wC/ARAAEACIAwAAAAAjACLxDAAAAI8DAAAAAJEDAAAAAAAAEPAIAAAApQf4EKkTUgoP
AATwKgUAAAIACvAIAAAAShABAAIKAADzAAvw+gQAAEIBQAIAAEMBgAEAAEQBBAAAAEXBSAIA
AEbBUgIAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMsBakoAAM0BAAAAAP8BGAAY
AD8DAAAQAIgDAAAAAJIAkgDw/zQAgAApAIIAHwCFABYAigAPAJEACQCYAAQAoQABAKoAAAC0
AAEAuwACAMIACADOABEA2QAdAOIAHADhABUA6QARAPIADgD7AA0ABQEOABABEgAaARcAIwEe
ACoBJwAxATAANgE7ADkBRwA6AUoAOgFOADkBTQA6AVUARAFeAE4BaABWAXMAXAF/AGIBjABm
AZkAaAGnAGkBtQBoAcIAZQHQAGEB3ABbAdsAXAHiAGQB6gBrAfIAcQH8AHYBBgF6ARABfgEb
AX8BJgGAATUBfwFDAXwBUAF3AVwBcAFnAWcBcAFdAXcBUgF8AUYBfQFGAYYBSwGQAU4BmwFQ
AaUBUQG1AVABwwFMAdABRQHcAT0B5QEyAewBJgHxARkB8wELAfIBCwECAggBEQICAR4C+gAq
AvAAMwLkADoC1wA/AskAQAK6AD8CrQA7AqAANQKUAC0CiAAtAogAMgJ8ADMCbwAyAmQALwJa
ACoCUAAkAkgAHAJAABMCOQAJAjQA/gEwAP8BMAD8ASYA9wEdAPABFQDoAQ4A3wEIANUBBADK
AQEAvwEAALEBAQCkAQYAmAEMAI0BFQCOARUAhQEMAHkBBgBsAQEAXwEAAFcBAQBPAQIAQQEI
ADQBEQArAR0AKwEeACABFgAUAREABwENAPoADADwAA0A5gAOAN0AEQDVABUAxgAgAMAAJwC7
AC4AuwAuALAAKQClACYAmQAkAI0AIwB7ACUAagAqAFsAMQBNADsAQgBHADoAVQA1AGUAMwB1
ADMAegA0AIAAJgEoAQIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBYACAAAAP8BAAAAD1DwAANQwAADUSAAC1DQAADwAE8DwFAAACAArwCAAAAEsQAQAC
CgAAIwEL8AwFAABCAUACAABDAYABAABEAQQAAABFwUgCAABGwVICAAB/AQEAAQCAAQAAAACB
Afz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/
AwAAEACIAwAAAACSAJIA8P80AIAAKQCCAB8AhQAWAIoADwCRAAkAmAAEAKEAAQCqAAAAtAAB
ALsAAgDCAAgAzgARANkAHQDiABwA4QAVAOkAEQDyAA4A+wANAAUBDgAQARIAGgEXACMBHgAq
AScAMQEwADYBOwA5AUcAOgFKADoBTgA5AU0AOgFVAEQBXgBOAWgAVgFzAFwBfwBiAYwAZgGZ
AGgBpwBpAbUAaAHCAGUB0ABhAdwAWwHbAFwB4gBkAeoAawHyAHEB/AB2AQYBegEQAX4BGwF/
ASYBgAE1AX8BQwF8AVABdwFcAXABZwFnAXABXQF3AVIBfAFGAX0BRgGGAUsBkAFOAZsBUAGl
AVEBtQFQAcMBTAHQAUUB3AE9AeUBMgHsASYB8QEZAfMBCwHyAQsBAgIIARECAgEeAvoAKgLw
ADMC5AA6AtcAPwLJAEACugA/Aq0AOwKgADUClAAtAogALQKIADICfAAzAm8AMgJkAC8CWgAq
AlAAJAJIABwCQAATAjkACQI0AP4BMAD/ATAA/AEmAPcBHQDwARUA6AEOAN8BCADVAQQAygEB
AL8BAACxAQEApAEGAJgBDACNARUAjgEVAIUBDAB5AQYAbAEBAF8BAABXAQEATwECAEEBCAA0
AREAKwEdACsBHgAgARYAFAERAAcBDQD6AAwA8AANAOYADgDdABEA1QAVAMYAIADAACcAuwAu
ALsALgCwACkApQAmAJkAJACNACMAewAlAGoAKgBbADEATQA7AEIARwA6AFUANQBlADMAdQAz
AHoANACAACYBKAECAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAWAAgAAAD/AQAAAA9Q8AADUMAAA1EgAAtQ0AAA8ABPDaAAAAAgAK8AgAAABMEAEAAgoA
ACMBC/CqAAAAQgEhAAAAQwEHAAAARAEEAAAARcEYAAAARsEgAAAAfwEBAAEAgAEAAAAAgQH8
/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMA
ABAAiAMAAAAABgAGAPD/AAAAAAcAAwAOAAUAHQAHAB8ABwAhAAcADQAQAAIAAEAArAEAAKwB
AACsAQAArAEAAKwBAACsAIAAAA/wEAAAABIQAAAXDQAAMxAAAB4NAAAPAATwwgAAAAIACvAI
AAAATRABAAIKAAAjAQvwkgAAAEIBDgAAAEMBAwAAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQAB
AIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAAAMsBakoAAM0BAAAAAM4BAAAA
AP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/wAAAwAHAAIADgAAAAcACAACAABAAKwBAACsAQAA
rACAAAAP8BAAAABDEAAAaw0AAFEQAABuDQAADwAE8MIAAAACAArwCAAAAE4QAQACCgAAIwEL
8JIAAABCAQQAAABDAREAAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCC
AQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACI
AwAAAAADAAMA8P8AABEAAgAJAAQAAAAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAcREA
AGoNAAB1EQAAew0AAA8ABPD6AAAAAgAK8AgAAABPEAEAAgoAACMBC/DKAAAAQgEsAAAAQwE/
AAAARAEEAAAARcEoAAAARsEwAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEA
AAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAACgAKAPD/LAA/
ACwAPwArADUAKQArACUAIgAgABoAGgASABIACwAKAAUAAAAAABUAGAACAABAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwAgAAAD/AQAAAAvBEAAAENAADoEQAAQA0A
AA8ABPDSAAAAAgAK8AgAAABQEAEAAgoAACMBC/CiAAAAQgETAAAAQwEYAAAARAEEAAAARcEU
AAAARsEcAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFq
SgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAABQAFAPD/AAAYAAYAEwALAA0AEAAH
ABMAAAALAAwAAgAAQACsAQAArAEAAKwBAACsAQAArACAAAAP8BAAAAAPEgAAvQwAACISAADV
DAAADwAE8MoAAAACAArwCAAAAFEQAQACCgAAIwEL8JoAAABCAQEAAABDAQsAAABEAQQAAABF
wRAAAABGwRgAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADL
AWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAAEAAQA8P8BAAsAAQALAAEABgAA
AAAACQAMAAIAAEAArAEAAKwBAACsAQAArACAAAAP8BAAAAD0EQAAZQwAAPURAABwDAAADwAE
8MIAAAACAArwCAAAAFIQAQACCgAAIwEL8JIAAABCAQkAAABDAQ4AAABEAQQAAABFwQwAAABG
wRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADN
AQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8JAAAABAAHAAAADgAHAAgAAgAA
QACsAQAArAEAAKwAgAAAD/AQAAAAeREAAEoMAACCEQAAWAwAAA8ABPDCAAAAAgAK8AgAAABT
EAEAAgoAACMBC/CSAAAAQgEFAAAAQwENAAAARAEEAAAARcEMAAAARsEUAAAAfwEBAAEAgAEA
AAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEY
ABgAPwMAABAAiAMAAAAAAwADAPD/BQAAAAIABgAAAA0ABwAIAAIAAEAArAEAAKwBAACsAIAA
AA/wEAAAABsRAABSDAAAIBEAAF8MAAAPAATwwgAAAAIACvAIAAAAVBABAAIKAAAjAQvwkgAA
AEIBEQAAAEMBDAAAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAA
AL8BAAAQAMABAAAAAMQBAAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAA
AAMAAwDw/xEADAAJAAYAAAAAAAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAACwEAAAYwwA
AMEQAABvDAAADwAE8MIAAAACAArwCAAAAFUQAQACCgAAIwEL8JIAAABCAQMAAABDAQwAAABE
AQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADE
AQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8AAAAAAQAG
AAMADAAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAKRAAALUMAAAsEAAAwQwAAA8AA/BC
EwAADwAE8HgAAAABAAnwEAAAAPUPAAA1DAAANRIAALUNAAACAArwCAAAAFYQAQABAgAAYwAL
8CQAAAAEAAAAAAB/AAAABACAAQAAAACBAcz//wC/ARAAEACIAwAAAAAjACLxDAAAAI8DAAAA
AJEDAAAAAAAAEPAIAAAAUAjdEQgTWAkPAATwKgUAAAIACvAIAAAAVxABAAIKAADzAAvw+gQA
AEIBQAIAAEMBgAEAAEQBBAAAAEXBSAIAAEbBUgIAAH8BAQABAIABAAAAAIEB/P65AIIBAIAA
AL8BAAAQAMsBakoAAM0BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAJIAkgDw/zQAgAApAIIAHwCF
ABYAigAPAJEACQCYAAQAoQABAKoAAAC0AAEAuwACAMIACADOABEA2QAdAOIAHADhABUA6QAR
APIADgD7AA0ABQEOABABEgAaARcAIwEeACoBJwAxATAANgE7ADkBRwA6AUoAOgFOADkBTQA6
AVUARAFeAE4BaABWAXMAXAF/AGIBjABmAZkAaAGnAGkBtQBoAcIAZQHQAGEB3ABbAdsAXAHi
AGQB6gBrAfIAcQH8AHYBBgF6ARABfgEbAX8BJgGAATUBfwFDAXwBUAF3AVwBcAFnAWcBcAFd
AXcBUgF8AUYBfQFGAYYBSwGQAU4BmwFQAaUBUQG1AVABwwFMAdABRQHcAT0B5QEyAewBJgHx
ARkB8wELAfIBCwECAggBEQICAR4C+gAqAvAAMwLkADoC1wA/AskAQAK6AD8CrQA7AqAANQKU
AC0CiAAtAogAMgJ8ADMCbwAyAmQALwJaACoCUAAkAkgAHAJAABMCOQAJAjQA/gEwAP8BMAD8
ASYA9wEdAPABFQDoAQ4A3wEIANUBBADKAQEAvwEAALEBAQCkAQYAmAEMAI0BFQCOARUAhQEM
AHkBBgBsAQEAXwEAAFcBAQBPAQIAQQEIADQBEQArAR0AKwEeACABFgAUAREABwENAPoADADw
AA0A5gAOAN0AEQDVABUAxgAgAMAAJwC7AC4AuwAuALAAKQClACYAmQAkAI0AIwB7ACUAagAq
AFsAMQBNADsAQgBHADoAVQA1AGUAMwB1ADMAegA0AIAAJgEoAQIAAEAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAD1DwAANQwAADUSAAC1
DQAADwAE8DwFAAACAArwCAAAAFgQAQACCgAAIwEL8AwFAABCAUACAABDAYABAABEAQQAAABF
wUgCAABGwVICAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADL
AWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAACSAJIA8P80AIAAKQCCAB8AhQAW
AIoADwCRAAkAmAAEAKEAAQCqAAAAtAABALsAAgDCAAgAzgARANkAHQDiABwA4QAVAOkAEQDy
AA4A+wANAAUBDgAQARIAGgEXACMBHgAqAScAMQEwADYBOwA5AUcAOgFKADoBTgA5AU0AOgFV
AEQBXgBOAWgAVgFzAFwBfwBiAYwAZgGZAGgBpwBpAbUAaAHCAGUB0ABhAdwAWwHbAFwB4gBk
AeoAawHyAHEB/AB2AQYBegEQAX4BGwF/ASYBgAE1AX8BQwF8AVABdwFcAXABZwFnAXABXQF3
AVIBfAFGAX0BRgGGAUsBkAFOAZsBUAGlAVEBtQFQAcMBTAHQAUUB3AE9AeUBMgHsASYB8QEZ
AfMBCwHyAQsBAgIIARECAgEeAvoAKgLwADMC5AA6AtcAPwLJAEACugA/Aq0AOwKgADUClAAt
AogALQKIADICfAAzAm8AMgJkAC8CWgAqAlAAJAJIABwCQAATAjkACQI0AP4BMAD/ATAA/AEm
APcBHQDwARUA6AEOAN8BCADVAQQAygEBAL8BAACxAQEApAEGAJgBDACNARUAjgEVAIUBDAB5
AQYAbAEBAF8BAABXAQEATwECAEEBCAA0AREAKwEdACsBHgAgARYAFAERAAcBDQD6AAwA8AAN
AOYADgDdABEA1QAVAMYAIADAACcAuwAuALsALgCwACkApQAmAJkAJACNACMAewAlAGoAKgBb
ADEATQA7AEIARwA6AFUANQBlADMAdQAzAHoANACAACYBKAECAABAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA
rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB
AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9Q8AADUMAAA1EgAAtQ0A
AA8ABPDaAAAAAgAK8AgAAABZEAEAAgoAACMBC/CqAAAAQgEhAAAAQwEHAAAARAEEAAAARcEY
AAAARsEgAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFq
SgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAABgAGAPD/AAAAAAcAAwAOAAUAHQAH
AB8ABwAhAAcADQAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAIAAAA/wEAAAABIQAAAX
DQAAMxAAAB4NAAAPAATwwgAAAAIACvAIAAAAWhABAAIKAAAjAQvwkgAAAEIBDgAAAEMBAwAA
AEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAA
AMQBAAAAAMsBakoAAM0BAAAAAM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/wAAAwAH
AAIADgAAAAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAABDEAAAaw0AAFEQAABuDQAADwAE
8MIAAAACAArwCAAAAFsQAQACCgAAIwEL8JIAAABCAQQAAABDAREAAABEAQQAAABFwQwAAABG
wRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADN
AQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAADAAMA8P8AABEAAgAJAAQAAAAHAAgAAgAA
QACsAQAArAEAAKwAgAAAD/AQAAAAcREAAGoNAAB1EQAAew0AAA8ABPD6AAAAAgAK8AgAAABc
EAEAAgoAACMBC/DKAAAAQgEsAAAAQwE/AAAARAEEAAAARcEoAAAARsEwAAAAfwEBAAEAgAEA
AAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEY
ABgAPwMAABAAiAMAAAAACgAKAPD/LAA/ACwAPwArADUAKQArACUAIgAgABoAGgASABIACwAK
AAUAAAAAABUAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwA
gAAAD/AQAAAAvBEAAAENAADoEQAAQA0AAA8ABPDSAAAAAgAK8AgAAABdEAEAAgoAACMBC/Ci
AAAAQgETAAAAQwEYAAAARAEEAAAARcEUAAAARsEcAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEA
gAAAvwEAABAAwAEAAAAAxAEAAAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMA
AAAABQAFAPD/AAAYAAYAEwALAA0AEAAHABMAAAALAAwAAgAAQACsAQAArAEAAKwBAACsAQAA
rACAAAAP8BAAAAAPEgAAvQwAACISAADVDAAADwAE8MoAAAACAArwCAAAAF4QAQACCgAAIwEL
8JoAAABCAQEAAABDAQsAAABEAQQAAABFwRAAAABGwRgAAAB/AQEAAQCAAQAAAACBAfz+uQCC
AQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACI
AwAAAAAEAAQA8P8BAAsAAQALAAEABgAAAAAACQAMAAIAAEAArAEAAKwBAACsAQAArACAAAAP
8BAAAAD0EQAAZQwAAPURAABwDAAADwAE8MIAAAACAArwCAAAAF8QAQACCgAAIwEL8JIAAABC
AQkAAABDAQ4AAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAfz+uQCCAQCAAAC/
AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/AwAAEACIAwAAAAAD
AAMA8P8JAAAABAAHAAAADgAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAeREAAEoMAACC
EQAAWAwAAA8ABPDCAAAAAgAK8AgAAABgEAEAAgoAACMBC/CSAAAAQgEFAAAAQwENAAAARAEE
AAAARcEMAAAARsEUAAAAfwEBAAEAgAEAAAAAgQH8/rkAggEAgAAAvwEAABAAwAEAAAAAxAEA
AAAAywFqSgAAzQEAAAAAzgEAAAAA/wEYABgAPwMAABAAiAMAAAAAAwADAPD/BQAAAAIABgAA
AA0ABwAIAAIAAEAArAEAAKwBAACsAIAAAA/wEAAAABsRAABSDAAAIBEAAF8MAAAPAATwwgAA
AAIACvAIAAAAYRABAAIKAAAjAQvwkgAAAEIBEQAAAEMBDAAAAEQBBAAAAEXBDAAAAEbBFAAA
AH8BAQABAIABAAAAAIEB/P65AIIBAIAAAL8BAAAQAMABAAAAAMQBAAAAAMsBakoAAM0BAAAA
AM4BAAAAAP8BGAAYAD8DAAAQAIgDAAAAAAMAAwDw/xEADAAJAAYAAAAAAAcACAACAABAAKwB
AACsAQAArACAAAAP8BAAAACwEAAAYwwAAMEQAABvDAAADwAE8MIAAAACAArwCAAAAGIQAQAC
CgAAIwEL8JIAAABCAQMAAABDAQwAAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACB
Afz+uQCCAQCAAAC/AQAAEADAAQAAAADEAQAAAADLAWpKAADNAQAAAADOAQAAAAD/ARgAGAA/
AwAAEACIAwAAAAADAAMA8P8AAAAAAQAGAAMADAAHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQ
AAAAKRAAALUMAAAsEAAAwQwAAA8ABPBUAAAAsgQK8AgAAABjEAEAAAoAAFMAC/AsAAAAfwCA
AIQABEEBAAAABcEOAAAABgEBAAAAPwMAABAAUgBPAFUAVABFAFIAAAAAABDwCAAAAHsKjgZv
BxMLDwAE8FQAAACyBArwCAAAAGQQAQAACgAAUwAL8CwAAAB/AIAAhAAEQQEAAAAFwQ4AAAAG
AQEAAAA/AwAAEABSAE8AVQBUAEUAUgAAAAAAEPAIAAAA9QhDDyQQjQkPAATwVAAAALIECvAI
AAAAZRABAAAKAABTAAvwLAAAAH8AgACEAARBAQAAAAXBDgAAAAYBAQAAAD8DAAAQAFIATwBV
AFQARQBSAAAAAAAQ8AgAAAA7C5gEeQXTCw8ABPBUAAAAsgQK8AgAAABmEAEAAAoAAFMAC/As
AAAAfwCAAIQABEEBAAAABcEOAAAABgEBAAAAPwMAABAAUgBPAFUAVABFAFIAAAAAABDwCAAA
ALUIgxBkEU0JDwAE8FQAAACyBArwCAAAAGcQAQAACgAAUwAL8CwAAAB/AIAAhAAEQQEAAAAF
wQ4AAAAGAQEAAAA/AwAAEABSAE8AVQBUAEUAUgAAAAAAEPAIAAAAJgm4EZkSvgkPAATw0AAA
ADIACvAIAAAAaRABAAAKAACzAAvwQgAAAH8AAAAEAIAAlPLmAIUAAgAAAIcAAQAAAIEBBj3o
AL8BEAAQAMABAQAACMsBnDEAAP8BCAAIAAECAgAACD8CAAACAAAAEPAIAAAAjgtlA9oDFAwP
AA3wXgAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAAAAAAABgAAAEAWgABAAAAAAADAAMAFAAA
AKoPCgAAAAEAAAABAAAAAAAAAKYPFgAAAPEeAADgAWgBaAHQAtACOAQ4BKAFoAUPAATw0AAA
ADIACvAIAAAAahABAAAKAACzAAvwQgAAAH8AAAAEAIAA6PrmAIUAAgAAAIcAAQAAAIEBBgAA
CL8BEAAQAMABAQAACMsBnDEAAP8BCAAIAAECAgAACD8CAAACAAAAEPAIAAAAiQg1EqoSDwkP
AA3wXgAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAAAAAAABgAAAEAWgABAAAAAAADAAMAFAAA
AKoPCgAAAAEAAAABAAAAAAAAAKYPFgAAAPEeAADgAWgBaAHQAtACOAQ4BKAFoAUPAATwDgEA
AAIACvAIAAAAaxABAAAKAACDAQvw5gAAAEIBWwsAAEMBpgIAAEQBBAAAAEXBNAAAAEbBHAAA
AH8BAQABAIABAAAAAIEBAAAACIMBAAAACL8BAAAQAMABBj3oAMEBAAABAMQBAAAAAMsB1JQA
AM0BAAAAAM4BAAAAANABAAAAANEBAQAAANQBAQAAANUBAQAAANcBAgAAAP8BGAAYAAECAgAA
CD8CAAACAA0ADQDw/wAApgJEAIYCiQBmAgABNgJ3AQYC+AHbAcsChgGeAzEBgwRsAPAFNgBd
BwAAXAkgAFsLQQALAAwAAgAAQACtASAArQEgAK0BIACtASAArACAAAAQ8AgAAADvCOADOw+V
Cw8ABPAqAQAAAgAK8AgAAABsEAEAAAoAAKMBC/ACAQAAQgG6CgAAQwELAwAARAEEAAAARcFA
AAAARsEgAAAAfwEBAAEAgAEAAAAAgQEAAAAIgwEAAAAIvwEAABAAwAEGAAAIwQEAAAEAxAEA
AAAAywHUlAAAzQEAAAAAzgEAAAAA0AEAAAAA0QEBAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEB
AAAA1wECAAAA/wEYABgAAQICAAAIPwIAAAIAEAAQAPD/ugoAAKcKDgCVCh0AagorAD8KOQAI
CkUAtQlWAGIJZwBDCSYAegiQALEH+gBqBpUCAAXQApYDCwPLAX0CAADwAQ0AEAACAABAAK0B
IACtASAArQEgAK0BIACtASAArACAAAAQ8AgAAAD1CHsHNRIADA8ABPARAQAAogwK8AgAAABt
EAEAAAoAAMMAC/BIAAAAgAB8AP8BhQACAAAAhwAGAAAAvwACAAIAgQEAAAAIgwEAAAAIvwEA
ABAAwAEBAAAIywGcMQAA/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAAADBNIHLg4NBQ8ADfCZ
AAAAAACfDwQAAAAEAAAAAACoDzkAAABhLmNvbTogM2ZmZToxOjoxLA0gICAgICAgICAgICAg
IGZlODA6OjAyMDA6NWVmZTowMTAyOjAzMDQAAKEPJgAAADoAAAAAAAAQAABaAAYAAAABAAMA
AQADAAwANAAAAAAAAwADAAwAAACmDxYAAADxHgAA4AFoAWgB0ALQAjgEOASgBaAFDwAE8BkB
AACiDArwCAAAAG4QAQAACgAAwwAL8EgAAACAAIAM/wGFAAIAAACHAAYAAAC/AAIAAgCBAQAA
AAiDAQAAAAi/AQAAEADAAQEAAAjLAZwxAAD/AQAACAABAgIAAAg/AgAAAgAAABDwCAAAAMME
zQcpDs0FDwAN8KEAAAAAAJ8PBAAAAAQAAAAAAKgPQQAAAGIuY29tOiAyMDAyOjA1MDY6MDcw
ODo6MSwNICAgICAgICAgICAgICBmZTgwOjowMjAwOjVlZmU6MDUwNjowNzA4AAChDyYAAABC
AAAAAAAAEAAAWgAGAAAAAQADAAEAAwAMADwAAAAAAAMAAwAMAAAApg8WAAAA8R4AAOABaAFo
AdAC0AI4BDgEoAWgBQ8ABPDVAAAAogwK8AgAAABvEAEAAAoAAMMAC/BIAAAAgAB0Ef8BhQAC
AAAAhwAGAAAAvwACAAIAgQEAAAAIgwEAAAAIvwEAABAAwAEBAAAIywGcMQAA/wEAAAgAAQIC
AAAIPwIAAAIAAAAQ8AgAAAD9BlYOyRCfBw8ADfBdAAAAAACfDwQAAAAEAAAAAACoDwsAAAAw
NS4wNi4wNy4wOAAAoQ8YAAAADAAAAAAAABAAAFoADAAAAAAAAwADAAwAAACmDxYAAADxHgAA
4AFoAWgB0ALQAjgEOASgBaAFDwAE8NUAAACiDArwCAAAAHAQAQAACgAAwwAL8EgAAACAAFQa
/wGFAAIAAACHAAYAAAC/AAIAAgCBAQAAAAiDAQAAAAi/AQAAEADAAQEAAAjLAZwxAAD/AQAA
CAABAgIAAAg/AgAAAgAAABDwCAAAAC0NCwZ+CM8NDwAN8F0AAAAAAJ8PBAAAAAQAAAAAAKgP
CwAAADAxLjAyLjAzLjA0AAChDxgAAAAMAAAAAAAAEAAAWgAMAAAAAAADAAMADAAAAKYPFgAA
APEeAADgAWgBaAHQAtACOAQ4BKAFoAUPAATwXgAAAEIBCvAIAAAAcRABAIAKAACTAAvwNgAA
AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBnDEAANEBAQAAAP8BGAAYAAECAgAACD8CAAAC
AAAAEPAIAAAAMAsbB1AH5QwPAATwXgAAAEIBCvAIAAAAchABAEAKAACTAAvwNgAAAEQBBAAA
AH8BAAABAL8BAAAQAMABAQAACMsBnDEAANEBAQAAAP8BGAAYAAECAgAACD8CAAACAAAAEPAI
AAAAiwdlD6APywgPAATw2wAAAKIMCvAIAAAAcxABAAAKAADDAAvwSAAAAIAA3CH/AYUAAgAA
AIcABgAAAL8AAgACAIEBAAAACIMBAAAACL8BAAAQAMABAQAACMsBnDEAAP8BAAAIAAECAgAA
CD8CAAACAAAAEPAIAAAABw52AawEqQ4PAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8RAAAAYS5j
b20gKDNmZmU6MTo6MSkAAKEPGAAAABIAAAAAAAAQAABaABIAAAAAAAMAAwAMAAAApg8WAAAA
8R4AAOABaAFoAdAC0AI4BDgEoAWgBQ8ABPBeAAAAQgEK8AgAAAB0EAEAgAoAAJMAC/A2AAAA
RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGcMQAA0QEBAAAA/wEYABgAAQICAAAIPwIAAAIA
AAAQ8AgAAAAbDAACewPVDQ8ABPDjAAAAogwK8AgAAAB1EAEAAAoAAMMAC/BIAAAAgACEK/8B
hQACAAAAhwAGAAAAvwACAAIAgQEAAAAIgwEAAAAIvwEAABAAwAEBAAAIywGcMQAA/wEAAAgA
AQICAAAIPwIAAAIAAAAQ8AgAAABSC/sRDRf0Cw8ADfBrAAAAAACfDwQAAAAEAAAAAACoDxkA
AABiLmNvbSAoMjAwMjowNTA2OjA3MDg6OjEpAAChDxgAAAAaAAAAAAAAEAAAWgAaAAAAAAAD
AAMADAAAAKYPFgAAAPEeAADgAWgBaAHQAtACOAQ4BKAFoAUPAATwXgAAAEIBCvAIAAAAdhAB
AMAKAACTAAvwNgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBnDEAANEBAQAAAP8BGAAY
AAECAgAACD8CAAACAAAAEPAIAAAACgmwEhUUQAsPAATwSAAAABIACvAIAAAAARABAAAMAACD
AAvwMAAAAIEBAAAACIMBBQAACJMBHkCXAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQAB
ABAA8AcgAAAA////AAAAAACRkZEAAAAAAGGP/QAArgAA/AEoAM7OzgAAAHIXIAAAAAEAMAAA
AAAAixMAABYWAABBABAAGQoAAFMAEADoFgAAAAD1DxwAAAAVAQAA3BkAAwAAAACtnQAAAQAA
AGEAAAABAAAAAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA
bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwCAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUA
cwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD/////
//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAOAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAA
AAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA/AEAABAAAAABAAAAiAAAAAMA
AACQAAAADwAAALAAAAAEAAAAwAAAAAYAAADIAAAABwAAANAAAAAIAAAA2AAAAAkAAADgAAAA
CgAAAOgAAAAXAAAA8AAAAAsAAAD4AAAAEAAAAAABAAATAAAACAEAABYAAAAQAQAADQAAABgB
AAAMAAAAnAEAAAIAAADkBAAAHgAAABYAAABBNCBQYXBlciAoMjEweDI5NyBtbSkAZSAeAAAA
BgAAAE5va2lhAGVyAwAAAP6uAAADAAAADQAAAAMAAAABAAAAAwAAAAAAAAADAAAAAAAAAAMA
AAAAAAAAAwAAAA4bCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAHAAAA
EAAAAFRpbWVzIE5ldyBSb21hbgAaAAAATm9raWEgU2FucyBUaXRsZSBTZW1pQm9sZAALAAAA
Tm9raWEgU2FucwAQAAAATm9raWEgU2FucyBXaWRlAAYAAABBcmlhbAATAAAAQmxhbmsgUHJl
c2VudGF0aW9uAAIAAAAgAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAAFAAAAHgAA
ABAAAABEZXNpZ24gVGWBAAAAggAAAIMAAACEAAAA/v////7/////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////7/AAAFAAIAAAAAAAAA
AAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAGxNAAARAAAAAQAAAJAAAAACAAAA
mAAAAAMAAACoAAAABAAAALQAAAAFAAAAyAAAAAYAAADUAAAABwAAAIgBAAAIAAAAzAEAAAkA
AADgAQAAEgAAAOwBAAAKAAAAEAIAAAsAAAAcAgAADAAAACgCAAANAAAANAIAAA4AAABAAgAA
DwAAAEgCAAARAAAAUAIAAAIAAADkBAAAHgAAAAYAAABJUHY2IABmAB4AAAABAAAAAFB2Nh4A
AAAJAAAAZnRlbXBsaW4AACAAHgAAAAEAAAAAdGVtHgAAAKoAAABOb2tpYSBTdGFuZGFyZCBQ
cmVzZW50YXRpb24gVGVtcGxhdGUgLSBBNA0Kdi4gNiAyMDAyLzA2LzEyIEp1aGFuaSBQaXRr
5G5lbg0KTm9raWEgQ29ycG9yYXRlIEZvbnRzDQpQcm92aWRlZCBieTogTkJJXElNU1xJVFBc
Q1BcT2ZmaWNlIFBsYXRmb3Jtcw0KTkJJIE93bmVyOiAgRXJpYyBCZWFzbGV5AHQAHgAAADoA
AABDOlxVU0VSU1xVU0VSSU5GXE1TT0ZGSUNFXFRFTVBMQVRFXEJsYW5rIFByZXNlbnRhdGlv
bi5wb3QAIEoeAAAACQAAAGZ0ZW1wbGluAFVTRR4AAAACAAAANABlbR4AAAAZAAAATWljcm9z
b2Z0IFBvd2VyUG9pbnQgNC4wAFxURUAAAADQ1BqWBAAAAEAAAAAAADndgZK/AUAAAAAwDZkn
PRjEAUAAAABA1QtzQhjEAQMAAAAPAAAAAwAAADMAAABHAAAAFEsAAP////8DAAAACACJEHQL
AAABAAkAAAOCJQAAAgDRJAAAAAARAAAAJgYPABgA/////wAAEAAAAAAAAAAAAMADAACZAgAA
CQAAACYGDwAIAP////8CAAAAFwAAACYGDwAjAP////8EABsAVE5QUBQA2ADmADIAAAD//08A
FAAAAE0AaQCZAAoAAAAmBg8ACgBUTlBQAAACAPQDCQAAACYGDwAIAP////8DAAAADwAAACYG
DwAUAFROUFAEAAwAAQAAAAEAAAAAAAAABQAAAAsCAAAAAAUAAAAMApkCwAMFAAAACQIAAAAC
BQAAAAEC////AgUAAAAEAQ0AAAAFAAAABwEDAAAA0SQAAEELIADMAG8AoAAAAAAAmQLAAwAA
AAAoAAAAoAAAAG8AAAABAAgAAAAAAGBFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAA
AICAAIAAAACAAIAAgIAAAMDAwADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIi
IgApKSkAVVVVAE1NTQBCQkIAOTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMA
AABmAAAAmQAAAMwAADMAAAAzMwAAM2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABm
zAAAZv8AAJkAAACZMwAAmWYAAJmZAACZzAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8A
AP9mAAD/mQAA/8wAMwAAADMAMwAzAGYAMwCZADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMz
zAAzM/8AM2YAADNmMwAzZmYAM2aZADNmzAAzZv8AM5kAADOZMwAzmWYAM5mZADOZzAAzmf8A
M8wAADPMMwAzzGYAM8yZADPMzAAzzP8AM/8zADP/ZgAz/5kAM//MADP//wBmAAAAZgAzAGYA
ZgBmAJkAZgDMAGYA/wBmMwAAZjMzAGYzZgBmM5kAZjPMAGYz/wBmZgAAZmYzAGZmZgBmZpkA
ZmbMAGaZAABmmTMAZplmAGaZmQBmmcwAZpn/AGbMAABmzDMAZsyZAGbMzABmzP8AZv8AAGb/
MwBm/5kAZv/MAMwA/wD/AMwAmZkAAJkzmQCZAJkAmQDMAJkAAACZMzMAmQBmAJkzzACZAP8A
mWYAAJlmMwCZM2YAmWaZAJlmzACZM/8AmZkzAJmZZgCZmZkAmZnMAJmZ/wCZzAAAmcwzAGbM
ZgCZzJkAmczMAJnM/wCZ/wAAmf8zAJnMZgCZ/5kAmf/MAJn//wDMAAAAmQAzAMwAZgDMAJkA
zADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADMZjMAmWZmAMxmmQDMZswAmWb/AMyZ
AADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzMmQDMzMwAzMz/AMz/AADM/zMA
mf9mAMz/mQDM/8wAzP//AMwAMwD/AGYA/wCZAMwzAAD/MzMA/zNmAP8zmQD/M8wA/zP/AP9m
AAD/ZjMAzGZmAP9mmQD/ZswAzGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA/5n/AP/MAAD/zDMA
/8xmAP/MmQD/zMwA/8z/AP//MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/ZmYA/2b/AP//
ZgAhAKUAX19fAHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx8QD4+PgA
8Pv/AKSgoACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AP//////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////wAA/wAAAAD/AP//AP8A//8AAP//////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////8A//8AAP//////AAAAAP//////////////////////
////////////////////////////////AAAAAAAAAP//////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////AAD//wAAAP//////////////////////
////////////////////////////AP////////8A////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////AAAAAAD/AP///////wD/////////////////////////
//////////////8A////////AP///////////wD/////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////8A////AAD/////AAD/////////AP//////////////////////////
//////8AAAAA/wAAAAD/AP//////////////AP//////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////wD/AP///////////////////wAAAAAAAP//AAD/AAD/AP8A/wAA////
//8A////////////AP////////////////8A////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////8AAAD/////////////////////AP///wAA//////////////////////8A
/////////////////////////////////wD///8A////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////8AAAD//////////////////////wD/////AP////////////////////8A////
//////////////////////////////8AAAAA/wAAAP//////////////////////////////
////////////////////////////////////////////////////////////////////////
//////8AAP//AP////////////////////////////8A//////////////////8A////////
////////////////////////////AP////////8A////////////////////////////////
////////////////////////////////////////////////////////////////////////
////AP////8A////////////////////////////AP///////////////wAAAP//////////
//////////////////////////8A/////////wD/////////////////////////////////
////////////////////////////////////////////////////////////////////////
/wD//////wD//////////////////////////wAA//////8A////AAD//wD/////////////
////////////////////////AP//////////AP//////////////////////////////////
//////////////////////////////////////////////////////////////////////8A
////////AAAAAAAAAP////////////////8A/wAA////AP//AP//////////////////////
/////////////////////////////////wD/////////////////////////////////////
////////////////////////////////////////////////////////////////////AP8A
/////wAAAAD//wAAAAD/////////////AP//AP///wD//wD/////////////////////////
////////////////////////////////AP//////////////////////////////////////
//////////////////////////////////////////////////////////////////8AAP//
AAAAAP//////AP8A////////////AAD///8A//8A/wD/////////////////////////////
/////////////////////////////wD/////////////////////////////////////////
//////////////////////////////////////////////////////////////8A/////wD/
//8AAP//////AAD/////////AAD/////AP//AP8A////////////////////////////////
//////////////////////////8A////////////////////////////////////////////
//////////////////////////////////////////////////////////8A//////8AAP//
/wAA/////wAAAP///////wD///////8A/wD/AP//////////////////////////////////
/////////////////////////wAA////////////////////////////////////////////
////////////////////////////////////////////////////////AP//////AP///wDH
AAD//wAA/wD/////////////////AP//AAD/////////////////////////////////////
//////////////////////8A/wD/////////////////////////////////////////////
/////////////////////////////////////////////////////wD//////wD///8A/McA
/////wC8vJFn/////////////wD//wAA/////////////////////////////0FBQUFBQUFB
QUFBQf////////////8A////AAD//////////////////////////wAA/wAAAP8AAAD/AAD/
AP8AAP8A/wAA/wAA//8AAP////////////////////////////8AAP////8AAP///wAAx8f/
//+MvN21bWz///////8AAAD///8AAP////////////////////9BQUFBQUH/////////////
//9BQUH/////////AP//////AP//////////////////////////////////AP//////////
/////////////////////////////////////////////////wD//////wD/////////x8f/
1s+Nka/W/////////wAA////AAD/AAD//////////0FBQUFB////////////////////////
////QUH//////wD//////wD/////////////////////////////////////////////////
////////////////////////////////////////////////AAD///8AAP8A////////x8eR
1rWR////////////AP///wD/AABB////QUFBQUH/////////////////////////////////
////QUH///8A////////AP///////////////////////wAAAAAAAP//////////////////
//////////////////////////////////////////////8A//////8AAAAAAP8AAAAAx8fH
/////////////wD///8AAP9B+UFBQf//////////////////////////////////////////
////QQAA/////////wD///////////////8AAAD//wD//////wD//////wD/////////////
////////////////////////////////////////////AP////////////8A/wAA/////8fH
x/////////+8vJFnAP9B+UH/////////////////////////////////////////////////
/wBBQf////////8A/////////////wAAAP//AAD/////////AP////8A////////////////
/////////////////////////////////////////wD////////////////////////////H
x8f///+MvN21bWz//////////////////////////////////////////////////////wD/
//9B/////////wD//////////wD///////////////////8AAAAA////////////////////
////////////////////////////////////////AP//////////////////////////////
x8fH1s+Nka/W////////////////////////////////////////////////////////////
/0H///////8A/////////wD/////////////////////AAAA/wAA////////////////////
/////////////////////////////////////wD/////////////////////////////////
/8fH1rWR//////////////////////////////////////////////////////////8A////
QUH/////AP//////AAAA/////////////////////wD/AP///wD/////////////////////
////////////////////////////////////AP//////AP//////////////////////AAD/
/8fHAP////////8AAP////8A//8AAAAAAP8AAP8AAAAA/wD/AP///wAAAP8A/wD/AP//////
Qf///wD/////AAD//////////////wAA////////AP////8A////////////////////////
//////////////////////////////////8AAAAAAAD//////////////////////wD/////
/8fH////////AAAAAAD/AP//AAD/AAD/AP//AAAAAP8AAAAA//8AAAD/AAAA/wD///////9B
//8A/////wD//////////wAA/wD//wD//////wD//////wD/////////////////////////
////////////////////////////////////////AAD//wAA/////wAA/////wAA////////
AMf//////wAAAP///wD//wD//////wD//wD/////////////AAAA/wD//wAA//////8A/0EA
/////wD//////////wD//wD/////AAAA/wD///////8A////////////////////////////
//////////////////////////////////////8AAAD//wD//wAAAAD//wAA/////////wD/
x8f//////////////////////////////////////////////////////////////wD/Qf//
//8A/////////wD//////////wAAAAD/////////AAAA////////////////////////////
////////////////////////////////////////////AAAA////AAD/////////////AP//
x8f///////////////////////////////////////////////////////////8AAABBQf//
AAD/////AAAA//////////8A//8A/////////wD/AAD/////////////////////////////
/////////////////////////////////////////////////////////////////wAA/wD/
x8f//////////////////////////////////////////////////////////wD///9B//8A
AP///wD/////vLyRZ/////8A/wD//////wD///8A////////////////////////////////
//////////////////8AAAAAAAAAAAAAAP8AAAAAAAAAAP8AAAD/AAD//////////wAA////
x8f///////////////////////////////////////////////////////8AvLyRZ0FBAP//
//8A////jLzdtW1s//8A//8AAP///wAA/////wD/////////////////////////////////
//////////////////8AAP///wD/AP//AAAA/////wD/AP8A////////////////AP//////
x8fHx////////////////////////////////////////////////6z/jLzdtW1sAEFBQUFB
QUFBQdbPjZGv1gAAAP8AAAAA/wAA//////8A////////////////////////////////////
/////////////////////////////////////////////////////////////wD/////////
///Hx8fHx8fHx8f////////////////////////////////////8x9bPjZGv1gD//7y8kWf/
//9BQUG1kf8AAAAAAP//AP//////////AP//////////////////////////////////////
//////////////////////////////////////////////////////////8A////////////
////////////x8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/////kda1kf8A/4y83bVtbP//
/wAAQf8AAAAAAP///wD//////////wD/////////////////////////////////////////
////////////////////////////////////////////////////////AP//////////////
/////////////////////////////////////////////////wD/////AP/Wz42Rr9b///8A
//8A+QAAAAD///8A//////////8A////////////////////////////////////////////
//////////////////////////////////////////////////////8A////////////////
/////////////////////////////////////////////wAA/////wD//5HWtZH/////AAD/
AEH5AAAA////AP///////wAAAP//////////////////////////////////////////////
////////////////////////////////////////////////////AP//////////////////
//////////////////////////////////////////8A/wD/////AP////8AAP////8A//8A
AP8AAP//AAD/////////AP//////////////////////////////////////////////////
//////////////////////////////////////////////////8A////////////////////
//////////////////////////////////////8A//8A//////8AAP///wD/////AAAAAAAA
AP////8A/////////wD/////////////////////////////////////////////////////
////////////////////////////////////////////////AP//////////////////////
////////////////////////////////////AP//AP//////AP////8A////////////////
//8AAP////////8A////////////////////////////////////////////////////////
//////////////////////////////////////////////8A/////////////wD/////////
//////////////////////////////8AAP///wD///////8A////AAD//wD///////////8A
AP//////////AP//////////////////////////////////////////////////////////
/////////////////////////////////////////////wD//////////wD/////////////
//////////////////////////8A////////AP//////AP////8AAAAA//8AAP//////AP//
/////////wD/////////////////////////////////////////////////////////////
////////////////////////////////////////////AAAAAAAAAAD/AP//////////AP//
////////AP//////////////AP///////wD//////wD//////////wAAAAD/AAD/AAD/////
/////wAA////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////wD///////////8A////
//////8A////////////AP////////8A////////AP//////////////AAAAAAD/////////
/wAA////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////AAD///////8AAP//////
////AP//////////AP////////////////////8AAAD/AAD//////////////////////wAA
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////8AAAAAAAAA//8A////////
AP8A/////////wD/AAD/AAD/AP8A/wAA////////AP//AP////8AAP////////////8A////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////wD/////AP//
/wD/////AAD///////////////////////////////8AAAAAAAD/////AAD///8AAP//////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////AAAAAP//////
AAAAAP//////////////////////////////////////////AAAAAP8AAAAAAP//////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////8AAAAAAAAAAAAAAP8AAAAAAAAAAP8AAAD/AAD/////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////8AAP///wD/AP//AAAA/////wD/AP8A/wAA////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AP//////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////wD/
/////////////////////////////////////////////////////////////////////wD/
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////8A////
//////////8AAP8A//8AAAD/AP8AAP8A//8AAAD/AP8AAP8AAP////////////////8A////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////AP//////
//////8A//////////////////8A////////////////////////////////////AP//////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////wD//wD/AAAA
AP//AP8AAP8A/wAA/wAA/wD/AAD/AP//AP///////////////////////////wD/////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////8A////////////
//////////////////////////////////////////////////////////8A////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////AP//////////////
////////////////////////////////////////////////////////AP//////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////wD//////////////wAA
/wD//wAAAP8A/wAA/wD//wAAAP8A/wAA/wAA/////////////////wD/////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////8A/////////////wD/////
/////////////wD///////////////////////////////////8A////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////AP//AP8AAAAA//8A//8A/wD/
/wD/////////////////////////////////////////////AP//////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////wD//////////////wAA////////
/////////////////////////////////////////////wD/////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////8A////////////////////////////
//////////////////////////////////////////8A////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////AP//////////////////////////////
////////////////////////////////////////AP//////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////wAAAAAA/wAAAAAA/wAA/wD/
//8A////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////8AAAAAAP8AAP8AAP8AAP8AAP8A
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////AP8A////AP///wD/AAD/AP//AP//
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////wUAAAAHAQEAAAAIAAAA+gIFAAEA
AAAAAAAABAAAAC0BAAAHAAAA/AIBAAAAAAAAAAQAAAAtAQEADwAAACYGDwAUAFROUFAEAAwA
AAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xp
ZGUgVGl0bGVzAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPIAAAABQAAABfwJHj
1Z0AAAgA9AMDAOYAZnRlbXBsaW4IAAAAZgB0AGUAbQBwAGwAaQBuAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

--------------050504080802020602080102--




From owner-v6ops@ops.ietf.org  Fri Apr  2 02:02:16 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14865
	for <v6ops-archive@lists.ietf.org>; Fri, 2 Apr 2004 02:02:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9Idl-000N8O-CW
	for v6ops-data@psg.com; Fri, 02 Apr 2004 06:58:57 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9Idj-000N84-Qj
	for v6ops@ops.ietf.org; Fri, 02 Apr 2004 06:58:56 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i326wod25380;
	Fri, 2 Apr 2004 09:58:50 +0300
Date: Fri, 2 Apr 2004 09:58:49 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Fred Templin <ftemplin@iprg.nokia.com>
cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a 
 lter natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-0 9
 .txt] ]
In-Reply-To: <406C78AA.3010104@iprg.nokia.com>
Message-ID: <Pine.LNX.4.44.0404020950380.25265-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 1 Apr 2004, Fred Templin wrote:
> >The check only protects from someone spoofing their v4 address.  If 
> >the use of link-locals by strangers (remember that these have TTL=255 
> >and are allowed to do anything Neighbor Discovery -wise) is 
> >categorically thought to be harmful (I certainly think so), this 
> >doesn't really help.
> 
> Right, but this is an issue for the upper layers (e.g., ND handling code).

I have to disagree with that.  ND operates with very specific security
assumptions (TTL=255, link-local messages is considered "reasonably
safe").  Those assumptions are valid for typical links (physical,
local point-to-point tunnels, etc.).

Making it possible to send TTL=255 + LL packets from everywhere in the 
Internet breaks this assumption.

So, my argument is that while that assumption has not been
sufficiently well spelled out, you must avoid breaking that assumption
rather than say, "whoops -- we broke the assumption.  Well, figure out
a new means to secure ND, deploy it everywhere where this mechanism is 
deployable -- and make sure it interoperates with current ND 
specifications."

> >Of course, but as LL's are treated specially e.g. by ND code, this 
> >makes the ISATAP decapsulation non-equivalent to 6to4 decapsulation.
>
> I'm not sure what you mean by this; ND handling code comes *after*
> decapsulation; not during - correct? The only mitigations specified
> by 6to4 for decapsulation are found in the second paragraph of
> ([RFC3056], section 10) and these are optional.
> 
> The final sentence of that paragraph says: "2002:: traffic must also
> be excepted from checks applied to prevent spoofing of "6 over 4"
> traffic [6OVER4]." Perhaps a similar sentence with
> s/6over4/ISATAP is needed somewhere?

Link-locals can be discarded by the 6to4 pseudo-interface, as they are
not used for anything.  The spec does not say anything about that.  
(Obviously, discarding is not possible with ISATAP so they aren't
equivalent in that regard.)  draft-ietf-v6ops-6to4-security-02.txt
does mention this though, under "Attacks with ND Messages".

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




From owner-v6ops@ops.ietf.org  Fri Apr  2 06:35:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04198
	for <v6ops-archive@lists.ietf.org>; Fri, 2 Apr 2004 06:35:00 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9Mtc-000Kst-UG
	for v6ops-data@psg.com; Fri, 02 Apr 2004 11:31:36 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9MtY-000KhJ-RK
	for v6ops@ops.ietf.org; Fri, 02 Apr 2004 11:31:33 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i32BUtS29103;
	Fri, 2 Apr 2004 14:30:55 +0300
Date: Fri, 2 Apr 2004 14:30:55 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Fernando Gont <fernando@gont.com.ar>
cc: tcpm@ietf.org, <v6ops@ops.ietf.org>, <sebastien.roy@sun.com>
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when   connecting
In-Reply-To: <4.3.2.7.2.20040322073643.00b1b4a0@mail.daleclick.com>
Message-ID: <Pine.LNX.4.44.0404021426220.29062-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

I've been waiting for other comments on this, but none have emerged 
so...

What I propose as a way forward for this specific Informational 
document:

 1) state the reasons why this specific connect() etc. behaviour is 
desirable (read: why many vendors have already done that), and what 
drawbacks it could have (if any), and

 2) state the desire for getting a better higher-level API which would
handle all of this and much more (instead of/in addition to 1), but
mention why this is not an only practical solution.

Does this sound reasonable and well-balanced?

On Mon, 22 Mar 2004, Fernando Gont wrote:
> At 16:39 20/03/2004 +0200, Pekka Savola wrote:
> 
> > > Does it really make sense to handle the whole connection establishment
> > > issue inside the app, instead of inside the API itself?
> >Those are the core APIs we have today.  We could have better ones, but
> >IMHO I think we need to fix problems in the current ones as long as we
> >don't have a widely-deployed alternative.
> 
> IMHO, there are two points to note:
> 
> * If you fix the current ones so that their behavior is "acceptable" to the 
> application programmer, then it'll be harder to introduce a new API. People 
> is reluctant to change, so they must have a reason for learning a new API. 
> If you try to fix the current one, they will find fewer reasons for the change.
> 
> * You said "we don't have a widely-deployed alternative". Unless you meant 
> "we don't have a well-tested alternative", I'd say that it's a 
> chicken-and-egg problem. That means, for an API to be widely deployed, 
> people would have to use it. And for people to use it, they should be able 
> to find a good reason to do it.
> 
> Yes, I'm aware that my proposal my sound as a long-term solution. But, 
> IMHO, it will certainly be harder to introduce a new API if you actually 
> want to do it "in long term".
> I guess "timing" is an issue, here.
> 
> 
> 
> > > I think that if we're debating this, we're implicitly assuming that
> > > applications want to connect to say www.example.com, and not one specific
> > > IP address to which it maps to.
> > >
> > > So why not implement such a "higher-level" connect(), and handle all the
> > > relevant issues inside the API?
> >
> >Defining such APIs is probably beyond the scope of the work we can do,
> >and the things we can fix except in the 5+ year timeframe.. but if I
> >get you right, you're proposing that instead of:
> >
> >  1) getaddrinfo() or gethostbyname() and connect for one address,
> >[where, arguably, TCP retry timeout could be warranted -- I don't
> >think so myself, but you could argue for it]
> >
> >  2) getaddrinfo() / gethostbyname() loop to connect to one address
> >[where TCP retry timeout could not be warranted]
> >
> >You'd be proposing to create a new function to accomplish 2) in such a
> >manner that it would also react to ICMP messages, etc?
> 
> Exactly.
> 
> Then, within that function, each individual connect() could react to ICMP 
> messages a
> as you proposed, but if all addresses fail because of ICMP errors, it could 
> let TCP retry in the hope the transiet problem will dissappear.
> 
> 
> [....]
> > > Doesn't the problem really have to do with having applications performing
> > > such a low-level action?
> >
> >At some point, someone has to decide which behaviour is desirable.
> >Isn't this only hiding the same policy decision inside an abstraction
> >layer
> 
> Yes, but even when the difference may sound subtle, IMHO it's not.
> Having that abstraction layer is what let's you choose a policy, without 
> having the risk of causing any harm to existing apps.
> That way, if you ever need to change the low-level-connect() behavoir for 
> whatever reason, you could still do it. As far as the high-level connect() 
> behaves the same, there would be no problem.
> 
> Think about it. Why should an application programmer care about TCP 
> retries, ICMP erros, an the like?
> In the same way, why should he care about setting "strange" options such as 
> SO_REUSEADDR on his listening socket?
> Should *he* really handle byte-ordering issues  by means of htons() and the 
> like?
> 
> 
> >-- and the same could be achieved by e.g. a setsockopt() flag?
> 
> Strictly speaking, you *could* do that. But then you'd have all programmers 
> implementing themselves a function you could provide them.
> You'd have all them implementing the getaddrinfo()/gethostbyname() loop, 
> setting a strange socket option, etc. Why not provide them with a 
> well-tested function, and let them spend their time implementing their 
> application itself?
> 
> 
> 
> >(I don't deny that better APIs would not hurt, but we still seem to
> >require low-level C-like primitives, and unless there are additional
> >ones implemented there, we still have to fix the problems somehow..)
> 
> Well, the low-level ones could be provided as part of the new API.
> 
> Or along with the providing a new API, the current one could be modified as 
> you suggest. It wouldn't hurt too much if the *low-level* API aborted a 
> connection establishment because an ICMP error is received. Being a 
> *low-level* API, you'd be suppossed to know the details behind the function.
> 
> Best Regards,
> 
> 
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> 
> 
> 
> 

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




From owner-v6ops@ops.ietf.org  Fri Apr  2 08:17:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08301
	for <v6ops-archive@lists.ietf.org>; Fri, 2 Apr 2004 08:17:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9OUv-0003LN-VO
	for v6ops-data@psg.com; Fri, 02 Apr 2004 13:14:13 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9OUJ-00037E-7I
	for v6ops@ops.ietf.org; Fri, 02 Apr 2004 13:13:35 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i32DDPq30963;
	Fri, 2 Apr 2004 16:13:25 +0300
Date: Fri, 2 Apr 2004 16:13:24 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Ralph Droms <rdroms@cisco.com>
cc: v6ops@ops.ietf.org
Subject: Re: DHCP auth in unmanaged [Re: WG Last Call:  draft-ietf-v6ops-unmaneval-01.txt]
In-Reply-To: <4.3.2.7.2.20040325084437.027e9520@flask.cisco.com>
Message-ID: <Pine.LNX.4.44.0404021431130.29062-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 30 Mar 2004, Ralph Droms wrote:
> I can walk into a WiFi hotspot today, establish a new trust relationship
> that I haven't used before, and establish a secure link to the Internet
> that uses a DHCP-delegated IPv4 address.  Delegating a prefix with DHCPv6
> is essentially the same problem as obtaining an IPv4 address with DHCPv4.
> What is the problem we need to solve with DHCPv6?

The requirements aren't.  The specifications are not.  DHCPv4 does not
even try to provide any security.  DHCPv6 goes at great length to do
that.  DHCPv6 Prefix Delegation specified using authentication as a
SHOULD.  It's pretty important to be able to conform to that SHOULD.

> >  2) before getting IP
> >addresses in the first place (that is, if you don't have an address
> >yet, you cannot run mechanisms which help in making the key sharing
> >simpler).
> 
> Whether or not an IP address has been obtained is irrelevant to the
> problem and especially to DHCPv6 prefix delegation.

You cannot run other protocols (e.g., key management protocols) unless
you have IP addresses, so this is at least somewhat relevant.  Of
course, as the current authentication scheme relies on off-band
mechanisms, but if those were found to be problematic, automation
might help.  But that is rather difficult, lacking IP addresses (or at
least non-LL addresses).


> >But you raise a good point: I think we should spell out the obvious,
> >that rather than trying to operate with *really* shared links, the
> >operators should strongly consider mechanisms (any pointers?) which
> >achieve the isolation, making the issues more complex.
> 
> OK, and I think that secured, non-shared links really are the norm.
> 
> As security issues are explicitly described in more detail in the
> DHCPv6 and PD RFCs, I suggest the text about security be replaced with
> pointers to the discussions of security in those two documents:
> 
> 4.1.2   Explicit prefix delegation
> 
>     Several networks have already started using an explicit prefix
>     delegation mechanism using DHCPv6 [RFC3633]. In this mechanism, the
>     gateway uses a DHCP request to obtain a prefix from a DHCP server
>     managed by the ISP. The DHCP server identifies the gateway, for
>     example, through identification information provided by the gateway
>     in the DHCP request message or by the port or circuit through which
>     the DHCP request message is received.  The server can implement
>     prefix delegation policies based on the identity of the requesting
>     gateway.  According to the recommendations in RFCxxxx the ISP
>     assigns a /48 to the customer. The gateway then automatically
>     assign /64s out of this /48 to its internal links.

Sounds reasonable.
 
> (Editorial notes:
>   * I don't think the acronym "ISP" is defined anywhere in the document
>   * There doesn't seem to be a citation of RFC 3315 anywhere in the document
>   * There should be citations of RFC 2131 and RFC 2132 for DHCPv4)

I'd maybe add here:

      In a typical scenario, the link between the user and the ISP is 
      point-to-point, set up using some (semi-)trusted mechanism, and 
      DHCP authentication is not deemed necessary.  In some other 
      cases, the link is shared between the users, but the customers
      are isolated from each other using special techniques such as 
      proxy ARP; in these scenarios, DHCP authentication may not be 
      required either.  However, there are a few rather rare cases 
      where the customers really share a network, and in such a 
      network DHCP authentication is required; key management, 
      however, may prove a challenge.

>     Security issues associated with DHCP and prefix delegation are
>     addressed in the "Security Considerations" section of RFC 3315
>     and RFC 3633, respectively.

I don't think the security issues have been sufficiently addressed in
those documents.
 
> 4.1.3   Recommendation
> 
>     The ND proxy and DHCP methods appear to have different domains of
>     application. ND proxy is a simple method that corresponds well to
>     "informal sharing" of a link, while explicit delegation provides
>     strong administrative control. The ND proxy mechanism has not yet
>     been accepted as an Internet Standard and the interaction
>     between neighbor discovery and ND proxy needs to be specified.

The latter part is confusing as well.  DHCPv6 is not an "Internet 
Standard" either :-).  Actually I don't even understand what you're 
trying to say.  Instead e.g.:

 4.1.3   Recommendation

     The ND proxy and DHCP methods appear to have different domains of
     application. ND proxy is a simple method that corresponds well to
     "informal sharing" of a link, while explicit delegation provides
     strong administrative control. The specification of of ND-proxy 
     is still in progress, and aimed at Informational category, rather 
     than Standards Track.

> > > If customers do truly
> > > share a link, there are *many* other attacks available and pointing out 
> > DHCP
> > > as a specific problem is only telling part of the story.
> >
> >Yep, but that's the only story being covered in that section of the
> >document...
> 
> It's also the only place in the document where specific security issues are
> raised beyond the level of "Specific security issues should be studied and
> addressed during the development of the specific mechanisms."

If you have pointers about problems with other mechanisms, please
raise them.  Note that in most cases, the mechanisms are still under
development (Teredo, tunnel broker, etc.) or being studied
security-wise (6to4).  DHCPv6 is an example for which these issues 
haven't been raised yet, so this seems like a place to do so.

> >If they provide a password, that's fine.  As long as it's clear how
> >they provide it, and how it would end up being configured in the
> >router. (Trivial if the ISP ships the box to the user, possibly
> >non-trivial otherwise.)
> >
> >I think the shared key model also requires that the key stays as it
> >forever (providing for better brute-force attacks against it), unless
> >you do re-keying or the like somehow.  But that would probably be
> >equally problematic.
> 
> Which is exactly the model employed in the equivalent problem of
> address assignment today.  Why are the requirements for prefix
> delegation stricter than for what is deployed today?

If DHCPv6 includes a feature, and DHCPv6 PD requires it's used with a
SHOULD, it should be feasible to do so.  If a feature is made
available, it should also be possible to use it in the cases where
it's relevant.
 
> > > The issue of DHCPv6 security is adequately addressed in RFC3315 and need
> > > not be rehashed here.  Anyone who reads RFC3315 (btw, the reference
> > > [DNSDHCPV6] is never cited anywhere in the body of the document) will
> > > see the security analysis for DHCPv6.
> >
> >The security analysis in there is restricted to the scenario which
> >may not be directly applicable here:
> >
> >    This protocol is focused on solving the intradomain problem where the
> >    out-of-band exchange of a shared key is feasible.
> >
> >This is inter-domain, and whether sharing keys is feasible is an open
> >question. (In some cases, with some constraints, it certainly seems to
> >be possible, but...)
> 
> The common model today is to establish a separate security relationship
> with different administrative domains and select the appropriate
> relationship as needed.  The same strategy can be applied to prefix
> delegation - if, indeed, any ISP actually deploys a network in which
> customers really see each others traffic on a shared link.

Again, this is more complex than in some other protocols 
because automating key management is difficult -- see 
draft-bellovin-mandate-keymgmt-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





From owner-v6ops@ops.ietf.org  Fri Apr  2 08:46:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08991
	for <v6ops-archive@lists.ietf.org>; Fri, 2 Apr 2004 08:46:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9OyE-000KnQ-QU
	for v6ops-data@psg.com; Fri, 02 Apr 2004 13:44:30 +0000
Received: from [131.228.20.26] (helo=mgw-x3.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9Oy0-000KcB-MR
	for v6ops@ops.ietf.org; Fri, 02 Apr 2004 13:44:16 +0000
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32DiC306552;
	Fri, 2 Apr 2004 16:44:12 +0300 (EET DST)
X-Scanned: Fri, 2 Apr 2004 16:43:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i32DhUkb020232;
	Fri, 2 Apr 2004 16:43:30 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks004.ntc.nokia.com 00BFgqED; Fri, 02 Apr 2004 16:38:00 EEST
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32DbsF20866;
	Fri, 2 Apr 2004 16:37:54 +0300 (EET DST)
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 2 Apr 2004 16:37:15 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt]
Date: Fri, 2 Apr 2004 16:37:14 +0300
Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE2A5@esebe005.ntc.nokia.com>
Thread-Topic: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt]
Thread-Index: AcQTIpUxCyVc2R5NTVm6JnnwmNHkhgABX6eQAWNhnFA=
From: <juha.wiljakka@nokia.com>
To: <H.Soliman@flarion.com>, <pekkas@netcore.fi>
Cc: <karim.el-malki@ericsson.com>, <v6ops@ops.ietf.org>,
        <Jonne.Soininen@nokia.com>
X-OriginalArrivalTime: 02 Apr 2004 13:37:15.0466 (UTC) FILETIME=[9C5D52A0:01C418B7]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable


 Hi!

After browsing through these quite long e-mail threads I also send some =
personal comments on the mailing list:
 - When thinking about potential IPv6-in-IPv4 tunneling in the UE, a =
simple automatic mechanism most probably is the best fit
 - I tend to prefer mechanisms that have been deployed already, i.e. =
existing (commerical) implementations are speaking for the usability of =
a mechanism. We don't have so much experience on newer mechanisms (such =
as STEP) yet.
 - What comes to ISATAP (now we are talking about draft -20), I would =
prefer waiting until the next version is published, and continue =
discussion after that
 - It is important to publish the incoming ISATAP draft as an =
Info/Experimental RFC (and thus document the existing implementations), =
*but* I also would like to see ISATAP on the Standard's Track. That's =
because I see it as a useful mechanism - and not only in the UE =
tunneling case.

BR,
	-Juha W.-

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext Soliman Hesham
Sent: 26 March, 2004 14:09
To: Pekka Savola
Cc: Karim El-Malki (HF/EAB); v6ops@ops.ietf.org; Soininen Jonne
(Nokia-NET/Helsinki)
Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on
draft-ietf-v6ops-3gpp-analysis-09.txt]

 > > =3D> One answer to all of the above: The whole point of =
recommending
 > > a solution in specific scenarios is to assess the feasability
 > > of the solution to that particular deployment. None of the above
 > > is relevant for 3GPP:
 > >   - On this point to point link ingress filtering in the GGSN=20
 > >     stops address spoofing.
 >=20
 > If that's enabled, that is.  But as you see, this issue is=20
 > not limited=20
 > to being (or not being) able to spoof your IPv4 address.

=3D> So this is a non-issue, ok? If it is, we can add=20
a sentence to reflect this requirement.

 >=20
 > >   - It's always used in the same admin domain, logically, i.e.
 > >     as far as the IP layer can see.
 >=20
 > You misunderstand the concept of administrative domains.  Is=20
 > the home=20
 > user and his (hers) ISP in the same administrative domain as well? =20
 > No, they are not.  3GPP UE is managed by the user, not the 3GPP=20
 > operator.  3GPP operator cannot trust whoever uses the UE.  UE users=20
 > cannot trust other UE users.

=3D> Huh??? How is this specific to ISATAP???
Any user can setup a tunnel to a tunnel agent and bomb
someone else. This is the same for MIP. Ok, so you
say the tunnel in other cases is secure and the user=20
can be identified. Here the tunnel is not secure of=20
course, but the user was authenticated and authorised
for network access and can be tracked. Can you tell
me how this is different from tracking an abusive
MN that floods other nodes through its HA?

 >=20
 > >   - 6-to-4 is not recommended and should not be used by end
 > >     hosts. We discussed this several times and even Brian C
 > >     recommended against this a couple of years ago.=20
 >=20
 > Such recommendation is not grounded on reality.  It is used by hosts
 > by the million, and there is nothing we can do to get it out from
 > there. =20

=3D> By the million? You're right, I'm not grounded in reality.
At least not in your reality....

   I'd suspect many UEs would include 6to4 capability themselves

=3D> What is your suspicion grounded on?

 > (I seem to recall hearing some UE pilot stacks would have), e.g. for
 > trying to obtain IPv6 access in WLANs.

=3D> I see.

 > > Given the above conditions, there is no security problems
 > > that we can see.
 >=20
 > Perhaps you just don't look sufficiently hard enough :-)

=3D> I assume you looked pretty hard, please write a threat=20
to the list and we can begin from there. I'm talking about
a detailed threat here, not "User A floods User B". This
might be the beginning of a productive discussion.
Unlike the condescending statement above which is an=20
end to a discussion. =20


 >=20
 > To be frank, the argument has sounded a bit like, "we want to have a
 > recommended solution soon, as long as it's the solution we have in
 > mind".  Where are the requirements?
 >=20
 > It seems in many cases, a driver for ISATAP has been its
 > auto-discovery function.  Oh really -- that's implementable in about
 > every solution in a dozen of lines of code :).  Not really a good=20
 > reason to be blindfolded to just look at one solution, IMHO.

=3D> I'm not going to go into this again. We had both operators
and vendors supporting this. In Seoul there was no objection
to standardising ISATAP.
You still haven't answered my question, why aren't you asking=20
the WG? Normally one person's opinion doesn't reverse WG
concensus. Is this a special case?

I'll move on from this if the WG concensus is to not support
ISATAP in this scenario.=20

Hesham





From owner-v6ops@ops.ietf.org  Fri Apr  2 12:44:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20669
	for <v6ops-archive@lists.ietf.org>; Fri, 2 Apr 2004 12:44:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9Sf4-000AEN-Vl
	for v6ops-data@psg.com; Fri, 02 Apr 2004 17:40:58 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9Seq-000ACk-7k
	for v6ops@ops.ietf.org; Fri, 02 Apr 2004 17:40:44 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i32HeQn30660;
	Fri, 2 Apr 2004 09:40:26 -0800
X-mProtect: <200404021740> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdCdwSXh; Fri, 02 Apr 2004 09:40:24 PST
Message-ID: <406DA59A.5040207@iprg.nokia.com>
Date: Fri, 02 Apr 2004 09:40:42 -0800
From: Fred 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: Pekka Savola <pekkas@netcore.fi>
CC: Ralph Droms <rdroms@cisco.com>, v6ops@ops.ietf.org
Subject: Re: DHCP auth in unmanaged [Re: WG Last Call:  draft-ietf-v6ops-unmaneval-01.txt]
References: <Pine.LNX.4.44.0404021431130.29062-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka and Ralph,

Minor change suggestion for the proposed text:

Pekka Savola wrote:

> 4.1.3   Recommendation
>
>     The ND proxy and DHCP methods appear to have different domains of
>     application.
>

s/different/complimentary

Fred
ftemplin@iprg.nokia.com





From owner-v6ops@ops.ietf.org  Fri Apr  2 12:56:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21040
	for <v6ops-archive@lists.ietf.org>; Fri, 2 Apr 2004 12:56:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9Ssc-000LzB-OF
	for v6ops-data@psg.com; Fri, 02 Apr 2004 17:54:58 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9SsF-000LpW-4g
	for v6ops@ops.ietf.org; Fri, 02 Apr 2004 17:54:35 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i32HsQd22547;
	Fri, 2 Apr 2004 09:54:26 -0800
X-mProtect: <200404021754> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdUIS4wf; Fri, 02 Apr 2004 09:54:19 PST
Message-ID: <406DA8DE.1000702@iprg.nokia.com>
Date: Fri, 02 Apr 2004 09:54:38 -0800
From: Fred 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: Pekka Savola <pekkas@netcore.fi>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a
  lter natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-0
 9 .txt] ]
References: <Pine.LNX.4.44.0404020950380.25265-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



Pekka Savola wrote:

>On Thu, 1 Apr 2004, Fred Templin wrote:
>  
>
>>>The check only protects from someone spoofing their v4 address.  If 
>>>the use of link-locals by strangers (remember that these have TTL=255 
>>>and are allowed to do anything Neighbor Discovery -wise) is 
>>>categorically thought to be harmful (I certainly think so), this 
>>>doesn't really help.
>>>      
>>>
>>Right, but this is an issue for the upper layers (e.g., ND handling code).
>>    
>>
>
>I have to disagree with that.  ND operates with very specific security
>assumptions (TTL=255, link-local messages is considered "reasonably
>safe").  Those assumptions are valid for typical links (physical,
>local point-to-point tunnels, etc.).
>
>Making it possible to send TTL=255 + LL packets from everywhere in the 
>Internet breaks this assumption.
>

Well, we have made specific mention this assumption in past versions of
the draft, e.g, see Security considerations in:

  
http://www.join.uni-muenster.de/Dokumente/drafts/draft-ietf-ngtrans-isatap-03.txt

>So, my argument is that while that assumption has not been
>sufficiently well spelled out, you must avoid breaking that assumption
>rather than say, "whoops -- we broke the assumption.  Well, figure out
>a new means to secure ND, deploy it everywhere where this mechanism is 
>deployable -- and make sure it interoperates with current ND 
>specifications."
>

I think there may be other efforts in progress in regard to securing ND,
so for the time being I am fine with looking at a domain of applicability
that might be more constrained than including the entire Internet and
allowing other mechanisms to come online as they become mature.

>>>Of course, but as LL's are treated specially e.g. by ND code, this 
>>>makes the ISATAP decapsulation non-equivalent to 6to4 decapsulation.
>>>      
>>>
>>I'm not sure what you mean by this; ND handling code comes *after*
>>decapsulation; not during - correct? The only mitigations specified
>>by 6to4 for decapsulation are found in the second paragraph of
>>([RFC3056], section 10) and these are optional.
>>
>>The final sentence of that paragraph says: "2002:: traffic must also
>>be excepted from checks applied to prevent spoofing of "6 over 4"
>>traffic [6OVER4]." Perhaps a similar sentence with
>>s/6over4/ISATAP is needed somewhere?
>>    
>>
>
>Link-locals can be discarded by the 6to4 pseudo-interface, as they are
>not used for anything.  The spec does not say anything about that.  
>(Obviously, discarding is not possible with ISATAP so they aren't
>equivalent in that regard.)  draft-ietf-v6ops-6to4-security-02.txt
>does mention this though, under "Attacks with ND Messages".
>

Well, section 3.1 of RFC 3056 has something to say about (non)use of 
link-locals
for 6to4, but that text seems to me to be only a snapshot in time and 
not to be
taken as precluding the possibility of future scenarios requiring 
link-locals.

Fred
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Sat Apr  3 13:32:57 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29162
	for <v6ops-archive@lists.ietf.org>; Sat, 3 Apr 2004 13:32:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1B9prI-000G9g-Us
	for v6ops-data@psg.com; Sat, 03 Apr 2004 18:27:08 +0000
Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9prF-000G8t-B8
	for v6ops@ops.ietf.org; Sat, 03 Apr 2004 18:27:05 +0000
Received: from fernando.gont.com.ar ([200.68.210.155])
	by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id PAA13615;
	Sat, 3 Apr 2004 15:52:02 -0400
Message-Id: <4.3.2.7.2.20040403152932.00b26ae0@mail.daleclick.com>
X-Sender: fgont@mail.daleclick.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 03 Apr 2004 15:33:41 -0300
To: Pekka Savola <pekkas@netcore.fi>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when  
  connecting
Cc: tcpm@ietf.org, <v6ops@ops.ietf.org>, <sebastien.roy@sun.com>
In-Reply-To: <Pine.LNX.4.44.0404021426220.29062-100000@netcore.fi>
References: <4.3.2.7.2.20040322073643.00b1b4a0@mail.daleclick.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

At 14:30 02/04/2004 +0300, Pekka Savola wrote:

>What I propose as a way forward for this specific Informational
>document:
>  1) state the reasons why this specific connect() etc. behaviour is
>desirable (read: why many vendors have already done that), and what
>drawbacks it could have (if any), and

I agree.


>  2) state the desire for getting a better higher-level API which would
>handle all of this and much more (instead of/in addition to 1), but
>mention why this is not an only practical solution.

What do you mean "this is not an only practical solution"?


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





From owner-v6ops@ops.ietf.org  Sun Apr  4 16:11:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09967
	for <v6ops-archive@lists.ietf.org>; Sun, 4 Apr 2004 16:11:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BADt8-000G2z-0C
	for v6ops-data@psg.com; Sun, 04 Apr 2004 20:06:38 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BADsy-000G0K-KW
	for v6ops@ops.ietf.org; Sun, 04 Apr 2004 20:06:28 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP
	id 0CD1CF913; Sun,  4 Apr 2004 16:06:27 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Sun, 4 Apr 2004 16:06:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG Last Call: On-link Assumption and IPv6 On by default
Date: Sun, 4 Apr 2004 16:06:19 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612BE0E@tayexc13.americas.cpqcorp.net>
Thread-Topic: WG Last Call: On-link Assumption and IPv6 On by default
Thread-Index: AcQRb3uQY71IvTaZQGmRDo00TAmLUQJECEDg
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
Cc: <sebastien.roy@sun.com>
X-OriginalArrivalTime: 04 Apr 2004 20:06:27.0239 (UTC) FILETIME=[4FEE9B70:01C41A80]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

WG,

I have read both of these in depth and believe them to be result of
healthy consensus within the WG.  I support both documents going to the
IESG.=20

v6onbydefault-01 needs to affect the current standard so not sure how
the chairs want to present that to the IESG. This document as standard
is my suggestion and reflection of the result in 2461biz this way the
historical glue for the change is kept in tact and my suggestion.

v6onbydefault-01 should be an informational RFC.  Not BCP because this
work will last over time no matter what we do to IPv6 and a caution for
some time to all deployments of IPv6.

Good job to the authors and thanks for the contribution.

Now lets ship the freaking thing ok and move on :--).

thanks
/jim

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Wednesday, March 24, 2004 2:10 AM
> To: v6ops@ops.ietf.org
> Cc: sebastien.roy@sun.com
> Subject: WG Last Call: On-link Assumption and IPv6 On by default
>=20
> Hi all,
>=20
> This is a WG Last Call for comments on sending two documents to the
> IESG:
>=20
> 1) draft-ietf-v6ops-onlinkassumption-01.txt,=20
>    "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful",
>    target category BCP.
>=20
> 2) draft-ietf-v6ops-v6onbydefault-01.txt
>    "Issues with Dual Stack IPv6 on by Default",
>    target category Informational.
>=20
> Please review the documents carefully, and send your feedback=20
> to the list.  Please also indicate whether or not you believe=20
> that these documents are ready to go to the IESG.
>=20
> The last call will end in about 2 weeks, on 7th April.
>=20
> Pekka & Jonne
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Sun Apr  4 16:19:06 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10139
	for <v6ops-archive@lists.ietf.org>; Sun, 4 Apr 2004 16:19:05 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAE3j-000Ihp-Pu
	for v6ops-data@psg.com; Sun, 04 Apr 2004 20:17:35 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAE3h-000IhO-HZ
	for v6ops@ops.ietf.org; Sun, 04 Apr 2004 20:17:33 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id F2FDEB00F
	for <v6ops@ops.ietf.org>; Sun,  4 Apr 2004 16:17:32 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Sun, 4 Apr 2004 16:17:32 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C41A81.DC64BDD2"
Subject: FW: I-D ACTION:draft-ietf-v6ops-application-transition-02.txt
Date: Sun, 4 Apr 2004 16:17:25 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612BE11@tayexc13.americas.cpqcorp.net>
X-MS-Has-Attach: yes
Thread-Topic: I-D ACTION:draft-ietf-v6ops-application-transition-02.txt
Thread-Index: AcQYBF/yenHU9U92R8Od8HDeTprtTwCfU+uA
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Apr 2004 20:17:32.0776 (UTC) FILETIME=[DC9F7E80:01C41A81]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C41A81.DC64BDD2
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This is very good and useful piece of work and good job to all.  Can we
ship this as WG product? =20
thanks
/jim

-----Original Message-----
From: i-d-announce-admin@ietf.org [mailto:i-d-announce-admin@ietf.org]
On Behalf Of Internet-Drafts@ietf.org
Sent: Thursday, April 01, 2004 8:15 AM
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-application-transition-02.txt

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

	Title		: Application Aspects of IPv6 Transition
	Author(s)	: M. Shin, et al.
	Filename	: draft-ietf-v6ops-application-transition-02.txt
	Pages		: 30
	Date		: 2004-3-31
=09
As IPv6 networks are deployed and the network transition discussed, one
should also consider how to enable IPv6 support in applications running
on IPv6 hosts, and what is the best strategy to develop IP protocol
support in applications.  This document specifies scenarios and aspects
of application transition. It also proposes guidelines on how to develop
IP version-independent applications during the transition period.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transit
ion-02.txt

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


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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-ietf-v6ops-application-transition-02.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_001_01C41A81.DC64BDD2
Content-Type: application/octet-stream;
	name="ATT7902572.TXT"
Content-Description: ATT7902572.TXT
Content-Disposition: attachment;
	filename="ATT7902572.TXT"
Content-Transfer-Encoding: base64

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt
c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl
eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDA0LTQtMTA4MTk1NC5JLURAaWV0Zi5vcmc+DQoNCkVO
Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXY2b3BzLWFwcGxp
Y2F0aW9uLXRyYW5zaXRpb24tMDIudHh0DQo=

------_=_NextPart_001_01C41A81.DC64BDD2
Content-Type: application/octet-stream;
	name="draft-ietf-v6ops-application-transition-02.URL"
Content-Description: draft-ietf-v6ops-application-transition-02.URL
Content-Disposition: attachment;
	filename="draft-ietf-v6ops-application-transition-02.URL"
Content-Transfer-Encoding: base64

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLXY2b3BzLWFwcGxpY2F0aW9uLXRyYW5zaXRpb24tMDIudHh0DQo=

------_=_NextPart_001_01C41A81.DC64BDD2--



From owner-v6ops@ops.ietf.org  Mon Apr  5 02:29:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12449
	for <v6ops-archive@lists.ietf.org>; Mon, 5 Apr 2004 02:29:48 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BANYp-000Hnj-SF
	for v6ops-data@psg.com; Mon, 05 Apr 2004 06:26:19 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BANYn-000HnG-Sc
	for v6ops@ops.ietf.org; Mon, 05 Apr 2004 06:26:18 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i356PfR19322;
	Mon, 5 Apr 2004 09:25:42 +0300
Date: Mon, 5 Apr 2004 09:25:41 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Fernando Gont <fernando@gont.com.ar>
cc: tcpm@ietf.org, <v6ops@ops.ietf.org>, <sebastien.roy@sun.com>
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when    connecting
In-Reply-To: <4.3.2.7.2.20040403152932.00b26ae0@mail.daleclick.com>
Message-ID: <Pine.LNX.4.44.0404050922040.18946-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Sat, 3 Apr 2004, Fernando Gont wrote:
> At 14:30 02/04/2004 +0300, Pekka Savola wrote:
> >What I propose as a way forward for this specific Informational
> >document:
> >  1) state the reasons why this specific connect() etc. behaviour is
> >desirable (read: why many vendors have already done that), and what
> >drawbacks it could have (if any), and
> 
> I agree.

Great.

> >  2) state the desire for getting a better higher-level API which would
> >handle all of this and much more (instead of/in addition to 1), but
> >mention why this is not an only practical solution.
> 
> What do you mean "this is not an only practical solution"?

What I should have said if "but mention why this is would not be a 
practical solution, if there were no other solutions".

That is, new APIs would be great, but we cannot stop fixing problems
current APIs until we have something more concrete out there.  
Otherwise we'd end up with no practically (in short term) deployable
solution.

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




From owner-v6ops@ops.ietf.org  Mon Apr  5 02:33:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12693
	for <v6ops-archive@lists.ietf.org>; Mon, 5 Apr 2004 02:33:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BANfM-000JQ0-AH
	for v6ops-data@psg.com; Mon, 05 Apr 2004 06:33:04 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BANfK-000JOW-Ny
	for v6ops@ops.ietf.org; Mon, 05 Apr 2004 06:33:02 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i356WrW19477;
	Mon, 5 Apr 2004 09:32:54 +0300
Date: Mon, 5 Apr 2004 09:32:53 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Fred Templin <ftemplin@iprg.nokia.com>
cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a 
 lter natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-0 9
 .txt] ]
In-Reply-To: <406DA8DE.1000702@iprg.nokia.com>
Message-ID: <Pine.LNX.4.44.0404050925510.18946-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 2 Apr 2004, Fred Templin wrote:
> >I have to disagree with that.  ND operates with very specific security
> >assumptions (TTL=255, link-local messages is considered "reasonably
> >safe").  Those assumptions are valid for typical links (physical,
> >local point-to-point tunnels, etc.).
> >
> >Making it possible to send TTL=255 + LL packets from everywhere in the 
> >Internet breaks this assumption.
> 
> Well, we have made specific mention this assumption in past versions of
> the draft, e.g, see Security considerations in:
>   
> http://www.join.uni-muenster.de/Dokumente/drafts/draft-ietf-ngtrans-isatap-03.txt

Too bad this was removed and apparently forgotten by many WG 
participatents :-(

> >So, my argument is that while that assumption has not been
> >sufficiently well spelled out, you must avoid breaking that assumption
> >rather than say, "whoops -- we broke the assumption.  Well, figure out
> >a new means to secure ND, deploy it everywhere where this mechanism is 
> >deployable -- and make sure it interoperates with current ND 
> >specifications."
> 
> I think there may be other efforts in progress in regard to securing ND,
> so for the time being I am fine with looking at a domain of applicability
> that might be more constrained than including the entire Internet and
> allowing other mechanisms to come online as they become mature.

Good.  Note that for e.g. SEND to work, there has to be a trust 
anchor.  That's communicated using the routers.  If would not be 
routers (but everyone just on link), applying something like SEND to 
ISATAP would be very difficult or impossible.  So, while there is work 
in progress for ND, that work migth also be applicable only in the 
specific scenario it is designed for.

> >Link-locals can be discarded by the 6to4 pseudo-interface, as they are
> >not used for anything.  The spec does not say anything about that.  
> >(Obviously, discarding is not possible with ISATAP so they aren't
> >equivalent in that regard.)  draft-ietf-v6ops-6to4-security-02.txt
> >does mention this though, under "Attacks with ND Messages".
> >
> 
> Well, section 3.1 of RFC 3056 has something to say about (non)use of
> link-locals for 6to4, but that text seems to me to be only a
> snapshot in time and not to be taken as precluding the possibility
> of future scenarios requiring link-locals.

Agree.  As a matter of fact, long-since-expired 6to4 multicast
extensions used (AFAIR) link-local MLD messages on the
pseudo-interface.  But (more or less) luckily enough, that has not
materialized, and there is no current use for link-locals.  As a
matter of fact, the 6to4 security document recommends dropping them
(for what it's worth).

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




From owner-v6ops@ops.ietf.org  Mon Apr  5 09:46:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00878
	for <v6ops-archive@lists.ietf.org>; Mon, 5 Apr 2004 09:46:40 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAUNN-000I7s-WD
	for v6ops-data@psg.com; Mon, 05 Apr 2004 13:42:57 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAUNA-000I48-5t
	for v6ops@ops.ietf.org; Mon, 05 Apr 2004 13:42:44 +0000
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35DghPA028322
	for <v6ops@ops.ietf.org>; Mon, 5 Apr 2004 15:42:43 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 5 Apr 2004 15:42:43 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <212YYVWA>; Mon, 5 Apr 2004 15:42:43 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B5D@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'Pekka Savola'" <pekkas@netcore.fi>,
        Fred Templin
	 <ftemplin@iprg.nokia.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a
	  lter natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-
	0 9 .txt] ]
Date: Mon, 5 Apr 2004 15:42:21 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 05 Apr 2004 13:42:43.0066 (UTC) FILETIME=[DEDE5DA0:01C41B13]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

 > > >Making it possible to send TTL=255 + LL packets from 
 > everywhere in the 
 > > >Internet breaks this assumption.
 > > 
 > > Well, we have made specific mention this assumption in 
 > past versions of
 > > the draft, e.g, see Security considerations in:
 > >   
 > > 
 > http://www.join.uni-muenster.de/Dokumente/drafts/draft-ietf-n
 > gtrans-isatap-03.txt
 > 
 > Too bad this was removed and apparently forgotten by many WG 
 > participatents :-(

Don't think it was forgotten. At least our implementation does
the checks. The IPv4 spoofing protection on edge routers is a valid
assumption and should be mandated anyway. But I agree that the
current spec could do with several changes like this one. I am trying
to put together a list of things which I would like to see in a new
version of the ISATAP spec.

/Karim



From owner-v6ops@ops.ietf.org  Mon Apr  5 22:21:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06501
	for <v6ops-archive@lists.ietf.org>; Mon, 5 Apr 2004 22:21:54 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAg8L-000NoZ-0Q
	for v6ops-data@psg.com; Tue, 06 Apr 2004 02:16:13 +0000
Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAg8G-000No5-7t
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 02:16:08 +0000
Received: from fernando.gont.com.ar ([200.68.210.165])
	by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id XAA22746;
	Mon, 5 Apr 2004 23:46:11 -0400
Message-Id: <4.3.2.7.2.20040405210436.00c10e80@mail.daleclick.com>
X-Sender: fgont@mail.daleclick.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 05 Apr 2004 23:01:02 -0300
To: v6ops@ops.ietf.org
From: Fernando Gont <fernando@gont.com.ar>
Subject: Some comments on draft-ietf-v6ops-v6onbydefault-01.txt
Cc: sebastien.roy@sun.com, alain.durand@sun.com, james.paugh@sun.com,
        Pekka Savola <pekkas@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi all,

I've had a look on draft-ietf-v6ops-v6onbydefault-01.txt , and have some 
comments on it.

In section 2, it says:

"  An application on this system is trying to communicate with a
    destination whose name resolves to public and global IPv4 and IPv6
    addresses.  The application uses an address resolution API that
    implements the destination address selection mechanism described in
    Default Address Selection for IPv6 [ADDRSEL].  The application will
    attempt to connect to each address returned in order until one
    succeeds. "

I think this para provides a hint on where the problem really lays. An 
application wants to use a service, not a specific node or a specific 
attachment point. Therefore, it shouldn't be involved in selecting the node 
or the network interface on which the server is provided.


In section 2.1, it says:

"  Fixing the destination address selection mechanism by adding such a
    rule is only a mitigating factor if applications use standard name
    resolution API's that implement this mechanism, and these
    applications try addresses in the order returned.  This may not be an
    acceptable assumption in some cases, as there are applications that
    use hard coded addresses and address search orders (DNS resolver is
    one example), and/or literal addresses passed in from the user."

I'm aware of this. However, I'd not say it's good practice to do this. So, 
well, if you have problems (delays, performance, whatever), for using a 
hard-coded address (for example), well, you should not be doing it!


In section 2.3, it says:

"  When the unreachability of a destination is obviated by the reception
    of an ICMPv6 destination unreachable message, the transport layer
    should make it possible for the application to deal with this by
    failing the connection attempt, passing ICMPv6 errors up to the
    application, etc... "

This one has to do with what I pointed out above: Should an application 
programmer be concerned with a (probably transient) error at the network layer.
Should, for example, a database programmer be knowledgeable on this stuff 
(i.e., at this level of detail)?


In section 2.3.2, it says:


"2.3.2 UDP Implications

    As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass
    to the application layer all ICMP error messages that it receives
    from the IP layer.  As a result, proper handling destination
    unreachability by UDP applications is the responsibility of the
    applications themselves."

Note that, IIRC, the socket API pass ICMP errors only on *connected* sockets.



In section 3.2, it says:

"3.2 Poor IPv6 Network Performance

    Most applications on dual stack nodes will try IPv6 destinations
    first by default due to the Default Address Selection mechanism
    described in [ADDRSEL].  If the IPv6 connectivity to those
    destinations is poor while the IPv4 connectivity is better (i.e., the
    IPv6 traffic experiences higher latency, lower throughput, or more
    lost packets than IPv4 traffic), applications will still communicate
    over IPv6 at the expense of network performance.  There is no
    information available to applications in this case to advise them to
    try another destination address."

IMHO, this has to do with the design decisions of IPv6 (and IPv4). There's 
no knowledge about "nodes". So you cannot infer, from two IP addresses, if 
they correspond to the same node, or to two different nodes.

If there was a concept of "node", then this stuff would be handled by the 
network layer, in a transparent way.

So, strictly speaking, I don't think you need to address this issue. It has 
to do with the architecture itself, not with dual stacks or whatever.

There's a good theoretical discussion of this in RFC 1498. I think it 
provides very useful insights on all of the above stuff.

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





From owner-v6ops@ops.ietf.org  Mon Apr  5 22:22:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06519
	for <v6ops-archive@lists.ietf.org>; Mon, 5 Apr 2004 22:22:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAgBe-000ORN-4y
	for v6ops-data@psg.com; Tue, 06 Apr 2004 02:19:38 +0000
Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAgBb-000ONV-OY
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 02:19:36 +0000
Received: from fernando.gont.com.ar ([200.68.210.165])
	by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id XAA22739;
	Mon, 5 Apr 2004 23:45:50 -0400
Message-Id: <4.3.2.7.2.20040405201058.02a45d80@mail.daleclick.com>
X-Sender: fgont@mail.daleclick.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 05 Apr 2004 23:04:08 -0300
To: Pekka Savola <pekkas@netcore.fi>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when   
  connecting
Cc: tcpm@ietf.org, <v6ops@ops.ietf.org>, <sebastien.roy@sun.com>
In-Reply-To: <Pine.LNX.4.44.0404050922040.18946-100000@netcore.fi>
References: <4.3.2.7.2.20040403152932.00b26ae0@mail.daleclick.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

At 09:25 05/04/2004 +0300, Pekka Savola wrote:

> > >  2) state the desire for getting a better higher-level API which would
> > >handle all of this and much more (instead of/in addition to 1), but
> > >mention why this is not an only practical solution.
> > What do you mean "this is not an only practical solution"?
>What I should have said if "but mention why this is would not be a
>practical solution, if there were no other solutions".

Actually, I think it is the only real solution to the problem.
Having the API report ICMP errors to the application is moving the problem 
from the API to the application, but *not* solving it.

If you leave connect() as is, then you may have the delay problem you 
describe (i.e., you may suffer undesirable delays to use a service).
If you make it report ICMP errors to the application, you still have a 
problem I mentioned in the other e-mails. You might even say that you'll 
have application programmers (probably *not* knowledgeable on TCP/IP 
internals) handling issues of the underlying protocols.

So a real solution is to hide all this stuff from the application 
programmer. Let him just concentrate on actually using a service, and 
handle all the protocol-related issues inside the API.

Furthermore, if for whatever reason you need to change the behavior of 
connect() in the future, then, unless you provide a more "abstract" 
connect(), you'll have to "bother" application programmers again.



>That is, new APIs would be great, but we cannot stop fixing problems
>current APIs until we have something more concrete out there.
>Otherwise we'd end up with no practically (in short term) deployable
>solution.

If you consider it useful, I could try to continue thinking on the 
"abstract" API. I'm just thinking about writting some stuff down, so that 
there's a place from which which can move things forward. It may take me 
some time (say, months), but...

(BTW, for those interested tcpm-only readers, I've just posted a message 
with subject "Some comments on draft-ietf-v6ops-v6onbydefault-01.txt" on 
the v6ops list, that's related to all this. I can forward it to to the tcpm 
list, if you want).


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





From owner-v6ops@ops.ietf.org  Mon Apr  5 22:23:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06538
	for <v6ops-archive@lists.ietf.org>; Mon, 5 Apr 2004 22:23:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAgCn-000OeT-6b
	for v6ops-data@psg.com; Tue, 06 Apr 2004 02:20:49 +0000
Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAgCk-000OeF-VW
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 02:20:47 +0000
Received: from fernando.gont.com.ar ([200.68.210.165])
	by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id XAA22743;
	Mon, 5 Apr 2004 23:46:00 -0400
Message-Id: <4.3.2.7.2.20040405201120.00b18e70@mail.daleclick.com>
X-Sender: fgont@mail.daleclick.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 05 Apr 2004 23:12:23 -0300
To: Kacheong Poon <kacheong.poon@sun.com>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when 
  connecting
Cc: Pekka Savola <pekkas@netcore.fi>, tcpm@ietf.org, v6ops@ops.ietf.org,
        sebastien.roy@sun.com
In-Reply-To: <4071B897.5070905@sun.com>
References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com>
 <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

At 12:50 05/04/2004 -0700, Kacheong Poon wrote:

>>So why not implement such a "higher-level" connect(), and handle all the 
>>relevant issues inside the API?
>FYI, SCTP has this same problem.  So sctp_connectx() was added in the
>API draft to allow an app to pass in an array of addresses.

Is there any reason for which an array of IP addresses is passed, instead 
of, say, a domain name?


>How does
>the stack handle this is implementation dependent.  One way may be to
>have a policy on the priority of addresses to try and when to switch
>to another one.  If connectx() is implemented as a general call for
>other protocols, a policy for TCP may be that TCP will try another
>address if it gets an ICMPv6 message following the suggestion in
>draft-ietf-v6ops-v6onbydefault-01.txt,

IMHO, it's a better approach than just having connect() fail when ICMP 
errors are received.

However, unless there's a reason for it (as I asked above), I think it's 
still a low-level API.
For example, if I want to get the document at 
http://www.example.com/index.html , why should I care about whether the 
webeserver is IPv4-only, IPv6-only or dual/stack?
Does an application programmer really need to know the IP addresses the 
domain "www.example.com" map to?
Actually, should an application programmer be supposed to be knowledgeable 
on network addressing?

Best Regards,


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





From owner-v6ops@ops.ietf.org  Tue Apr  6 01:38:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23149
	for <v6ops-archive@lists.ietf.org>; Tue, 6 Apr 2004 01:38:26 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAjEc-000HSe-Nt
	for v6ops-data@psg.com; Tue, 06 Apr 2004 05:34:54 +0000
Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAa81-0002UC-Tx
	for v6ops@ops.ietf.org; Mon, 05 Apr 2004 19:51:29 +0000
Received: from jurassic.eng.sun.com ([129.146.83.36])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i35JonLT027170;
	Mon, 5 Apr 2004 12:50:49 -0700 (PDT)
Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49])
	by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i35Jolub913796;
	Mon, 5 Apr 2004 12:50:49 -0700 (PDT)
Message-ID: <4071B897.5070905@sun.com>
Date: Mon, 05 Apr 2004 12:50:47 -0700
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117
X-Accept-Language: en, zh-hk, zh-tw, zh-cn
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
CC: Pekka Savola <pekkas@netcore.fi>, tcpm@ietf.org, v6ops@ops.ietf.org,
        sebastien.roy@sun.com
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when  connecting
References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com>
In-Reply-To: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fernando Gont wrote:

> So why not implement such a "higher-level" connect(), and handle all the 
> relevant issues inside the API?

FYI, SCTP has this same problem.  So sctp_connectx() was added in the
API draft to allow an app to pass in an array of addresses.  How does
the stack handle this is implementation dependent.  One way may be to
have a policy on the priority of addresses to try and when to switch
to another one.  If connectx() is implemented as a general call for
other protocols, a policy for TCP may be that TCP will try another
address if it gets an ICMPv6 message following the suggestion in
draft-ietf-v6ops-v6onbydefault-01.txt,

Check section 8.9 in draft-ietf-tsvwg-sctpsocket-08.txt on
sctp_connectx().


-- 

						K. Poon.
						kacheong.poon@sun.com





From owner-v6ops@ops.ietf.org  Tue Apr  6 04:45:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21449
	for <v6ops-archive@lists.ietf.org>; Tue, 6 Apr 2004 04:45:24 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAmAE-0009na-IM
	for v6ops-data@psg.com; Tue, 06 Apr 2004 08:42:34 +0000
Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAmAB-0009nF-RD
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 08:42:31 +0000
Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1BAmAA-0003Xu-00; Tue, 06 Apr 2004 09:42:30 +0100
Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1BAmAA-0003Xp-00; Tue, 06 Apr 2004 09:42:30 +0100
Received: from zurich.ibm.com (sig-9-145-227-182.de.ibm.com [9.145.227.182])
	by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i368gTF126506;
	Tue, 6 Apr 2004 09:42:30 +0100
Message-ID: <40726D87.AE521541@zurich.ibm.com>
Date: Tue, 06 Apr 2004 10:42:47 +0200
From: Brian E Carpenter <brc@zurich.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 Templin <ftemplin@iprg.nokia.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter  
 natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-09  
 .txt] ]
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com> <406C223B.6AB75BC5@zurich.ibm.com> <406CAD48.1070301@iprg.nokia.com>
Content-Type: multipart/mixed;
 boundary="------------98A5254CAD83EEECEA51E2F6"
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------98A5254CAD83EEECEA51E2F6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Fred,

Thanks. I've PDF'ed the picture in case anyone here is PPT-challenged.

Fred Templin wrote:
> 
> Brian E Carpenter wrote:
> 
> > Can somebody draw me a picture? [Emphasis on the word "useful."]
> >
> >
> Brian,
> 
> Attached, please find a rough-cut and incomplete picture. It depicts
> two administrative domains (A and B), each with a node that is
> engaged in a peer-to-peer session (a.com and b.com). Domain A
> uses a native IPv6 prefix space and has delegated a portion of the
> space to a (b)router upstream from the node "a.com". Domain B
> uses a 6to4 prefix space and has delegated portions of the space
> to a hierarchically nested pair of (b)routers upstream from node
> "b.com".
> 
> If the DNS entries for 'a.com' and 'b.com' are populated with AAAA
> resource records as shown in the picture, one could view the presence
> of the ISATAP-format link local addresses 

Well, I wouldn't expect those AAAA records to be visible outside the
originating sites. They would typically be suppressed by a 2-faced DNS
setup.

I don't think the link local address you have for b.com is correct,
anyway. Inside site B, link locals are formed using Ethernet addresses
or whatever. The hosts inside a 6to4 site have no knowledge of 6to4.

> as an unambiguous
> indication that the nodes "support the protocol", 

I regard it as highly unlikely that site B would contain logic to
identify fe80::0200:5efe:0506:0708 as a foreign ISATAP-like address.
Site B is running 6to4; why would it have any ISATAP-related code active?

> and could use
> the ISATAP link-local address as the IPv6 next-hop toward
> the final destination.
> 
> The picture shows a stream of packets emanating from a.com towards
> b.com (and, similarly, for packets emanating from b.com towards
> a.com). These outbound packets would be encapsulated using ISATAP
> and it would appear from IPv6's perspective that they are being
> "bridged" up to the edge of the remote peer's domain (although there
> would still need to be some flavor of NDproxy in operation). Once the
> inbound packets hit the edge of the remote peer's domain, the packets
> would be decapsulated and steered towards the final destination
> within the domain via the delegated IPv6 prefix information.
> 
> The question comes when we consider the inbound packets
> arriving at the edge of administrative domain B. Does the edge
> node use 6to4 or ISATAP to decapsulate the packets. (And, does
> it even matter?)

Well, as noted, I don't see any reason that site B would have an ISATAP
interface active. It won't know that 3ffe:1::1 is anything unusual.
Similarly, site A won't have any 6to4 code active. It won't know that
2002:0506:0708::1 is anything unusual. They will both send as if these are
native addresses, and receive in their normal way (native at site A and
6to4 decapsulation at site B).

At least that's what I think.

   Brian
--------------98A5254CAD83EEECEA51E2F6
Content-Type: application/pdf;
 name="6to4tap.pdf"
Content-Disposition: inline;
 filename="6to4tap.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjMNJeLjz9MNCjYgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDggDS9IIFsg
MTA0MTUgODI2IF0gDS9MIDEzODI5NiANL0UgMTM2NTM3IA0vTiAxIA0vVCAxMzgwNTkgDT4+
IA1lbmRvYmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB4cmVmDTYgNDk5IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMTAzMjYg
MDAwMDAgbg0KMDAwMDAxMTI0MSAwMDAwMCBuDQowMDAwMDExNDU2IDAwMDAwIG4NCjAwMDAw
MTY1NTkgMDAwMDAgbg0KMDAwMDAxNjYwOCAwMDAwMCBuDQowMDAwMDE2NjU4IDAwMDAwIG4N
CjAwMDAwMTY3MDggMDAwMDAgbg0KMDAwMDAxNjc1OCAwMDAwMCBuDQowMDAwMDE2ODA4IDAw
MDAwIG4NCjAwMDAwMTY4NTggMDAwMDAgbg0KMDAwMDAxNjkwOCAwMDAwMCBuDQowMDAwMDE2
OTU4IDAwMDAwIG4NCjAwMDAwMTcwMDcgMDAwMDAgbg0KMDAwMDAxNzA1NyAwMDAwMCBuDQow
MDAwMDE3MTA3IDAwMDAwIG4NCjAwMDAwMTcxNTcgMDAwMDAgbg0KMDAwMDAxNzIwNyAwMDAw
MCBuDQowMDAwMDE3MjU3IDAwMDAwIG4NCjAwMDAwMTczMDcgMDAwMDAgbg0KMDAwMDAxNzM1
NyAwMDAwMCBuDQowMDAwMDE3NDA2IDAwMDAwIG4NCjAwMDAwMTc0NTYgMDAwMDAgbg0KMDAw
MDAxNzUwNiAwMDAwMCBuDQowMDAwMDE3NTU2IDAwMDAwIG4NCjAwMDAwMTc2MDYgMDAwMDAg
bg0KMDAwMDAxNzY1NiAwMDAwMCBuDQowMDAwMDE3NzA2IDAwMDAwIG4NCjAwMDAwMTc3NTUg
MDAwMDAgbg0KMDAwMDAxNzgwNSAwMDAwMCBuDQowMDAwMDE3ODU1IDAwMDAwIG4NCjAwMDAw
MTc5MDQgMDAwMDAgbg0KMDAwMDAxNzk1NCAwMDAwMCBuDQowMDAwMDE4MDA0IDAwMDAwIG4N
CjAwMDAwMTgwNTQgMDAwMDAgbg0KMDAwMDAxODEwNCAwMDAwMCBuDQowMDAwMDE4MTU0IDAw
MDAwIG4NCjAwMDAwMTgyMDQgMDAwMDAgbg0KMDAwMDAxODI1NCAwMDAwMCBuDQowMDAwMDE4
MzA0IDAwMDAwIG4NCjAwMDAwMTgzNTQgMDAwMDAgbg0KMDAwMDAxODQwNCAwMDAwMCBuDQow
MDAwMDE4NDU0IDAwMDAwIG4NCjAwMDAwMTg1MDQgMDAwMDAgbg0KMDAwMDAxODU1NCAwMDAw
MCBuDQowMDAwMDE4NjA0IDAwMDAwIG4NCjAwMDAwMTg2NTQgMDAwMDAgbg0KMDAwMDAxODcw
NCAwMDAwMCBuDQowMDAwMDE4NzU0IDAwMDAwIG4NCjAwMDAwMTg4MDQgMDAwMDAgbg0KMDAw
MDAxODg1NCAwMDAwMCBuDQowMDAwMDE4OTA0IDAwMDAwIG4NCjAwMDAwMTg5NTQgMDAwMDAg
bg0KMDAwMDAxOTAwNCAwMDAwMCBuDQowMDAwMDE5MDU0IDAwMDAwIG4NCjAwMDAwMTkxMDQg
MDAwMDAgbg0KMDAwMDAxOTE1NCAwMDAwMCBuDQowMDAwMDE5MjA0IDAwMDAwIG4NCjAwMDAw
MTkyNTQgMDAwMDAgbg0KMDAwMDAxOTMwNCAwMDAwMCBuDQowMDAwMDE5MzU0IDAwMDAwIG4N
CjAwMDAwMTk0MDQgMDAwMDAgbg0KMDAwMDAxOTQ1NCAwMDAwMCBuDQowMDAwMDE5NTA0IDAw
MDAwIG4NCjAwMDAwMTk1NTQgMDAwMDAgbg0KMDAwMDAxOTYwNCAwMDAwMCBuDQowMDAwMDE5
NjU0IDAwMDAwIG4NCjAwMDAwMTk3MDQgMDAwMDAgbg0KMDAwMDAxOTc1NCAwMDAwMCBuDQow
MDAwMDE5ODA0IDAwMDAwIG4NCjAwMDAwMTk4NTQgMDAwMDAgbg0KMDAwMDAxOTkwNCAwMDAw
MCBuDQowMDAwMDE5OTU0IDAwMDAwIG4NCjAwMDAwMjAwMDQgMDAwMDAgbg0KMDAwMDAyMDA1
NCAwMDAwMCBuDQowMDAwMDIwMTA0IDAwMDAwIG4NCjAwMDAwMjAxNTQgMDAwMDAgbg0KMDAw
MDAyMDIwNCAwMDAwMCBuDQowMDAwMDIwMjU0IDAwMDAwIG4NCjAwMDAwMjAzMDMgMDAwMDAg
bg0KMDAwMDAyMDM1MyAwMDAwMCBuDQowMDAwMDIwNDAzIDAwMDAwIG4NCjAwMDAwMjA0NTMg
MDAwMDAgbg0KMDAwMDAyMDUwMyAwMDAwMCBuDQowMDAwMDIwNTUyIDAwMDAwIG4NCjAwMDAw
MjA2MDIgMDAwMDAgbg0KMDAwMDAyMDY1MiAwMDAwMCBuDQowMDAwMDIwNzAyIDAwMDAwIG4N
CjAwMDAwMjA3NTIgMDAwMDAgbg0KMDAwMDAyMDgwMiAwMDAwMCBuDQowMDAwMDIwODUyIDAw
MDAwIG4NCjAwMDAwMjA5MDIgMDAwMDAgbg0KMDAwMDAyMDk1MiAwMDAwMCBuDQowMDAwMDIx
MDAyIDAwMDAwIG4NCjAwMDAwMjEwNTIgMDAwMDAgbg0KMDAwMDAyMTEwMyAwMDAwMCBuDQow
MDAwMDIxMTU0IDAwMDAwIG4NCjAwMDAwMjEyMDUgMDAwMDAgbg0KMDAwMDAyMTI1NiAwMDAw
MCBuDQowMDAwMDIxNjg4IDAwMDAwIG4NCjAwMDAwMjE3MzkgMDAwMDAgbg0KMDAwMDAyMTc5
MCAwMDAwMCBuDQowMDAwMDIxODQxIDAwMDAwIG4NCjAwMDAwMjIwNDkgMDAwMDAgbg0KMDAw
MDAyMjEwMCAwMDAwMCBuDQowMDAwMDIyMTUxIDAwMDAwIG4NCjAwMDAwMjIyMDIgMDAwMDAg
bg0KMDAwMDAyMjI1MiAwMDAwMCBuDQowMDAwMDIyMzAyIDAwMDAwIG4NCjAwMDAwMjIzNTMg
MDAwMDAgbg0KMDAwMDAyMjM5NCAwMDAwMCBuDQowMDAwMDIyNDQ1IDAwMDAwIG4NCjAwMDAw
MjI0OTYgMDAwMDAgbg0KMDAwMDAyMjU0NyAwMDAwMCBuDQowMDAwMDIyNTk4IDAwMDAwIG4N
CjAwMDAwMjI2NDkgMDAwMDAgbg0KMDAwMDAyMjcwMCAwMDAwMCBuDQowMDAwMDIyNzUxIDAw
MDAwIG4NCjAwMDAwMjI4MDIgMDAwMDAgbg0KMDAwMDAyMjg1MyAwMDAwMCBuDQowMDAwMDIy
OTA0IDAwMDAwIG4NCjAwMDAwMjI5NTUgMDAwMDAgbg0KMDAwMDAyMzAwNiAwMDAwMCBuDQow
MDAwMDIzMDU3IDAwMDAwIG4NCjAwMDAwMjMxMDcgMDAwMDAgbg0KMDAwMDAyMzE1OCAwMDAw
MCBuDQowMDAwMDIzMjA5IDAwMDAwIG4NCjAwMDAwMjMyNjAgMDAwMDAgbg0KMDAwMDAyMzMx
MSAwMDAwMCBuDQowMDAwMDIzMzYyIDAwMDAwIG4NCjAwMDAwMjM0MTMgMDAwMDAgbg0KMDAw
MDAyMzQ2NCAwMDAwMCBuDQowMDAwMDIzNTE1IDAwMDAwIG4NCjAwMDAwMjM1MzggMDAwMDAg
bg0KMDAwMDAyNTUwMyAwMDAwMCBuDQowMDAwMDI1NTI2IDAwMDAwIG4NCjAwMDAwMjc1MTkg
MDAwMDAgbg0KMDAwMDAyNzU0MiAwMDAwMCBuDQowMDAwMDI5NDA0IDAwMDAwIG4NCjAwMDAw
Mjk0MjcgMDAwMDAgbg0KMDAwMDAzMTE1OCAwMDAwMCBuDQowMDAwMDMxMTgxIDAwMDAwIG4N
CjAwMDAwMzI5MTcgMDAwMDAgbg0KMDAwMDAzMjk0MCAwMDAwMCBuDQowMDAwMDM0NTc0IDAw
MDAwIG4NCjAwMDAwMzQ5MDYgMDAwMDAgbg0KMDAwMDAzNTEyMCAwMDAwMCBuDQowMDAwMDM1
MTQzIDAwMDAwIG4NCjAwMDAwMzY1NjEgMDAwMDAgbg0KMDAwMDAzNjU4NCAwMDAwMCBuDQow
MDAwMDM4NjI4IDAwMDAwIG4NCjAwMDAwMzg3NDIgMDAwMDAgbg0KMDAwMDAzODg3NCAwMDAw
MCBuDQowMDAwMDM4OTg1IDAwMDAwIG4NCjAwMDAwMzkwNjAgMDAwMDAgbg0KMDAwMDAzOTE2
OCAwMDAwMCBuDQowMDAwMDU2NzI0IDAwMDAwIG4NCjAwMDAwNTY5MzEgMDAwMDAgbg0KMDAw
MDA1NzAzMyAwMDAwMCBuDQowMDAwMDU3MTUzIDAwMDAwIG4NCjAwMDAwNTcyODIgMDAwMDAg
bg0KMDAwMDA1NzQwMiAwMDAwMCBuDQowMDAwMDYwMDgwIDAwMDAwIG4NCjAwMDAwNjAyNzIg
MDAwMDAgbg0KMDAwMDA2MDM3NCAwMDAwMCBuDQowMDAwMDcwMjM4IDAwMDAwIG4NCjAwMDAw
NzAzNTggMDAwMDAgbg0KMDAwMDA3MDQ2NiAwMDAwMCBuDQowMDAwMDcwNTc3IDAwMDAwIG4N
CjAwMDAwNzA2NzMgMDAwMDAgbg0KMDAwMDA3MDc4NCAwMDAwMCBuDQowMDAwMDcwOTAxIDAw
MDAwIG4NCjAwMDAwNzEwMjEgMDAwMDAgbg0KMDAwMDA3MTEyOSAwMDAwMCBuDQowMDAwMDcx
MjU4IDAwMDAwIG4NCjAwMDAwNzEzMzYgMDAwMDAgbg0KMDAwMDA3MTQ1NiAwMDAwMCBuDQow
MDAwMDcxNTY3IDAwMDAwIG4NCjAwMDAwNzE2NDggMDAwMDAgbg0KMDAwMDA3MTczMiAwMDAw
MCBuDQowMDAwMDcxODI1IDAwMDAwIG4NCjAwMDAwNzE5NDUgMDAwMDAgbg0KMDAwMDA3MjAx
NCAwMDAwMCBuDQowMDAwMDcyMTMxIDAwMDAwIG4NCjAwMDAwNzIyMDAgMDAwMDAgbg0KMDAw
MDA3MjMyNiAwMDAwMCBuDQowMDAwMDcyNDQzIDAwMDAwIG4NCjAwMDAwNzI1NzUgMDAwMDAg
bg0KMDAwMDA3MjY4MCAwMDAwMCBuDQowMDAwMDcyNzg1IDAwMDAwIG4NCjAwMDAwNzI4OTAg
MDAwMDAgbg0KMDAwMDA3MzAyMiAwMDAwMCBuDQowMDAwMDczMTAzIDAwMDAwIG4NCjAwMDAw
NzMzODUgMDAwMDAgbg0KMDAwMDA3MzQ5MyAwMDAwMCBuDQowMDAwMDczNjEwIDAwMDAwIG4N
CjAwMDAwNzM3MzAgMDAwMDAgbg0KMDAwMDA3MzgzOCAwMDAwMCBuDQowMDAwMDczOTY0IDAw
MDAwIG4NCjAwMDAwNzQxNjIgMDAwMDAgbg0KMDAwMDA3NDM0MiAwMDAwMCBuDQowMDAwMDc0
NDU5IDAwMDAwIG4NCjAwMDAwNzQ2MzIgMDAwMDAgbg0KMDAwMDA3NDc1NSAwMDAwMCBuDQow
MDAwMDc0ODM2IDAwMDAwIG4NCjAwMDAwNzQ5MjkgMDAwMDAgbg0KMDAwMDA3NTAyOCAwMDAw
MCBuDQowMDAwMDc1MTMzIDAwMDAwIG4NCjAwMDAwNzUyMDggMDAwMDAgbg0KMDAwMDA3NTMy
MiAwMDAwMCBuDQowMDAwMDc1NDk1IDAwMDAwIG4NCjAwMDAwNzU2MTIgMDAwMDAgbg0KMDAw
MDA3NTY5NiAwMDAwMCBuDQowMDAwMDc1ODA0IDAwMDAwIG4NCjAwMDAwNzU5ODEgMDAwMDAg
bg0KMDAwMDA3NjI2NiAwMDAwMCBuDQowMDAwMDc2NTAzIDAwMDAwIG4NCjAwMDAwNzY3NDAg
MDAwMDAgbg0KMDAwMDA3NzAyNSAwMDAwMCBuDQowMDAwMDc3MjYyIDAwMDAwIG4NCjAwMDAw
Nzc0OTYgMDAwMDAgbg0KMDAwMDA3Nzc3NSAwMDAwMCBuDQowMDAwMDc4MDU3IDAwMDAwIG4N
CjAwMDAwNzgzMzkgMDAwMDAgbg0KMDAwMDA3ODU3MyAwMDAwMCBuDQowMDAwMDc4ODU4IDAw
MDAwIG4NCjAwMDAwNzg5NzggMDAwMDAgbg0KMDAwMDA3OTEwNyAwMDAwMCBuDQowMDAwMDc5
MjkzIDAwMDAwIG4NCjAwMDAwNzk0MTkgMDAwMDAgbg0KMDAwMDA3OTYwNSAwMDAwMCBuDQow
MDAwMDc5ODQ1IDAwMDAwIG4NCjAwMDAwODAwNjcgMDAwMDAgbg0KMDAwMDA4MDI1OSAwMDAw
MCBuDQowMDAwMDgwNDI5IDAwMDAwIG4NCjAwMDAwODA2MzMgMDAwMDAgbg0KMDAwMDA4MDc1
NiAwMDAwMCBuDQowMDAwMDgxMDQxIDAwMDAwIG4NCjAwMDAwODEyNzggMDAwMDAgbg0KMDAw
MDA4MTUxNSAwMDAwMCBuDQowMDAwMDgxODAwIDAwMDAwIG4NCjAwMDAwODIwMzcgMDAwMDAg
bg0KMDAwMDA4MjI3MSAwMDAwMCBuDQowMDAwMDgyNTUzIDAwMDAwIG4NCjAwMDAwODI4Mzgg
MDAwMDAgbg0KMDAwMDA4MzA3MiAwMDAwMCBuDQowMDAwMDgzMzM2IDAwMDAwIG4NCjAwMDAw
ODM0NTMgMDAwMDAgbg0KMDAwMDA4MzYzMCAwMDAwMCBuDQowMDAwMDgzODIyIDAwMDAwIG4N
CjAwMDAwODM5NDggMDAwMDAgbg0KMDAwMDA4NDEyMSAwMDAwMCBuDQowMDAwMDg0MzQwIDAw
MDAwIG4NCjAwMDAwODQ1NDcgMDAwMDAgbg0KMDAwMDA4NDcyNCAwMDAwMCBuDQowMDAwMDg0
ODUwIDAwMDAwIG4NCjAwMDAwODUwNDIgMDAwMDAgbg0KMDAwMDA4NTIyNSAwMDAwMCBuDQow
MDAwMDg1NDE3IDAwMDAwIG4NCjAwMDAwODU2NDUgMDAwMDAgbg0KMDAwMDA4NTg4OCAwMDAw
MCBuDQowMDAwMDg2MDg5IDAwMDAwIG4NCjAwMDAwODYzMDggMDAwMDAgbg0KMDAwMDA4NjQy
OCAwMDAwMCBuDQowMDAwMDg2NTYwIDAwMDAwIG4NCjAwMDAwODY3NDMgMDAwMDAgbg0KMDAw
MDA4NjkyNiAwMDAwMCBuDQowMDAwMDg3MTI3IDAwMDAwIG4NCjAwMDAwODczMzcgMDAwMDAg
bg0KMDAwMDA4NzYxMCAwMDAwMCBuDQowMDAwMDg3ODM4IDAwMDAwIG4NCjAwMDAwODgwNjkg
MDAwMDAgbg0KMDAwMDA4ODM0NSAwMDAwMCBuDQowMDAwMDg4NTcwIDAwMDAwIG4NCjAwMDAw
ODg3ODMgMDAwMDAgbg0KMDAwMDA4OTAzOCAwMDAwMCBuDQowMDAwMDg5Mjk5IDAwMDAwIG4N
CjAwMDAwODk1NjYgMDAwMDAgbg0KMDAwMDA4OTc4NSAwMDAwMCBuDQowMDAwMDg5OTY1IDAw
MDAwIG4NCjAwMDAwOTAxNTEgMDAwMDAgbg0KMDAwMDA5MDMzMSAwMDAwMCBuDQowMDAwMDkw
NTExIDAwMDAwIG4NCjAwMDAwOTA3NDMgMDAwMDAgbg0KMDAwMDA5MDk1NCAwMDAwMCBuDQow
MDAwMDkxMTcxIDAwMDAwIG4NCjAwMDAwOTEzNzEgMDAwMDAgbg0KMDAwMDA5MTU1OCAwMDAw
MCBuDQowMDAwMDkxNzU3IDAwMDAwIG4NCjAwMDAwOTE5NDIgMDAwMDAgbg0KMDAwMDA5MjEy
NyAwMDAwMCBuDQowMDAwMDkyMzE1IDAwMDAwIG4NCjAwMDAwOTI1MDcgMDAwMDAgbg0KMDAw
MDA5MjcwOSAwMDAwMCBuDQowMDAwMDkyOTExIDAwMDAwIG4NCjAwMDAwOTMxMjggMDAwMDAg
bg0KMDAwMDA5MzMzOSAwMDAwMCBuDQowMDAwMDkzNTUwIDAwMDAwIG4NCjAwMDAwOTM3NTgg
MDAwMDAgbg0KMDAwMDA5Mzk2NCAwMDAwMCBuDQowMDAwMDk0MTY4IDAwMDAwIG4NCjAwMDAw
OTQzNzIgMDAwMDAgbg0KMDAwMDA5NDU4MCAwMDAwMCBuDQowMDAwMDk0NzkwIDAwMDAwIG4N
CjAwMDAwOTUwMDEgMDAwMDAgbg0KMDAwMDA5NTIxNiAwMDAwMCBuDQowMDAwMDk1NDI2IDAw
MDAwIG4NCjAwMDAwOTU2MzEgMDAwMDAgbg0KMDAwMDA5NTgyOSAwMDAwMCBuDQowMDAwMDk2
MDI4IDAwMDAwIG4NCjAwMDAwOTYyMTkgMDAwMDAgbg0KMDAwMDA5NjQwOSAwMDAwMCBuDQow
MDAwMDk2NjAwIDAwMDAwIG4NCjAwMDAwOTY4MDIgMDAwMDAgbg0KMDAwMDA5NzAwNCAwMDAw
MCBuDQowMDAwMDk3MjEzIDAwMDAwIG4NCjAwMDAwOTc0MjQgMDAwMDAgbg0KMDAwMDA5NzYz
OCAwMDAwMCBuDQowMDAwMDk3ODQ3IDAwMDAwIG4NCjAwMDAwOTgwNTUgMDAwMDAgbg0KMDAw
MDA5ODI2MyAwMDAwMCBuDQowMDAwMDk4NDcyIDAwMDAwIG4NCjAwMDAwOTg2ODIgMDAwMDAg
bg0KMDAwMDA5ODg5NSAwMDAwMCBuDQowMDAwMDk5MTA4IDAwMDAwIG4NCjAwMDAwOTkzMzEg
MDAwMDAgbg0KMDAwMDA5OTU1NiAwMDAwMCBuDQowMDAwMDk5NzY5IDAwMDAwIG4NCjAwMDAw
OTk5ODYgMDAwMDAgbg0KMDAwMDEwMDE5MSAwMDAwMCBuDQowMDAwMTAwNDAwIDAwMDAwIG4N
CjAwMDAxMDA2MDAgMDAwMDAgbg0KMDAwMDEwMDgwNyAwMDAwMCBuDQowMDAwMTAxMDEwIDAw
MDAwIG4NCjAwMDAxMDEyMjMgMDAwMDAgbg0KMDAwMDEwMTQzMSAwMDAwMCBuDQowMDAwMTAx
NjUzIDAwMDAwIG4NCjAwMDAxMDE4NzEgMDAwMDAgbg0KMDAwMDEwMjEwOCAwMDAwMCBuDQow
MDAwMTAyMzM0IDAwMDAwIG4NCjAwMDAxMDI1NzYgMDAwMDAgbg0KMDAwMDEwMjgwMiAwMDAw
MCBuDQowMDAwMTAzMDQ0IDAwMDAwIG4NCjAwMDAxMDMyNzAgMDAwMDAgbg0KMDAwMDEwMzUx
MiAwMDAwMCBuDQowMDAwMTAzNzM3IDAwMDAwIG4NCjAwMDAxMDM5NzggMDAwMDAgbg0KMDAw
MDEwNDIwMyAwMDAwMCBuDQowMDAwMTA0NDQ0IDAwMDAwIG4NCjAwMDAxMDQ2NjggMDAwMDAg
bg0KMDAwMDEwNDkwNyAwMDAwMCBuDQowMDAwMTA1MTMwIDAwMDAwIG4NCjAwMDAxMDUzNjgg
MDAwMDAgbg0KMDAwMDEwNTU5MCAwMDAwMCBuDQowMDAwMTA1ODI2IDAwMDAwIG4NCjAwMDAx
MDYwNDYgMDAwMDAgbg0KMDAwMDEwNjI4MCAwMDAwMCBuDQowMDAwMTA2NDk5IDAwMDAwIG4N
CjAwMDAxMDY3MzEgMDAwMDAgbg0KMDAwMDEwNjk0OCAwMDAwMCBuDQowMDAwMTA3MTc2IDAw
MDAwIG4NCjAwMDAxMDczOTAgMDAwMDAgbg0KMDAwMDEwNzYxNCAwMDAwMCBuDQowMDAwMTA3
ODI1IDAwMDAwIG4NCjAwMDAxMDgwNDUgMDAwMDAgbg0KMDAwMDEwODI1MyAwMDAwMCBuDQow
MDAwMTA4NDY3IDAwMDAwIG4NCjAwMDAxMDg3MjkgMDAwMDAgbg0KMDAwMDEwODkzNyAwMDAw
MCBuDQowMDAwMTA5MTc4IDAwMDAwIG4NCjAwMDAxMDk0MTkgMDAwMDAgbg0KMDAwMDEwOTYz
NiAwMDAwMCBuDQowMDAwMTA5ODY4IDAwMDAwIG4NCjAwMDAxMTAwNTQgMDAwMDAgbg0KMDAw
MDExMDI2NSAwMDAwMCBuDQowMDAwMTEwNDgyIDAwMDAwIG4NCjAwMDAxMTA2ODEgMDAwMDAg
bg0KMDAwMDExMDg2OCAwMDAwMCBuDQowMDAwMTExMDUzIDAwMDAwIG4NCjAwMDAxMTEyMzgg
MDAwMDAgbg0KMDAwMDExMTQ0MCAwMDAwMCBuDQowMDAwMTExNjMyIDAwMDAwIG4NCjAwMDAx
MTE4MzQgMDAwMDAgbg0KMDAwMDExMjA1MSAwMDAwMCBuDQowMDAwMTEyMjU5IDAwMDAwIG4N
CjAwMDAxMTI0NzAgMDAwMDAgbg0KMDAwMDExMjY3NiAwMDAwMCBuDQowMDAwMTEyODg0IDAw
MDAwIG4NCjAwMDAxMTMwODggMDAwMDAgbg0KMDAwMDExMzI5OCAwMDAwMCBuDQowMDAwMTEz
NTA5IDAwMDAwIG4NCjAwMDAxMTM3MTkgMDAwMDAgbg0KMDAwMDExMzkzMSAwMDAwMCBuDQow
MDAwMTE0MTMzIDAwMDAwIG4NCjAwMDAxMTQzMzUgMDAwMDAgbg0KMDAwMDExNDUzMyAwMDAw
MCBuDQowMDAwMTE0NzI2IDAwMDAwIG4NCjAwMDAxMTQ5MTUgMDAwMDAgbg0KMDAwMDExNTEw
NyAwMDAwMCBuDQowMDAwMTE1MzA5IDAwMDAwIG4NCjAwMDAxMTU1MTggMDAwMDAgbg0KMDAw
MDExNTcyMyAwMDAwMCBuDQowMDAwMTE1OTQxIDAwMDAwIG4NCjAwMDAxMTYxNTMgMDAwMDAg
bg0KMDAwMDExNjM2NCAwMDAwMCBuDQowMDAwMTE2NTcwIDAwMDAwIG4NCjAwMDAxMTY3Nzkg
MDAwMDAgbg0KMDAwMDExNjk4NSAwMDAwMCBuDQowMDAwMTE3MTk2IDAwMDAwIG4NCjAwMDAx
MTc0MDYgMDAwMDAgbg0KMDAwMDExNzYyNCAwMDAwMCBuDQowMDAwMTE3ODQyIDAwMDAwIG4N
CjAwMDAxMTgwNjcgMDAwMDAgbg0KMDAwMDExODI5MCAwMDAwMCBuDQowMDAwMTE4NDk5IDAw
MDAwIG4NCjAwMDAxMTg3MTIgMDAwMDAgbg0KMDAwMDExODkxNSAwMDAwMCBuDQowMDAwMTE5
MTIyIDAwMDAwIG4NCjAwMDAxMTkzMjMgMDAwMDAgbg0KMDAwMDExOTUzNCAwMDAwMCBuDQow
MDAwMTE5NzQwIDAwMDAwIG4NCjAwMDAxMTk5NTcgMDAwMDAgbg0KMDAwMDEyMDE3MCAwMDAw
MCBuDQowMDAwMTIwNDAwIDAwMDAwIG4NCjAwMDAxMjA2MjQgMDAwMDAgbg0KMDAwMDEyMDg2
NyAwMDAwMCBuDQowMDAwMTIxMDk0IDAwMDAwIG4NCjAwMDAxMjEzMzcgMDAwMDAgbg0KMDAw
MDEyMTU2NCAwMDAwMCBuDQowMDAwMTIxODA3IDAwMDAwIG4NCjAwMDAxMjIwMzQgMDAwMDAg
bg0KMDAwMDEyMjI3NiAwMDAwMCBuDQowMDAwMTIyNTAyIDAwMDAwIG4NCjAwMDAxMjI3NDQg
MDAwMDAgbg0KMDAwMDEyMjk3MCAwMDAwMCBuDQowMDAwMTIzMjExIDAwMDAwIG4NCjAwMDAx
MjM0NTAgMDAwMDAgbg0KMDAwMDEyMzY3MyAwMDAwMCBuDQowMDAwMTIzOTExIDAwMDAwIG4N
CjAwMDAxMjQxMzMgMDAwMDAgbg0KMDAwMDEyNDM2OSAwMDAwMCBuDQowMDAwMTI0NTg5IDAw
MDAwIG4NCjAwMDAxMjQ4MjMgMDAwMDAgbg0KMDAwMDEyNTA0MCAwMDAwMCBuDQowMDAwMTI1
MjcyIDAwMDAwIG4NCjAwMDAxMjU1MDAgMDAwMDAgbg0KMDAwMDEyNTcxNCAwMDAwMCBuDQow
MDAwMTI1OTM4IDAwMDAwIG4NCjAwMDAxMjYxNDkgMDAwMDAgbg0KMDAwMDEyNjM2OSAwMDAw
MCBuDQowMDAwMTI2NTc3IDAwMDAwIG4NCjAwMDAxMjY3OTEgMDAwMDAgbg0KMDAwMDEyNzA1
MyAwMDAwMCBuDQowMDAwMTI3MjYxIDAwMDAwIG4NCjAwMDAxMjc1MDIgMDAwMDAgbg0KMDAw
MDEyNzY4OCAwMDAwMCBuDQowMDAwMTI3ODc0IDAwMDAwIG4NCjAwMDAxMjgwNjAgMDAwMDAg
bg0KMDAwMDEyODI3MCAwMDAwMCBuDQowMDAwMTI4NDgyIDAwMDAwIG4NCjAwMDAxMjg2ODQg
MDAwMDAgbg0KMDAwMDEyODg3NyAwMDAwMCBuDQowMDAwMTI5MDY2IDAwMDAwIG4NCjAwMDAx
MjkyNTggMDAwMDAgbg0KMDAwMDEyOTQ2MCAwMDAwMCBuDQowMDAwMTI5NjY5IDAwMDAwIG4N
CjAwMDAxMjk4NzQgMDAwMDAgbg0KMDAwMDEzMDA5MiAwMDAwMCBuDQowMDAwMTMwMzA0IDAw
MDAwIG4NCjAwMDAxMzA1MTUgMDAwMDAgbg0KMDAwMDEzMDcyMSAwMDAwMCBuDQowMDAwMTMw
OTMwIDAwMDAwIG4NCjAwMDAxMzExMzYgMDAwMDAgbg0KMDAwMDEzMTM0NyAwMDAwMCBuDQow
MDAwMTMxNTU3IDAwMDAwIG4NCjAwMDAxMzE3NzUgMDAwMDAgbg0KMDAwMDEzMTk5MyAwMDAw
MCBuDQowMDAwMTMyMjAyIDAwMDAwIG4NCjAwMDAxMzI0MjUgMDAwMDAgbg0KMDAwMDEzMjYz
OCAwMDAwMCBuDQowMDAwMTMyODQxIDAwMDAwIG4NCjAwMDAxMzMwNDggMDAwMDAgbg0KMDAw
MDEzMzI0OSAwMDAwMCBuDQowMDAwMTMzNDYwIDAwMDAwIG4NCjAwMDAxMzM2NjYgMDAwMDAg
bg0KMDAwMDEzMzg4MyAwMDAwMCBuDQowMDAwMTM0MDk2IDAwMDAwIG4NCjAwMDAxMzQzMjYg
MDAwMDAgbg0KMDAwMDEzNDU1MCAwMDAwMCBuDQowMDAwMTM0NzkzIDAwMDAwIG4NCjAwMDAx
MzUwMjAgMDAwMDAgbg0KMDAwMDEzNTI2MyAwMDAwMCBuDQowMDAwMTM1NDkwIDAwMDAwIG4N
CjAwMDAxMzU3MzMgMDAwMDAgbg0KMDAwMDEzNTk2MCAwMDAwMCBuDQowMDAwMTM2MjAyIDAw
MDAwIG4NCjAwMDAxMzY0MjggMDAwMDAgbg0KMDAwMDAxMDQxNSAwMDAwMCBuDQowMDAwMDEx
MjE5IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNTA1DS9JbmZvIDQgMCBSIA0vUm9vdCA3
IDAgUiANL1ByZXYgMTM4MDUwIA0vSURbPDhiZjdmNjI4MjNhZDRkMmJmMGU4NDFiZDA4NmRh
NGM3PjwzMWNjMjhmYmFkMDNhYzA3NTdiODgxYzgzNzQwNGU0Nz5dDT4+DXN0YXJ0eHJlZg0w
DSUlRU9GDSAgICANNyAwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAzIDAgUiAN
L01ldGFkYXRhIDUgMCBSIA0vUGFnZUxhYmVscyAyIDAgUiANPj4gDWVuZG9iag01MDMgMCBv
YmoNPDwgL1MgMzYgL0wgMTA1MSAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDUwNCAw
IFIgPj4gDXN0cmVhbQ0KSImkk09oFEkUxr9XlerE6W5tNclMMi70QdYQkkybGJEFsRY8BBGN
QUFxM2mjYjBRBvGgIvJECSJ7GHQJIgiNeIjsgkEXjWvYLfASMYcB/xDEQx8VBEfIwaMVDUhE
XMQHRfHxffB+71EF0Dug5RYAet2Hr1Xdwh3YyNtPx1YWy4i3x6jQhIwd43Me6zHyTTmEWSv1
Z3d2cfhHpV7c6AuXa7EUq2QnSkjJZMOP8qObUrjgYsMn97McWSxLwMkY9IZRWwCaJ4DhAHTJ
XOX/gIYZ4EyvG+d1G9bhz+VzytRUvbCZo4sD1Ecbuy44QSZpxGrejSk6L8adxElzNvwLTlFO
1onUNS53cREvqEeUVegnS/ks71oIlxrSNbqAMUzjlYhqTEb7aOcxTGFOjC9JQtPNw+TQX3Jr
HYIojNeZc9iHp+J3uSET5cO1ZidfpsNUrov8uNn8ysN4IpyanHNlWeCan3knH6I2GSizJPHS
Vt2Lm3RVllTZ016YtzKhA+JNbcWrNGOTPoh/qSInaxNPr0xazDa+RtdF1QncoJ7bsAPXaYu4
oa64Uc4SF3GfjoqnatwtZ+MCYjygETGlOMP1aSv28B06LqrqvZtkww7db93T4r2jvSRrIt6L
f2hQpCpx06wdYR8/pzE54uz2J5ri9eag3dQfcsjp8bkJ3WY/P6OLcqsT+kFOd+kBfkQnZL2a
dqs/pR36iA2fl5tVzjXzS++zkJvFjOqZh+zQRdyjYxZy1jUWUs9TFcW4ijLlxrjDYjykUxZy
0k0a0wL6+SGNyhZHW2bTjt9wm06Il3b8tCnt1EcxQ5MyclLP5ONOc4Qf09/2NWq/lEu79SA/
mcdwhtxqU1jAIN+nM3JKTftJfdxidvAD22hG9WbihrDN9OMujYo5lbqlrG43RbucUempisf/
33fVV3/zdxVBrCB7C3t6PggwABNOCZANZW5kc3RyZWFtDWVuZG9iag01MDQgMCBvYmoNNzEw
IA1lbmRvYmoNOCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMyAwIFIgDS9SZXNv
dXJjZXMgOSAwIFIgDS9Db250ZW50cyBbIDEzOSAwIFIgMTQxIDAgUiAxNDMgMCBSIDE0NSAw
IFIgMTQ3IDAgUiAxNDkgMCBSIDE1MyAwIFIgMTU1IDAgUiBdIA0vUm90YXRlIDkwIA0vTWVk
aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDM2IDM2IDU3NiA3NTYgXSANPj4g
DWVuZG9iag05IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQyAvSW1h
Z2VJIF0gDS9Gb250IDw8IC9UVDIgMTA0IDAgUiAvVFQ0IDE1MCAwIFIgPj4gDS9YT2JqZWN0
IDw8IC9JbTEgMjg0IDAgUiAvSW0yIDI4NSAwIFIgL0ltMyAyODYgMCBSIC9JbTQgMjg3IDAg
UiAvSW01IDI4OCAwIFIgDS9JbTYgMjg5IDAgUiAvSW03IDI5MCAwIFIgL0ltOCAyOTEgMCBS
IC9JbTkgMjkyIDAgUiAvSW0xMCAyOTMgMCBSIA0vSW0xMSAyOTQgMCBSIC9JbTEyIDI5NSAw
IFIgL0ltMTMgMjk2IDAgUiAvSW0xNCAyOTcgMCBSIC9JbTE1IDI5OCAwIFIgDS9JbTE2IDI5
OSAwIFIgL0ltMTcgMzAwIDAgUiAvSW0xOCAzMDEgMCBSIC9JbTE5IDMwMiAwIFIgL0ltMjAg
MzAzIDAgUiANL0ltMjEgMzA0IDAgUiAvSW0yMiAzMDUgMCBSIC9JbTIzIDMwNiAwIFIgL0lt
MjQgMzA3IDAgUiAvSW0yNSAzMDggMCBSIA0vSW0yNiAzMDkgMCBSIC9JbTI3IDMxMCAwIFIg
L0ltMjggMzExIDAgUiAvSW0yOSAzMTIgMCBSIC9JbTMwIDMxMyAwIFIgDS9JbTMxIDMxNCAw
IFIgL0ltMzIgMzE1IDAgUiAvSW0zMyAzMTYgMCBSIC9JbTM0IDMxNyAwIFIgL0ltMzUgMzE4
IDAgUiANL0ltMzYgMzE5IDAgUiAvSW0zNyAzMjAgMCBSIC9JbTM4IDMyMSAwIFIgL0ltMzkg
MzIyIDAgUiAvSW00MCAzMjMgMCBSIA0vSW00MSAzMjQgMCBSIC9JbTQyIDMyNSAwIFIgL0lt
NDMgMzI2IDAgUiAvSW00NCAzMjcgMCBSIC9JbTQ1IDMyOCAwIFIgDS9JbTQ2IDMyOSAwIFIg
L0ltNDcgMzMwIDAgUiAvSW00OCAzMzEgMCBSIC9JbTQ5IDMzMiAwIFIgL0ltNTAgMzMzIDAg
UiANL0ltNTEgMzM0IDAgUiAvSW01MiAzMzUgMCBSIC9JbTUzIDMzNiAwIFIgL0ltNTQgMzM3
IDAgUiAvSW01NSAzMzggMCBSIA0vSW01NiAzMzkgMCBSIC9JbTU3IDM0MCAwIFIgL0ltNTgg
MzQxIDAgUiAvSW01OSAzNDIgMCBSIC9JbTYwIDM0MyAwIFIgDS9JbTYxIDM0NCAwIFIgL0lt
NjIgMzQ1IDAgUiAvSW02MyAzNDYgMCBSIC9JbTY0IDM0NyAwIFIgL0ltNjUgMzQ4IDAgUiAN
L0ltNjYgMzQ5IDAgUiAvSW02NyAzNTAgMCBSIC9JbTY4IDM1MSAwIFIgL0ltNjkgMzUyIDAg
UiAvSW03MCAzNTMgMCBSIA0vSW03MSAzNTQgMCBSIC9JbTcyIDM1NSAwIFIgL0ltNzMgMzU2
IDAgUiAvSW03NCAzNTcgMCBSIC9JbTc1IDM1OCAwIFIgDS9JbTc2IDM1OSAwIFIgL0ltNzcg
MzYwIDAgUiAvSW03OCAzNjEgMCBSIC9JbTc5IDM2MiAwIFIgL0ltODAgMzYzIDAgUiANL0lt
ODEgMzY0IDAgUiAvSW04MiAzNjUgMCBSIC9JbTgzIDM2NiAwIFIgL0ltODQgMzY3IDAgUiAv
SW04NSAzNjggMCBSIA0vSW04NiAzNjkgMCBSIC9JbTg3IDM3MCAwIFIgL0ltODggMzcxIDAg
UiAvSW04OSAzNzIgMCBSIC9JbTkwIDM3MyAwIFIgDS9JbTkxIDM3NCAwIFIgL0ltOTIgMzc1
IDAgUiAvSW05MyAzNzYgMCBSIC9JbTk0IDM3NyAwIFIgL0ltOTUgMzc4IDAgUiANL0ltOTYg
Mzc5IDAgUiAvSW05NyAzODAgMCBSIC9JbTk4IDM4MSAwIFIgL0ltOTkgMzgyIDAgUiAvSW0x
MDAgMzgzIDAgUiANL0ltMTAxIDM4NCAwIFIgL0ltMTAyIDM4NSAwIFIgL0ltMTAzIDM4NiAw
IFIgL0ltMTA0IDM4NyAwIFIgL0ltMTA1IDM4OCAwIFIgDS9JbTEwNiAzODkgMCBSIC9JbTEw
NyAzOTAgMCBSIC9JbTEwOCAzOTEgMCBSIC9JbTEwOSAzOTIgMCBSIC9JbTExMCAzOTMgMCBS
IA0vSW0xMTEgMzk0IDAgUiAvSW0xMTIgMzk1IDAgUiAvSW0xMTMgMzk2IDAgUiAvSW0xMTQg
Mzk3IDAgUiAvSW0xMTUgMzk4IDAgUiANL0ltMTE2IDM5OSAwIFIgL0ltMTE3IDQwMCAwIFIg
L0ltMTE4IDQwMSAwIFIgL0ltMTE5IDQwMiAwIFIgL0ltMTIwIDQwMyAwIFIgDS9JbTEyMSA0
MDQgMCBSIC9JbTEyMiA0MDUgMCBSIC9JbTEyMyA0MDYgMCBSIC9JbTEyNCA0MDcgMCBSIC9J
bTEyNSA0MDggMCBSIA0vSW0xMjYgNDA5IDAgUiAvSW0xMjcgNDEwIDAgUiAvSW0xMjggNDEx
IDAgUiAvSW0xMjkgNDEyIDAgUiAvSW0xMzAgNDEzIDAgUiANL0ltMTMxIDQxNCAwIFIgL0lt
MTMyIDQxNSAwIFIgL0ltMTMzIDQxNiAwIFIgL0ltMTM0IDQxNyAwIFIgL0ltMTM1IDQxOCAw
IFIgDS9JbTEzNiA0MTkgMCBSIC9JbTEzNyA0MjAgMCBSIC9JbTEzOCA0MjEgMCBSIC9JbTEz
OSA0MjIgMCBSIC9JbTE0MCA0MjMgMCBSIA0vSW0xNDEgNDI0IDAgUiAvSW0xNDIgNDI1IDAg
UiAvSW0xNDMgNDI2IDAgUiAvSW0xNDQgNDI3IDAgUiAvSW0xNDUgNDI4IDAgUiANL0ltMTQ2
IDQyOSAwIFIgL0ltMTQ3IDQzMCAwIFIgL0ltMTQ4IDQzMSAwIFIgL0ltMTQ5IDQzMiAwIFIg
L0ltMTUwIDQzMyAwIFIgDS9JbTE1MSA0MzQgMCBSIC9JbTE1MiA0MzUgMCBSIC9JbTE1MyA0
MzYgMCBSIC9JbTE1NCA0MzcgMCBSIC9JbTE1NSA0MzggMCBSIA0vSW0xNTYgNDM5IDAgUiAv
SW0xNTcgNDQwIDAgUiAvSW0xNTggNDQxIDAgUiAvSW0xNTkgNDQyIDAgUiAvSW0xNjAgNDQz
IDAgUiANL0ltMTYxIDQ0NCAwIFIgL0ltMTYyIDQ0NSAwIFIgL0ltMTYzIDQ0NiAwIFIgL0lt
MTY0IDQ0NyAwIFIgL0ltMTY1IDQ0OCAwIFIgDS9JbTE2NiA0NDkgMCBSIC9JbTE2NyA0NTAg
MCBSIC9JbTE2OCA0NTEgMCBSIC9JbTE2OSA0NTIgMCBSIC9JbTE3MCA0NTMgMCBSIA0vSW0x
NzEgNDU0IDAgUiAvSW0xNzIgNDU1IDAgUiAvSW0xNzMgNDU2IDAgUiAvSW0xNzQgNDU3IDAg
UiAvSW0xNzUgNDU4IDAgUiANL0ltMTc2IDQ1OSAwIFIgL0ltMTc3IDQ2MCAwIFIgL0ltMTc4
IDQ2MSAwIFIgL0ltMTc5IDQ2MiAwIFIgL0ltMTgwIDQ2MyAwIFIgDS9JbTE4MSA0NjQgMCBS
IC9JbTE4MiA0NjUgMCBSIC9JbTE4MyA0NjYgMCBSIC9JbTE4NCA0NjcgMCBSIC9JbTE4NSA0
NjggMCBSIA0vSW0xODYgNDY5IDAgUiAvSW0xODcgNDcwIDAgUiAvSW0xODggNDcxIDAgUiAv
SW0xODkgNDcyIDAgUiAvSW0xOTAgNDczIDAgUiANL0ltMTkxIDQ3NCAwIFIgL0ltMTkyIDQ3
NSAwIFIgL0ltMTkzIDQ3NiAwIFIgL0ltMTk0IDQ3NyAwIFIgL0ltMTk1IDQ3OCAwIFIgDS9J
bTE5NiA0NzkgMCBSIC9JbTE5NyA0ODAgMCBSIC9JbTE5OCA0ODEgMCBSIC9JbTE5OSA0ODIg
MCBSIC9JbTIwMCA0ODMgMCBSIA0vSW0yMDEgNDg0IDAgUiAvSW0yMDIgNDg1IDAgUiAvSW0y
MDMgNDg2IDAgUiAvSW0yMDQgNDg3IDAgUiAvSW0yMDUgNDg4IDAgUiANL0ltMjA2IDQ4OSAw
IFIgL0ltMjA3IDQ5MCAwIFIgL0ltMjA4IDQ5MSAwIFIgL0ltMjA5IDQ5MiAwIFIgL0ltMjEw
IDQ5MyAwIFIgDS9JbTIxMSA0OTQgMCBSIC9JbTIxMiA0OTUgMCBSIC9JbTIxMyA0OTYgMCBS
IC9JbTIxNCA0OTcgMCBSIC9JbTIxNSA0OTggMCBSIA0vSW0yMTYgNDk5IDAgUiAvSW0yMTcg
NTAwIDAgUiAvSW0yMTggNTAxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUwMiAwIFIg
Pj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMTE1IDAgUiAvQ3M4IDExMyAwIFIgL0NzOSAxMTIg
MCBSIC9DczEwIDg5IDAgUiAvQ3MxMSA4NCAwIFIgDS9DczEyIDkxIDAgUiAvQ3MxMyA5OSAw
IFIgL0NzMTQgOTIgMCBSIC9DczE1IDk2IDAgUiAvQ3MxNiAxMjEgMCBSIA0vQ3MxNyAxMjUg
MCBSIC9DczE4IDEyMCAwIFIgL0NzMTkgMTMxIDAgUiAvQ3MyMCAxMjMgMCBSIC9DczIxIDEz
NiAwIFIgDS9DczIyIDMyIDAgUiAvQ3MyMyAzNCAwIFIgL0NzMjQgMjkgMCBSIC9DczI1IDQy
IDAgUiAvQ3MyNiA0NCAwIFIgDS9DczI3IDM4IDAgUiAvQ3MyOCAyNyAwIFIgL0NzMjkgMTcg
MCBSIC9DczMwIDEwIDAgUiAvQ3MzMSAxOCAwIFIgDS9DczMyIDI2IDAgUiAvQ3MzMyAxOSAw
IFIgL0NzMzQgNDYgMCBSIC9DczM1IDcyIDAgUiAvQ3MzNiA2NSAwIFIgDS9DczM3IDczIDAg
UiAvQ3MzOCA4MiAwIFIgL0NzMzkgNzQgMCBSIC9DczQwIDc2IDAgUiAvQ3M0MSA1MiAwIFIg
DS9DczQyIDUwIDAgUiAvQ3M0MyA0OSAwIFIgL0NzNDQgNjEgMCBSIC9DczQ1IDU5IDAgUiAv
Q3M0NiA1OCAwIFIgDS9DczQ3IDU3IDAgUiAvQ3M0OCA1NiAwIFIgL0NzNDkgNjIgMCBSIC9D
czUwIDYzIDAgUiAvQ3M1MSA2MCAwIFIgDS9DczUyIDU1IDAgUiAvQ3M1MyA0OCAwIFIgL0Nz
NTQgNDcgMCBSIC9DczU1IDUzIDAgUiAvQ3M1NiA1NCAwIFIgDS9DczU3IDUxIDAgUiAvQ3M1
OCA2NCAwIFIgL0NzNTkgNzcgMCBSIC9DczYwIDc1IDAgUiAvQ3M2MSA3OCAwIFIgDS9DczYy
IDgxIDAgUiAvQ3M2MyA4MCAwIFIgL0NzNjQgNzkgMCBSIC9DczY1IDY3IDAgUiAvQ3M2NiA2
NiAwIFIgDS9DczY3IDY4IDAgUiAvQ3M2OCA3MSAwIFIgL0NzNjkgNzAgMCBSIC9DczcwIDY5
IDAgUiAvQ3M3MSAyMSAwIFIgDS9DczcyIDIwIDAgUiAvQ3M3MyAyMiAwIFIgL0NzNzQgMjUg
MCBSIC9Dczc1IDI0IDAgUiAvQ3M3NiAyMyAwIFIgDS9Dczc3IDEyIDAgUiAvQ3M3OCAxMSAw
IFIgL0NzNzkgMTMgMCBSIC9DczgwIDE2IDAgUiAvQ3M4MSAxNSAwIFIgDS9DczgyIDE0IDAg
UiAvQ3M4MyAzOSAwIFIgL0NzODQgNDAgMCBSIC9Dczg1IDM3IDAgUiAvQ3M4NiA0MSAwIFIg
DS9Dczg3IDQ1IDAgUiAvQ3M4OCA0MyAwIFIgL0NzODkgODMgMCBSIC9DczkwIDMwIDAgUiAv
Q3M5MSAyOCAwIFIgDS9DczkyIDMxIDAgUiAvQ3M5MyAzNSAwIFIgL0NzOTQgMzMgMCBSIC9D
czk1IDM2IDAgUiAvQ3M5NiAxMjkgMCBSIA0vQ3M5NyAxMjIgMCBSIC9Dczk4IDEyNyAwIFIg
L0NzOTkgMTM0IDAgUiAvQ3MxMDAgMTMzIDAgUiAvQ3MxMDEgMTMwIDAgUiANL0NzMTAyIDEz
NSAwIFIgL0NzMTAzIDExOSAwIFIgL0NzMTA0IDEyNCAwIFIgL0NzMTA1IDEyNiAwIFIgL0Nz
MTA2IDEyOCAwIFIgDS9DczEwNyAxMzcgMCBSIC9DczEwOCAxMzIgMCBSIC9DczEwOSA5NCAw
IFIgL0NzMTEwIDkzIDAgUiAvQ3MxMTEgOTUgMCBSIA0vQ3MxMTIgOTggMCBSIC9DczExMyA5
NyAwIFIgL0NzMTE0IDExOCAwIFIgL0NzMTE1IDg2IDAgUiAvQ3MxMTYgODUgMCBSIA0vQ3Mx
MTcgODcgMCBSIC9DczExOCA5MCAwIFIgL0NzMTE5IDg4IDAgUiAvQ3MxMjAgMTAwIDAgUiAv
Q3MxMjEgMTExIDAgUiANL0NzMTIyIDExMCAwIFIgL0NzMTIzIDExNiAwIFIgL0NzMTI0IDEx
NyAwIFIgL0NzMTI1IDExNCAwIFIgL0NzMTI2IDEwOSAwIFIgDS9DczEyNyAxMDMgMCBSIC9D
czEyOCAxMDIgMCBSIC9DczEyOSAxMDEgMCBSIC9DczEzMCAxMDcgMCBSIC9DczEzMSAxMDYg
MCBSIA0vQ3MxMzIgMTA1IDAgUiA+PiANPj4gDWVuZG9iag0xMCAwIG9iag1bIA0vSW5kZXhl
ZCAxMTUgMCBSIDggMTgzIDAgUiANXQ1lbmRvYmoNMTEgMCBvYmoNWyANL0luZGV4ZWQgMTE1
IDAgUiA1NCAyODAgMCBSIA1dDWVuZG9iag0xMiAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBS
IDQwIDI3OSAwIFIgDV0NZW5kb2JqDTEzIDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMzkg
MjczIDAgUiANXQ1lbmRvYmoNMTQgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA0NSAyNjQg
MCBSIA1dDWVuZG9iag0xNSAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDM2IDI2NiAwIFIg
DV0NZW5kb2JqDTE2IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgNTAgMjY1IDAgUiANXQ1l
bmRvYmoNMTcgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAxMyAxNzQgMCBSIA1dDWVuZG9i
ag0xOCAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDcgMTgwIDAgUiANXQ1lbmRvYmoNMTkg
MCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAxNyAxNzggMCBSIA1dDWVuZG9iag0yMCAwIG9i
ag1bIA0vSW5kZXhlZCAxMTUgMCBSIDYwIDI3NCAwIFIgDV0NZW5kb2JqDTIxIDAgb2JqDVsg
DS9JbmRleGVkIDExNSAwIFIgNDUgMjc1IDAgUiANXQ1lbmRvYmoNMjIgMCBvYmoNWyANL0lu
ZGV4ZWQgMTE1IDAgUiA0NCAyNzggMCBSIA1dDWVuZG9iag0yMyAwIG9iag1bIA0vSW5kZXhl
ZCAxMTUgMCBSIDU2IDI4MSAwIFIgDV0NZW5kb2JqDTI0IDAgb2JqDVsgDS9JbmRleGVkIDEx
NSAwIFIgNDIgMjgzIDAgUiANXQ1lbmRvYmoNMjUgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAg
UiA1OCAyODIgMCBSIA1dDWVuZG9iag0yNiAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDkg
MTg0IDAgUiANXQ1lbmRvYmoNMjcgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAxNiAxOTMg
MCBSIA1dDWVuZG9iag0yOCAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDE0IDIxMSAwIFIg
DV0NZW5kb2JqDTI5IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMjEgMTY2IDAgUiANXQ1l
bmRvYmoNMzAgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyMiAyNDEgMCBSIA1dDWVuZG9i
ag0zMSAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDE2IDIxMiAwIFIgDV0NZW5kb2JqDTMy
IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMTcgMTYwIDAgUiANXQ1lbmRvYmoNMzMgMCBv
YmoNWyANL0luZGV4ZWQgMTE1IDAgUiA4IDIwOSAwIFIgDV0NZW5kb2JqDTM0IDAgb2JqDVsg
DS9JbmRleGVkIDExNSAwIFIgMTggMTU4IDAgUiANXQ1lbmRvYmoNMzUgMCBvYmoNWyANL0lu
ZGV4ZWQgMTE1IDAgUiAxMiAyMTAgMCBSIA1dDWVuZG9iag0zNiAwIG9iag1bIA0vSW5kZXhl
ZCAxMTUgMCBSIDYgMjEzIDAgUiANXQ1lbmRvYmoNMzcgMCBvYmoNWyANL0luZGV4ZWQgMTE1
IDAgUiAzMCAyNzEgMCBSIA1dDWVuZG9iag0zOCAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBS
IDE2IDE5NSAwIFIgDV0NZW5kb2JqDTM5IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMzMg
MjYzIDAgUiANXQ1lbmRvYmoNNDAgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA0MiAyNjcg
MCBSIA1dDWVuZG9iag00MSAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDM2IDI3MiAwIFIg
DV0NZW5kb2JqDTQyIDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMjUgMTU3IDAgUiANXQ1l
bmRvYmoNNDMgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyMSAyNjggMCBSIA1dDWVuZG9i
ag00NCAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDIzIDE5MCAwIFIgDV0NZW5kb2JqDTQ1
IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMzAgMjcwIDAgUiANXQ1lbmRvYmoNNDYgMCBv
YmoNWyANL0luZGV4ZWQgMTE1IDAgUiAxOCAxNzMgMCBSIA1dDWVuZG9iag00NyAwIG9iag1b
IA0vSW5kZXhlZCAxMTUgMCBSIDMzIDI2MSAwIFIgDV0NZW5kb2JqDTQ4IDAgb2JqDVsgDS9J
bmRleGVkIDExNSAwIFIgMjMgMjYwIDAgUiANXQ1lbmRvYmoNNDkgMCBvYmoNWyANL0luZGV4
ZWQgMTE1IDAgUiAyNCAxNjUgMCBSIA1dDWVuZG9iag01MCAwIG9iag1bIA0vSW5kZXhlZCAx
MTUgMCBSIDIxIDE3MSAwIFIgDV0NZW5kb2JqDTUxIDAgb2JqDVsgDS9JbmRleGVkIDExNSAw
IFIgMzggMjU4IDAgUiANXQ1lbmRvYmoNNTIgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAx
OSAxNTYgMCBSIA1dDWVuZG9iag01MyAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDI4IDI1
OSAwIFIgDV0NZW5kb2JqDTU0IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgNDIgMjU3IDAg
UiANXQ1lbmRvYmoNNTUgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyNyAyNTYgMCBSIA1d
DWVuZG9iag01NiAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDMzIDI1NCAwIFIgDV0NZW5k
b2JqDTU3IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMzAgMjYyIDAgUiANXQ1lbmRvYmoN
NTggMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAzOCAxNjIgMCBSIA1dDWVuZG9iag01OSAw
IG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDMzIDE2OCAwIFIgDV0NZW5kb2JqDTYwIDAgb2Jq
DVsgDS9JbmRleGVkIDExNSAwIFIgMjAgMjUyIDAgUiANXQ1lbmRvYmoNNjEgMCBvYmoNWyAN
L0luZGV4ZWQgMTE1IDAgUiAyMSAxNjQgMCBSIA1dDWVuZG9iag02MiAwIG9iag1bIA0vSW5k
ZXhlZCAxMTUgMCBSIDIzIDI1NSAwIFIgDV0NZW5kb2JqDTYzIDAgb2JqDVsgDS9JbmRleGVk
IDExNSAwIFIgMjggMjUzIDAgUiANXQ1lbmRvYmoNNjQgMCBvYmoNWyANL0luZGV4ZWQgMTE1
IDAgUiA1NyAyNTEgMCBSIA1dDWVuZG9iag02NSAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBS
IDI1IDE5MiAwIFIgDV0NZW5kb2JqDTY2IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgNjMg
MjQ4IDAgUiANXQ1lbmRvYmoNNjcgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA0NyAyNTAg
MCBSIA1dDWVuZG9iag02OCAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDQ3IDI0NyAwIFIg
DV0NZW5kb2JqDTY5IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgNjEgMjc3IDAgUiANXQ1l
bmRvYmoNNzAgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA0NiAyNzYgMCBSIA1dDWVuZG9i
ag03MSAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDYzIDE5OCAwIFIgDV0NZW5kb2JqDTcy
IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMjAgMTc2IDAgUiANXQ1lbmRvYmoNNzMgMCBv
YmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyNSAxOTYgMCBSIA1dDWVuZG9iag03NCAwIG9iag1b
IA0vSW5kZXhlZCAxMTUgMCBSIDIwIDE4OCAwIFIgDV0NZW5kb2JqDTc1IDAgb2JqDVsgDS9J
bmRleGVkIDExNSAwIFIgNjQgMjQ1IDAgUiANXQ1lbmRvYmoNNzYgMCBvYmoNWyANL0luZGV4
ZWQgMTE1IDAgUiAyMSAxODYgMCBSIA1dDWVuZG9iag03NyAwIG9iag1bIA0vSW5kZXhlZCAx
MTUgMCBSIDQ4IDI0NCAwIFIgDV0NZW5kb2JqDTc4IDAgb2JqDVsgDS9JbmRleGVkIDExNSAw
IFIgNDggMjQzIDAgUiANXQ1lbmRvYmoNNzkgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA2
NCAyNDkgMCBSIA1dDWVuZG9iag04MCAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDQ4IDI0
NiAwIFIgDV0NZW5kb2JqDTgxIDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgNjQgMjQyIDAg
UiANXQ1lbmRvYmoNODIgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyMCAxOTEgMCBSIA1d
DWVuZG9iag04MyAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDI1IDI2OSAwIFIgDV0NZW5k
b2JqDTg0IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgOCAxOTcgMCBSIA1dDWVuZG9iag04
NSAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDMxIDIzNSAwIFIgDV0NZW5kb2JqDTg2IDAg
b2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMjEgMjMxIDAgUiANXQ1lbmRvYmoNODcgMCBvYmoN
WyANL0luZGV4ZWQgMTE1IDAgUiAyNiAyMzkgMCBSIA1dDWVuZG9iag04OCAwIG9iag1bIA0v
SW5kZXhlZCAxMTUgMCBSIDMzIDIzOCAwIFIgDV0NZW5kb2JqDTg5IDAgb2JqDVsgDS9JbmRl
eGVkIDExNSAwIFIgNCAxODcgMCBSIA1dDWVuZG9iag05MCAwIG9iag1bIA0vSW5kZXhlZCAx
MTUgMCBSIDM3IDI0MCAwIFIgDV0NZW5kb2JqDTkxIDAgb2JqDVsgDS9JbmRleGVkIDExNSAw
IFIgMTIgMTg1IDAgUiANXQ1lbmRvYmoNOTIgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAx
OCAxODIgMCBSIA1dDWVuZG9iag05MyAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDM1IDIw
NCAwIFIgDV0NZW5kb2JqDTk0IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMjkgMjA1IDAg
UiANXQ1lbmRvYmoNOTUgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyOCAyMTkgMCBSIA1d
DWVuZG9iag05NiAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDI0IDE3OSAwIFIgDV0NZW5k
b2JqDTk3IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgMjMgMjM0IDAgUiANXQ1lbmRvYmoN
OTggMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAzMSAyMzMgMCBSIA1dDWVuZG9iag05OSAw
IG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDE4IDE3NSAwIFIgDV0NZW5kb2JqDTEwMCAwIG9i
ag1bIA0vSW5kZXhlZCAxMTUgMCBSIDQ5IDIzNiAwIFIgDV0NZW5kb2JqDTEwMSAwIG9iag1b
IA0vSW5kZXhlZCAxMTUgMCBSIDQ3IDIyOSAwIFIgDV0NZW5kb2JqDTEwMiAwIG9iag1bIA0v
SW5kZXhlZCAxMTUgMCBSIDYzIDIyOCAwIFIgDV0NZW5kb2JqDTEwMyAwIG9iag1bIA0vSW5k
ZXhlZCAxMTUgMCBSIDQ4IDIyNCAwIFIgDV0NZW5kb2JqDTEwNCAwIG9iag08PCANL1R5cGUg
L0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDEx
OCANL1dpZHRocyBbIDI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAwIDI3OCAw
IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IA01NTYgNTU2IDU1NiAwIDI3OCAwIDAgMCAwIDAg
MCA2NjcgNjY3IDAgNzIyIDAgNjExIDc3OCAwIDI3OCAwIDAgDTAgMCA3MjIgMCA2NjcgMCAw
IDY2NyAwIDAgMCAwIDAgMCA2MTEgMCAwIDAgMCAwIDAgNTU2IDU1NiA1MDAgNTU2IA01NTYg
Mjc4IDAgMCAyMjIgMCA1MDAgMjIyIDgzMyA1NTYgNTU2IDAgMCAwIDAgMCAwIDUwMCBdIA0v
RW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9HSUFMT0MrQXJpYWwgDS9G
b250RGVzY3JpcHRvciAxMDggMCBSIA0+PiANZW5kb2JqDTEwNSAwIG9iag1bIA0vSW5kZXhl
ZCAxMTUgMCBSIDYyIDIyNiAwIFIgDV0NZW5kb2JqDTEwNiAwIG9iag1bIA0vSW5kZXhlZCAx
MTUgMCBSIDQ3IDIyNSAwIFIgDV0NZW5kb2JqDTEwNyAwIG9iag1bIA0vSW5kZXhlZCAxMTUg
MCBSIDYzIDIyNyAwIFIgDV0NZW5kb2JqDTEwOCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNj
cmlwdG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxh
Z3MgMzIgDS9Gb250QkJveCBbIC02NjUgLTMyNSAyMDAwIDEwMDYgXSANL0ZvbnROYW1lIC9H
SUFMT0MrQXJpYWwgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgOTQgDS9Gb250RmlsZTIgMTYx
IDAgUiANPj4gDWVuZG9iag0xMDkgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA2NCAyMjAg
MCBSIA1dDWVuZG9iag0xMTAgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA2NCAyMzAgMCBS
IA1dDWVuZG9iag0xMTEgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA0MyAyMzcgMCBSIA1d
DWVuZG9iag0xMTIgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA0IDE4OSAwIFIgDV0NZW5k
b2JqDTExMyAwIG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDYgMTU5IDAgUiANXQ1lbmRvYmoN
MTE0IDAgb2JqDVsgDS9JbmRleGVkIDExNSAwIFIgNDggMjIxIDAgUiANXQ1lbmRvYmoNMTE1
IDAgb2JqDVsgDS9JQ0NCYXNlZCAxNjcgMCBSIA1dDWVuZG9iag0xMTYgMCBvYmoNWyANL0lu
ZGV4ZWQgMTE1IDAgUiA0OCAyMjIgMCBSIA1dDWVuZG9iag0xMTcgMCBvYmoNWyANL0luZGV4
ZWQgMTE1IDAgUiA2NCAyMjMgMCBSIA1dDWVuZG9iag0xMTggMCBvYmoNWyANL0luZGV4ZWQg
MTE1IDAgUiAyNCAyMzIgMCBSIA1dDWVuZG9iag0xMTkgMCBvYmoNWyANL0luZGV4ZWQgMTE1
IDAgUiAxNyAyMDIgMCBSIA1dDWVuZG9iag0xMjAgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAg
UiAxNiAxOTQgMCBSIA1dDWVuZG9iag0xMjEgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAy
MSAxODEgMCBSIA1dDWVuZG9iag0xMjIgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAxNyAy
MTggMCBSIA1dDWVuZG9iag0xMjMgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAxNSAxNjMg
MCBSIA1dDWVuZG9iag0xMjQgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyMCAyMDAgMCBS
IA1dDWVuZG9iag0xMjUgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyMSAxNzcgMCBSIA1d
DWVuZG9iag0xMjYgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAxNyAxOTkgMCBSIA1dDWVu
ZG9iag0xMjcgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyMCAyMTYgMCBSIA1dDWVuZG9i
ag0xMjggMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiAyMyAyMDMgMCBSIA1dDWVuZG9iag0x
MjkgMCBvYmoNWyANL0luZGV4ZWQgMTE1IDAgUiA5IDIxNyAwIFIgDV0NZW5kb2JqDTEzMCAw
IG9iag1bIA0vSW5kZXhlZCAxMTUgMCBSIDIyIDIwOCAwIFIgDV0NZW5kb2JqDTEzMSAwIG9i
ag1bIA0vSW5kZXhlZCAxMTUgMCBSIDE3IDE3MiAwIFIgDV0NZW5kb2JqDTEzMiAwIG9iag1b
IA0vSW5kZXhlZCAxMTUgMCBSIDI3IDIwNyAwIFIgDV0NZW5kb2JqDTEzMyAwIG9iag1bIA0v
SW5kZXhlZCAxMTUgMCBSIDI3IDIxNSAwIFIgDV0NZW5kb2JqDTEzNCAwIG9iag1bIA0vSW5k
ZXhlZCAxMTUgMCBSIDE5IDIxNCAwIFIgDV0NZW5kb2JqDTEzNSAwIG9iag1bIA0vSW5kZXhl
ZCAxMTUgMCBSIDIxIDIwMSAwIFIgDV0NZW5kb2JqDTEzNiAwIG9iag1bIA0vSW5kZXhlZCAx
MTUgMCBSIDE1IDE2OSAwIFIgDV0NZW5kb2JqDTEzNyAwIG9iag1bIA0vSW5kZXhlZCAxMTUg
MCBSIDIwIDIwNiAwIFIgDV0NZW5kb2JqDTEzOCAwIG9iag0xODg1IA1lbmRvYmoNMTM5IDAg
b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTM4IDAgUiA+PiANc3RyZWFt
DQpIiexXy24dRRDdz1f0MkZi3NXv3pJARCQQku+KwIKYBGHsIMUS/D7nVFXfOw7s2Vh34Tmu
ftTzVPX1y8cWbh+D6O/x9uN2/fpGwm+PW26hjxZqieHLPmL49H77sF1z+cubEPV38/L7TcIb
bLwLstfwd5AYvgtvf47hVwh+D1vOfcchqUl4AJgh1brPFu63XOI+AGXPRWEmLH0XgwR5n/yu
aU9A4qLad5yYBw8GbGmfBbjv2EM8HBP0zE0XYe+8jlhPHmXXi+LeE/GUPRIXP3s2lde4Z90+
6z4on2ZDiXFvxM32l9j2mC77i8hekhqi1xfpjglS5ikXYZqGq3mkZHw0dUnTw/Pca1Nl7HBs
7MRVAVTA9zQflTIQjtTKngzi/4CTG86wy54ua3s+SNJeVSUEi7D5MU0Ih3ujNIQSUO/H2QWO
nRErAOH3SFhd914pzlHoL+K2N+K+cOcVWYpvN3GKrkeHQ4nbwkmPy7hFDULMKUdOmNy0IZbm
+3l88WQrfagcrrb9I1FdJN3edf+oiitCo7Dr8joYXeLJdcy8pvKpHsltWQM8gaFlHwd5ny4f
qmcezdXDdTR3poVF75v94i2oU+I6r0fDbZ+qT8uIYJHo22vbMyCC+ATZWqQIIeosnUNakuzd
IpwohZ/tItZWKFn2gzAvJ+EkCOHD1DxXeiioZ4eRUlw+LAMLk7k09QyTuVPZwgxNnvwqb6Y0
FIKrCzxa2hE33y6T+xjXbIWmiUbHZT0OvhjE3XEsiuFhVcddW6aflxFRFHZFPas6mREgTiw5
8gY+imJbD717Ochr183KOaghHt1JQ4TIEkA3NKOqS9ObbWeCJu2gCS09ymGZUPNqActxGl6W
wLJMHMlc91uaYAla3swzLEHkHjNc70/YSNxJooAwfBJashygapNGNiy2umvisryS4UwtGBa7
HIJGnPzyZomLwrHLkaiUo65MLLpdCchgIrSqW9LsniGbKY4LaxGXVG256wLOyO0p7sfl0qxo
13GgaEmH62K9YHLGnAsb50ynMLctj7p8YUXbz76xIu/OMQkCeYKLrY9GKmt/03+bL6ORjmPj
rJoucpIGvHXcjiYRD+Yz3ZTynLVzWseh9VE9eM/MGVrWGU3J11fFMvZ8SYQsfttQKjrzNzGN
Qz2Ir8ZlaWZWHXFTPLz3s03gcrhEQTPgTSfHzG6a2urZoC4hzta9WCFNRwqXZ6Wc1LxZ5Fw+
w+cR5H57fJ5InieS54nkeSJ5nkieJ5LwPJE8TyT//0QSw5vwWWPHZDKRocTZ+hWjzkZN+jo3
+oMOZ7z627mHPuCbw8WlabIzN9rqbb6qwOgZq0GY5O7sRIfV4GNZvHbhQRT1w2fYeM9x1MvA
Ds6TNgdENUhp1gaYoTwI3xk5gZa4vmpuOg8SV1OHLYo8W70/ZASWuHj7IO+xe6lyGQzJ1mY3
wZBxoKmnLKgxJ39n28pMueD/4KHOUdBr+0Fri7wi3pCZfslqW7z0WBpdS/nhnJ04xLO1WT9O
NraRI5nclkgPiyNJzbWs2khaG+VpQsFozBTlmI2Fc1eyCelm++q0XZ9OKUg4fUDqiZr1pf2J
0ECoKK2D+qcHrODv8fbjBlaIsYbTrX3NcPp7e/vi2x/+KleYkV6Ed7/c/vHuz4/vw08vXn3z
409XVz+f3mxfnzYJ/PEEQaLHcBc2adGmUvZrfDPxmQAtfHq/ffUFdfyXZoLFMIu1Bo//SzMk
FzWjUi9e3//57pf78Or7m6vTnalwF3RUhmlkQ60vbUesCe++ICFYXYoXG8wHEdqEgiERBdOm
923QEdLbJk7wDWq6tUuLRwXa0CM6yrfz5N0PIm2JzfqEjt08MdrQrbEEl1abuYV7umctew3y
vidtVyVr/vToU1nW8eu8tej4BZbuazqnemPVdSdhnqVV2Rp77Z5a9GTxYQgvnBTs6WJzFrYi
mW3UFboAGe7zWyIZDlkwM9R81hzhGtF8cfNxzoRWM6QMMAUy3QYmWIk6nnFNnJnGsUptfq5c
xiI2qFQ9pz6qOFwjhyR6eAtyoAMuikIjQocShm9cxAif3zSoh8hZEaUaST6/cORD5kqqzoCm
CrHLB42V5A9JXoeDxeZLG/VBfZLFnwpDJznJxZ8G9AfWcz4NNvo3wul5NZR5BHR2xoTVc9fF
Na6HBXIE0B6yZEpUJ6JbXROowOpcfoAGgqgMt4sXIyzuByEHCTLI32Ldlk/vQBdsinFGC9Kd
iTyeQkq0oEARJpEDOkdG9ABCNtYrtOmrU4Z3CB/BZa63SOOTTaZPgBzwcaagz1hq8FUAekS/
LCvxsTBFWe8Cpd4Ul54XLOvdgGYam0cbfke0EpLHSIBxASye4JkEk/C4qc2rGTmWko9YxZIi
+YuDs0rivGOdVOdCYvMn5sJ5ECN9sS2l5O7nS0BP9nlhUMEkY19tlWiaj9hV2SOWHpwZ61Gs
zuBma8pdY3w2g30M4Uno9Vox7FscTiRb+8qNhZegsKFBu6LPeZl1zQBUxf8IMAAzLDGSDWVu
ZHN0cmVhbQ1lbmRvYmoNMTQwIDAgb2JqDTE5MTMgDWVuZG9iag0xNDEgMCBvYmoNPDwgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNDAgMCBSID4+IA1zdHJlYW0NCkiJ7Fc7kiU3
DMv3FO8EXfqRkq7g1NfwRL5/lQGQ6u7ZcuLQVZPsPox+/ILoX939cv+0Ytccn79+de8A49r8
bfuaXOuXNWG/1gKulwuOq3/q3ldfgu2qA9ivHbvLNQHHVbV77MsbcL1qwuafutYNubrGFWfr
NQgLjSOGCetT58SLtyF1jt+hjffudpX1us3XNdfrMberrpctDr9G4o3zNtOYcAy39jDG6HEd
is4dpjrSOC9XbQ/kLTg9Bv97nS7XPsbiR+3Y/ja+92s9QW7raut1utl5O1xvPVKCtxcuq/sa
gWVzrTM9h8t8rPoVyR6MUK39OrmvtaQd3vhkLfMqgSvzWlEM86wjWnulIbhqAI4MueNY+6yd
Ts7CiC+PZE/7rJ7XIsX4gX+Xzi27ln/mvowIxYJjc11bb2zYuV7QaAH2Mkt/f8NfQE7Xp0cO
96R5s/Nfws1swCqV6kBFwwvf+j0YANivqh7wH+lQFQ7EZrUPyybgoDlwfAWcr6XNlgHkawPZ
2bxRoRlt8oDvKNbRK8+gVlfAwvgC6h5UgS/a6Tra1Vv3UdQQjnqmYIwu81bkfgwl/V5lEwye
jXdQV7y5Xk0RUK0jPDUWN49OCyOQeVPYq7Yy8f5Z9cCuTA+22AONHfVsjno7i1EGg9QDtK6u
k/ASBbdLlOqgMf5BysNXGINtSGrCydgjjcoZS2KpNkesblLPKd3BGnOV9lrPMtKXLy3RQb0N
mWrg1jI24BUUHHvO2mMKca4v0QfyWs9zkz25gy/GatHhCiPxYIprH9Fpg/FYYgCFZU1mpvad
dYUAFRJIezChZe3mssnHuG2LrBQZJKKKySwtIbeQJTIOsKB6T2h6GGnJOKArgjZbZG/GdrHn
NxyGOTuPrBudE/msuDXCMmEIiyiBiAmh2mcNpkY8WN9c20HPrBNmd7fMFzquas5EP5FvOXdW
loZZTK2SfYDCLzG1ovIZOeJj54PDtMHp14pnthF3ZKvVHEWDeQEcWeCdBNNAsObZzRyRrbDQ
o9lxa4tCQUVV/O4ZX7CwD+GIZ618+F5G+eJYYxnKLhi4dbMHoy0a2OoK7t5Dduwk+qUJcNtB
XrX3soLBw8nPyvHtRmeJ43i1pGUkdfD6zoogvbPxGgwOxCHeykpyfSTF7/hHYvxIjP+zxCif
Pz4xsTmhN2TG6I0ZRl0sNW3nnyE6ZgxztfZ5+cCW3ED3YjR+CfRnFkadYBbezHsT75cI0Mi0
JdWGa4oTpxB4M9zXvzCefhAHg/bFtmbTpSQxBuFhUDhlQ22YCmazZyo11cNxFbEKa9tQGnc/
HNhVrfTGX8RW9WeYR6JootRQXJ37WvWkf5hV3tz0G/FF3skum86SjNaNk31e5PM0cmPc2VlD
fbw8SxA/aoy+b40X27NEx1Pdplkcp2cJJVAZkLCFsxmm5u3i07s3nupyKVYIw1OXo4i55w4v
/vxVWXq96IQhQdK4RRrXkB8ZWyRyDekJ4i1SudYOXVbJXGsq/Cr5YRw3ilOV0DVNqt6kdK3V
ZNYmqWv8c+D5XpTYJdarndKD90abdsldo3oK5tMxA92swBK8xMHhUry02YM4Zfxz3EocH4ed
elg6ko5MPPSse42YWD7nI+6fId7IIk0hqyMHG4/3nD9Tms0g1SR2OQedAZ8Hq8YNPoxvuEap
n/1ouPFebklSEsAG3u4tiQp8aHA5p7QksI3U+2QubDRrB0sEGwhbs3RJBZud9C/KXPNDg1sK
0dwPD2p5lvOYVLDN2xj5aFQGgaWCDcrB2suYVc+6VLCt/IboIeRtWY60LRVsa4YKpmBh3vcZ
Blv9bmANxWZLBds+rbXVSrbXg/E1U2qWdiw7GqJ43oZPrhLfB2y0+nEQjqUl/KRDF5448IOv
7uuMBzzskF0ZB1GBtzNcp6aoo6BChz04OYDDwlHO0VaRU+81w7JgCMspAYPj/Kw7ayidiMeU
CvZxFMSUCvZxFMakCnY7AmRKBbsdgeIa3w66G6cPsNHRHutoBF5nx84Hh2lGgeaYSnYECrLl
IeVCv2D3TEpnl8JplHdQ9JAKdpgc6rNrQngYzomJ3zvj26SCiSOejSr4Wa5qVJ/5EdJr07Ln
7qJh4AhGMN6QHRYxalsi5bajbarg17JUMA9LQrSlR243WtSuzxod05ZUsJMjdB3ZGTA0XOO3
DdCI7mtTofLgn294Bu4A8fnTfEeydkS7RY8yWbLDKdA8dBlhi1S3qP3mVMFuqQaaKZI+4nOS
sLGOxg21WsJol25lBXo8JWno4PD+MqSX36GK7OxGsZf1uo3ku16PcVKsly3IqVQwMYsOjdle
jqFrexgjj72kEj1hKmnclAq+oWtGe0nRlKeNTHCMJQGBYPrLeFvR9xFk49fBep1e9bwt141l
mm+jdAylNAJLBRv+C8+nVLDNIP42JVrN93VyTx4OO6ZU8M3TbYrTSOPzrHPmW0403sWJhnxH
0OeMoWKniktMlRgyKGLMq513b0lh6zkDWtAr9YSYsUgMc9yF/C1Swy/8kh/Uwz965EeP/OiR
Hz3y+a965B8BBgADqCekDWVuZHN0cmVhbQ1lbmRvYmoNMTQyIDAgb2JqDTE3ODIgDWVuZG9i
ag0xNDMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNDIgMCBSID4+
IA1zdHJlYW0NCkiJ7Fe7khw3DMz3Kya0A7FIkOAjlEpOlPp+wGUncnmlwIF/390AuDN7Vuxo
k7vp4guPRgN7q72kPI+uI812/HWrqmkRz1TnMy6+3tI6epekYlDSaMA99U7cVsLukZM47EkA
a1KHJU0u95TtdB28tQ97qUoq+F6p2prgyma4Oy58+LFcRhJePZOYXUVsucfuPGlgHy3Zam5m
hyZ7StZKrZ92yNKk1+XCYPDw4mmZ9sjDDZmaKo+bN8SSGq7vKw27DkYyRrDQ0KRfHZbYZcNC
1RH393g4rgAZF+CbN2JNl0dbEObpyTI7cCc2I0OWKkFSGE2kZPnunAZgTsV2q0WyN8Q8IHLU
W3tAW81uNM0DrJFX6fAdL9eKF09Dan4PtV12yyS3ztukRYDjMaS0zIstyGlvgUm6UsMYdywv
hp3YPO5ZGZ0zTDmMA/uKnJB54OnsTInTunpkF8biQxe2X4zXSSbvIOsEgebl9Cz7bXNdSdN4
G9RRUKk5rrRZ8c89xwIfG5I82Y0RUjiwc6+40O3AHuFaTdlxYV4VsRl7HdFSFKRbMoxhinx7
0Mcgu7XpZnFm0LWJJ3zqoXXF3SvzQ2sPRqMgJsyurAuWT7GjFQVhdYzQtnnFaqZgO/P19y0f
Xw6r9nIoSLCOO5Aw2QqOTKvQxoLVKu5NbdWfCAseeIZU0FszvvEyIIQK3HUxQGj4PtXGLoPr
yLgor+DuZmIARbFK4HZxbJF71rz7DzRQjG8adK5tstBZhuq2K8PRtXvS6Zo2K0zfjzCzxLW6
GIXqaQlrGUaW3tqqWI2/9KZfpA4kKeZOUasmUs2WqxXPEC+mWgpzeYrusxQGDag3i85SnuYD
hx5d5OgsbWHkxajKyp49SImPLiOk7yxF3+6k7fnkO4Q2lzg9rU/osIC4LaQhdsXt6sUloeIn
zToDkdG0TpKWbHyv6o78evv0BiIW0/gP/i8fkRsoNuDb/fYBh3Jex9vvN35JOd7+uf308Y/7
12/p+Pz9/tvXb8fHn9/+hK1QBbyWVsnY9Pn9pk/c9MvbrZD6LXcyc02W3t0gcrEgb7SMECZC
gIw+DW6Mgy1IDE2SZbW916QS0LjRipXPsvojFFJsGWEIKxm4qn2bUK3qJGsgUeaSNZZWphnU
vFO0suzWnmqgQWB0apIpXTDPrhFhhh4Hxa6nsQ5bGKuG7Ipzcdib6pLTENBhsDtc9kwntQHB
N/APEbMm2SoaCMNp9UVEc6PdEiLMSIsJ2wW2czOhCctlefhllakqYGh3DD0FrBF/0Glye3PZ
auyIE7h7bTcUM4wqeWzbJuNc8vRAA9ajIGstEPJWikQ2Y9Uajt81uazn3WgFpfSIEd5WwLlP
uynI7Ird8IjLYbmpVEE24/bF+BeJJt3Y6rGOJuz7m1GrIMPuKeS7cn91kSem8VDVsjGXd8b2
8jyXGQjZWWqMQakmvW5NI5a0wwauFCRjhmtEj6Ar44S/facMlCq1J3mGVSKDwtPDG2lk1GNv
lwFEE+XNKJ1C3x+LkIiIYLPcss3EO1zVfVQsPpynNmUncUzKZDRdAl6b/5U4hrkm6revIOKJ
oyKsUorGoMjiguwVdJEoTKv6oo/6Msku2qNqbXFs3ZjGco75Bm3IKOhoLg70kMgtAz/1ssgx
kifdDQgS2Els3YnqZa/6bNY4lIlhIyXqaF3tyDYqn8vFfQwprMs6pftQFyUXQD2P1dWADntb
plhMC0j1/WoERrc2ihGT4Ahgfo/9fLXS1uyzWV02UBF7I8XPALV8+OtWN0yndZtJkWTyjVSE
hcmL4a3iJwOT0fYIAEyOYqrx6WevS/T4uTz5OUaSlY3xa7tqprBI5AlKu2we4XfcxUZ4earG
T6GwpMrz6raK2aqupOEjeOw+4pnVrcJzu8RLxo6vmACd2JSFgvHwyc4/8peNCxScebohwfcd
8LJiaovjZf8S9SCUsYNQTW9KTAPeMQuY7b9r2bKmYdmY1VTqdsbJgOFpbHL0h3BXb7gl7xEN
mCz3Ru63kZogf95UbNZEPK5g6phnzyGzuZy9T+I/O7X/gmCFwO3l5WGz/Zohg9nmzBNehgxO
3a+p43hNHa+p4zV1vKaO19TxmjpeU8f/MnXk48vhvdwaqdjoASEQa6Ref4C8YlCqorlbJ/WW
4JCG5d1Z59y98254XFtlCS/1nSp32ywWM+BHDxdf71v/VLb+3d9h17vSrnooVnErBhEvzukJ
oOXVxbe6wC17DPU5tv6J16fHDrQh91CfHggI4nCpH3vOIlaz4W44u/b4fjBBTJp8gpv2uv5A
EC33rjoWFmLy1PGTKl1p7aV+t6JiVFDcunnZvLmV/9Tg3ZfFunIPXrLnyMWYbgOF+G5XTI6K
8PpfAQYAqtEqFg1lbmRzdHJlYW0NZW5kb2JqDTE0NCAwIG9iag0xNjUxIA1lbmRvYmoNMTQ1
IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTQ0IDAgUiA+PiANc3Ry
ZWFtDQpIiexXy3EsOQy7O4qOoEsfkpJSeNeXhn3a/KuWIKgejTeBPczNMNUUxQ+I+epL7jWv
WuVucn1/SbG72bXmPef143Dc9VorLNP/4Km/X/X6c331su46L1W7cRjQHOldmx/qtcCVar+N
uN7isN09ULsXrPVutMqtzXG5O7HdeqnAJdC8VQLSdyv3MOAADd8cxo7ogeOm5p5meKZ13UXi
Yg3c611ahMmLu7uegQkbv27pvHucdn5uN2EN5InjK1ZYxZ83X2bpeJSjEUjjUe5aeBjJxsUa
aN4GzwKPwOseEskO6FcAjbQ6NOCVyU5sBY99jlv8983MV3gM0y8zj4xYb6+3Wt+fW6TUBBED
T49CzbJ4fi2SZAM1dex+BXjdSxKvS0fFJYCeDr999NdxmO0uGzaYB1qT3rvjWRATL0fFZkVM
TzAOR37uoKGIvArlmj19WYuHTEXnAgt9eRWJNQo418b+8apsJDzX41ht+4JNWQ7/DjGukUcl
eh8D0/LacVmJVuML/WMrjY3gDxBxKGn27PsNVpRdg9aUgFnrBzO73iLeQOaz2o/iWZn7vCIH
5vMoktg7yXwel5x2gVv6Q3Q+gXm+exzmI9gjv4p0mE9gtezT6d5azdYQNKj5TKply3smrPV0
LgW1B7ZfWOJ8X2gda5q94hNV8f3M4vu8eRjmU8pm8XnE9333lv+BXPaeBfYP8Tg/xulXmiVr
6HEiVz1TXReCf6yegk7ciYPL4FxmUhwK5RzRAnvK2ww7g/MSnbF4vZec5oJxM1LM91db7IP9
lrYMXeNPXYQelmdisc/bYhv4Azu/bpF441S0xTIp0n9CHvYGx7ubpO8J7gGsNGuc7qxx8/EZ
rHGeDspCD0QR2ww2NM9eJS54gdXBogIjb1XRKoc93PL7xY6MjsV9yLunt7RXOJ7dLm9Qz9PY
Vae3SP7rstJJszsYH0bN0zUmtb5e5nMcQECaS9l6zJF62keimPgNSear7cP8trAzEKMz/5xB
DxkxWKefVsnSMd0grX748tCKPc9XPouBYBeOmV3kpYVzp09jI5SgPKfXLB4XydCdzWgFsLHR
zsWz2RoYKRllXz/B1s71mc6FGcBqYG1XEIE648UmQpsivL1q0NSCvTb3ee4O32TBhV6m2mLN
cYO6IBnEXGxe5XnCQ4J8f/3z0STXR5N8NMlHk3w0yUeTfDTJR5P8HzRJuf5cbzs9lIljm7FL
JXd6pVKRveONy9TkxBN8/2t5/gSsXJZmx2YGx2++TLqOyzUSYv6Quhe5BiSdvhHiz38Jsg9k
4iBIBSns0ew9yvbiW39qHK9ML+RM5aiS7JMP68pg28Ajwe6kNOePGtz/MGDQ90L1PLoaixOc
xOhdxmlS1i9CPIoP2lH/GhRlM2Fykp2kpBGLDzYy0SaKirFmI81YQMBJCs84WpyOFwC3PQbo
y72tEQoE5oj98pN0ianhFOwpSe/RWOy7EWXxl+nRljXEB1omHvr3q0bjOaOFnIg0/AQmbJb7
QyRisI0huxxzIfgKlmOUke1CnCI5CBRBctnVGINn1DsJNzDP5yiPLHYNWQN/bB4SOHDMnjeN
PCki7gyPc4JlGfYE8/i0xxSP5OTehK5mdi1rfNhDOgJTo7QR96SAHzevtexY5rDuBjbisfGi
/JN9HHV3tmzyjvMReb5lDV52wkUB2PO6HjtaZ64qzBceMjeVVHrTLUdaULXu6WtBfo+87KEA
1FuXBe49loK8GVeqDXzMFbJZKhZO3b9EMHOA6whk1dfNyvZvmycqcV4cz1pbllFG6dpA8fe9
Fdak0N0wLtJkCIolDa1ymEem1zFabs3NTxBiWLey2ctHuqRA6qHOgZ83zWdTJ6sD5s0lJHQ7
Qd9FC0XckvRYREgAS7hCbj+/+JYFXu0w76NJ3iu7I6TFHqgWAv+RImimkCJHJwejrRTHYFcL
vHJKlr10zsYwW2KjPdVq6LOXcudSsLp/7bRGndUz2T7AFPbPuAuxbTpoxHQXvjWJZb5ZNBLo
eCRPjUDtkcXzJeewFCzvTa7UdoRRUw2m2V87GHRu/BlN8Dyi8BdAUCkFgMaT2V9RGcCyoTBD
snGlkmRoL0xFriHYQe48LuF887U3zJhRD+a3xBABx6+8wl91SYHsPsAiievxq6xkMxt7MK36
fIsU+fVzX1zYkmWegfRcuy8s8zzfqCAff7jk+18BBgDJNCY7DWVuZHN0cmVhbQ1lbmRvYmoN
MTQ2IDAgb2JqDTE2NTYgDWVuZG9iag0xNDcgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgL0xlbmd0aCAxNDYgMCBSID4+IA1zdHJlYW0NCkiJ7FZLjmUnDJ3XKmoDTcAYY+aZJLMo
S8g0pSjK/qX4A/diusUGkkmpzuPcg/H/o2ZI5ZNySUCff35U+Wew4JwQDOtxGyMxL0iGK07c
BXJChzUhC+7JxTA1Ret/ekBNQ/6npTI/a0pxXEAwpg4TZ/22Job9vCZ4sH4P7/emJ29ZuDue
jxJhFCyP9POWhmAe+rPjBoYzTAzyPXOqiy9O4Z4aT7mhx5R4nYq13NIiNz1F1VRMCfSyKr5R
2FPWY5hsNumy/C2ONmh2lZyIDWbHYH7hnAZMrO9+cdUHGFa1f45fvgw79OgLlEC2PhItzGQ4
O0b1WOs8X16aGSDYAyGY9fuunymmRGCYnN/9+64/K2a9SLE7vgx7oOgV+x7kwWjY0gYsgGoO
8sTVzfO4Atjr+piAt0+rRUEtdyq6FM8UgJZqOCd9kmJPOeh2T5kg+bX+KU8fFpyQHPeFB3gM
F314wAEjno+YfJgxeM8dDrVI08evq1mLRLFfV4s9RNJtQVNrM4JVrjHIOGEnS10PkGCrhJXa
tVraYzgcesP82KrIgy+wolWZe0munkW4GSLwubl5zXrq1aeG58X2LClxbxEV9b3SEiZo1h5o
Im8esKBd1DzpDbM1m74f9+lewZpy0sLawmANDqcZZN2wrBezd8fnTWzNs00o6UfeQi00AkBb
xwvqChqC4bEFkXKdL1J9krZSYUEyPGA7XtSGCtwiyY6hcBWUYFDhJ61ZNSlvmQxouOFM+0KG
x6wSvVn6ToYN6zFNTH7uLxYsjqJS5ruk6lDPQfuv16TUBklbcWdLAesxvuWOjmm1A3Dscqbd
ZmPhcNLMgYL77FPdkPte7iO2a/vqmzTvNVjUO68Z2mbhPZbXdjfa3S/OZN4eka1bkbVSb+jN
nuz5ZZEh79QO0T2ECxcwD87R8+A1S4ANtneiKoRtsGk83L8+CMmmxprOGvw+UUWDec3uYqni
WbYmP81B5Kft+VZdJNfzujh7SmbeDalrQj4YeefDu0c0L4CyXfb/EvJfWELy56+fYXbbJqKt
wPFYrUFXCfmsrtaRfYx6uF5Ma4zqqmJP+HK4Tck1lOtcPFZrBuMOK7IMaXGbodkym3V174Ff
B549D/aeWF1tvD0PQ4stq2ZhYSuNZ9PwJih4Nq+hjtQ6XbAZKqHxwXSj4Oodd8xGyPD2JoHa
Ap7W5R3xbYwua93HvKjNgBb+Ubeqa25V56NGS/CbkerIHgvxy/IxoxUfr+Qmx5PbLbpSHMzT
ECumvIqVtkr5wVI7PEOtMn//+Ftyzkb4N/ubP2svWg8goZZi/OPr46dfvsrnz399/GbcolZ8
x7VCdC68XOvMJ1enMk9u3bkS8u+4RbFz8eVaW/5mXzhXHAW6ldLkts1ecYu4d5NWrs1G59LG
lcyobvKUtkUUwFZ/p/eNLhGVcG7K6jHQ5XqxeWM3Fa9BXBIIoLy2jI0ua0rjIM5o7LKCkje2
BKvhbnnVrgVgDWny9yhKaxHOJl/Ve8p/nFi2SMrvJaq3TxCR56FlC6VWMWYK4mKF8p9oli2c
4jAYiEFeyhrkUf0xpgX+KFw2fd1GlN6ehN2iKtGTfaVv8lbpyn9cuUVVckMKsQX1ptb0zZUc
+BLXoN5l/toHT9aULbLSJEsr8YKBxn98Dznwe0febmj6ofLfottiK4VQB/dN3/oeyF7Y1wMA
Al/8Q0Hf6Y81NbBHK1G9s9Hrw9+D21PetUmNjuwW2JLHu2+kqo3+ZA5QoI+KI8ijurK9NQV7
bGW/6yFzSIde5PNdn+ngj6Bfct2bTddeHvg1R/3dOV3nWmSXoE5YIKijW/PUSYXAry0kjvSU
g17v8swHH2/yrBMw8ttNXwQOOt3lGx78fpfvpzl81x+nN8dNf+hCEPiYb/pDF4DIv0Z36PiM
/Gt0pR0f9Gt0h24CkX+LrqwQcLgTb9EV/umdW3SFTie/3/lnciLfzLFVMvLHTb+cydnyXR4P
c1q5y5/J2eCuPw56vcnDd7nZ8CYPulJFfrvrn7nZ6K7fT3uu0ZUR38f54mt8q24okX+Nbz3T
k67xrbaQBv41vtWW0sC/xvc05hpdtLU08K/RRVtMA/8aXbTNNPBjdOOUEz4fU4726MYpx81W
08COkY0zWvhwzFwaUT3MaOG3SO9x5MYNQ+jEccXoJfBzNH4c+0uPu1TcjphsNd3pcZmKq5fQ
bTX13etfAQYAsMpDrQ1lbmRzdHJlYW0NZW5kb2JqDTE0OCAwIG9iag0xNTU0IA1lbmRvYmoN
MTQ5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTQ4IDAgUiA+PiAN
c3RyZWFtDQpIiXyXMbYkJwxF87+K3oDLCAkJcicOvQbHc3y8/8QS3UXp0T5k/Wcur4T0AOnn
9z9/mbz++Ofnr59/f8qr6sXK/PqtXNRf5cVdr1ZflfSy/vr710/wLfHt6gFX+cCmDttV6g0r
wNSogfiQyVe9eUu8XINbkrdYF7jIjXfA27Asb76ZyeuKfQBfRiPQf+P9jqaXhPPVxMEsbxFO
v+ot3ynx9eKaxHskJWhb6jXRdNkgS+ouO/Fx77VzwsulAuISiRzX0haAi0Le+6UuHv9+16mn
osZHuWHsnpLgV+K7As+95tjHVWTyTyZTXd1MkJkRCayRgUWnslK7ZBQGdYloalT3w6eyEl9m
DfXNcX42O1JZiS6hoSDfIxy5+N7sSGXtV0uOH74qMtlW4kcqqvtdgQ07VkvCqaQTW1H47vqr
FfuAKQAKN39xl64AWtZs+sWOiOrNwufpW9ZTcecs+Wke17WtSCyP4bQf1zuGRJODalmbr1od
58jkh89u8k+b4Af8z1bqVRaf3eSFyvZw3I9GK17XZW5wk6s3UO+x1ZKiyW7yzA5IuN8a+pLh
plpV7HgWBo+k7+FNnO9oqGT7+X+YVtAX8whk9JVOKgSnObvKeauTXtslhntFbaB+iNtTWSoM
t1ZlTg6PS1vmAll8Bb43o6TfYqfBL5dREbxGmxB8oEVC9UkolYbXOqvCF0zmgiel+Ax4hQU+
MN4Z1cdBVPJD0/wloOwhjehltFQCfMiMhNMn9JKJ67PnHJKHynAENNwWC1bRagV+y5FGuYKv
K0dUYEEf+Yb329jpFUt+9SzJWvxIIGWf+T01BOCPMSV5h3LY/sSR5UtsXkuxYJ0tAnPaXiq7
xs7L6QM9KrotaPCBfBT725pAK8oLE8i3nTfg64Dw+9uZ8pwVcGa8HaWC/qgbP076423LxNdy
0h/x1CBPZ/3WN76e9W2Phw/6XDZYDuI8fyDfjuJxmJDXs/4e+6m2jvc9l6faMkW/gfypts7X
9jleawWfqusrZIuIT9Xl2Tkgf6qu833LEB+rWy/acDnjuzm5ncKpMYkgr2d9+06onb8w9oj6
6Qv85VAeJ32OBhB4KWf9HaezvG3hSD3Jy5dDhU/6cu34sb7yZU851ldiKEH+WF/5sqccq9ti
KEH+WN0WYwnyx+q2aFOBb8fqehOx4cfqtuhTkc/VhZeONcYSfLka1hZfOl/AOy+gjg+1843H
/lY3rC++1b7EvmJS+Ab0G84P3bqNlgucGhm2ac3VxzRsvrA3cpg70ANobL2c1r31Umy9YPxw
fuvsSHNdZ/P6qPf38IS9o1ZYgL2pL6kVe1PNpd3bX+dFt+ZXBRZgf+0LdOuvbQBfOM9nzk9n
euaWfq6rj2+dstfGe4LSaH7uBdk5FeZLxxnnD80uoMsYqjvuNtWS0TQbYo56Wf8zQKUC5/0W
EH9PZk+tLA9zfRsupbyHp5FybwQLuKbUOD871PGk0pIXSCEzTvsBitF1BW7JCRQe7Arq7r3m
w+RNJxsQbzON03Nscj5vNxWKvAHpNR1xoehPW6mpspas0CHxTkc08uR9pL02mHKd1YDbozzS
VmcAKww/Gv4d91SKO0UdPesXOzN7h9yzcvsf2p47CaLIybjZ/twEKd0WhV7bc9YF/Ryvuuc0
uym4ZGV1tMYfbzZlmDz13FLi/JT5D7+xovf7HOaEC15eTkud9PJrB0O5OIO4Z9jvzyeWdHDI
vAHrIO4dtN/N0ffdkymcBWn5XvED7FH4nZ/clOvoB50tB29Rw+DX4alw6gnF22Sfg8l4q0hR
0NaIRdO1LnhlweM+ZtDxvt1vDMCDejr1fp+Qsy2MeV9AcH9qdDaP9kxg8E8eDe/zYQ3kW8Qi
KY8deK8qyJtOfDkGhlI/mI1Qfsjk77TDTOq7MkmnfkyzBL4OHMyk/uqMbkl+RNMcfLmjh5lU
IzsK+oFzeO2DM+CjEcpbn/yKBvue8miL37SlItwAdgM/mQn8TS/PVOx3BssAdZHJr9O0TaTF
km2C17rx/azfdeOxoSV/2JM+RcMMPMyjFv3Zo07RLiON/awKVVCXGY3D/wkwAABdYcQNZW5k
c3RyZWFtDWVuZG9iag0xNTAgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1
ZVR5cGUgDS9GaXJzdENoYXIgNDYgDS9MYXN0Q2hhciAxMTEgDS9XaWR0aHMgWyAyNzggMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA2MTEg
NTU2IDAgMCAwIDAgMCAwIA0wIDAgMCA4ODkgMCA2MTEgXSANL0VuY29kaW5nIC9XaW5BbnNp
RW5jb2RpbmcgDS9CYXNlRm9udCAvR0lCQUNJK0FyaWFsLEJvbGQgDS9Gb250RGVzY3JpcHRv
ciAxNTEgMCBSIA0+PiANZW5kb2JqDTE1MSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlw
dG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3Mg
MzIgDS9Gb250QkJveCBbIC02MjggLTM3NiAyMDAwIDEwMTAgXSANL0ZvbnROYW1lIC9HSUJB
Q0krQXJpYWwsQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMzMgDS9Gb250RmlsZTIg
MTcwIDAgUiANPj4gDWVuZG9iag0xNTIgMCBvYmoNMTMzOCANZW5kb2JqDTE1MyAwIG9iag08
PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE1MiAwIFIgPj4gDXN0cmVhbQ0KSIl8
lzu2BDUMRPO3itkAxh997JyEkDUQczjsP0Hy9HSrPKDsfW7XaFSyVf3z6+9/jf767e+fP37+
+amvPstgmq9faun0qi+qreir8Xj9+dePswNYodadbfNi54wwZcK92LMB5ky5lxFZyYWZIqy5
sEIVM1deEuGVKY/SYhlUM+VRRuwctVyZYxmU+jcKCKf+jbIATv2j0mPnKPWPCvQi9Y/s4Qhr
DsPI0cyq4FKhcStTZhg5rrkwxSq45cIwctxz5RXZkQkLThxTJixlQBWcK8PEseTKCmWk/klZ
uuArpg5qaVBI6qDC0EnqoBaODkrqoJYZeyepgyCb+jf9hwCn/s1CUEPqnz0d2yboX6t2U0fl
ucvw3y8+Wqh+CT7Sq7y/YaDRwaqzBfVVuhz8QvVh5zLqM+JaASe2myfKy7sc687FN+ArFr92
E4t84GilzSY3fcSb/YD0AFoaBXGjx7uP1s6LJ+CH2DqN6uzFUKl36dFULhPEVTbc72IE4MaN
QXzR5vmDR0/Jus5BvfljTsvd9Qk4L43qzb7L5tdd+gK+WidB33Er8qJn9NTWG3UCdZ0b54/6
jJ52v8ke7e79a/xpy4yOmtICR3vZ7DNdM1pafRNFZaJN34ZOAroK9LwXcXV9PJrB0Da96Vj5
lM3fXZ8C/Jg9Fj9K9Xrm08bgaRNsyyjdm7g+aPCz2fpadYAyeSXrnvQZ7LT/qjJqW0aU+nzP
Ffw0+6i9r4xb3Xe2NL9yLz74Of3PjzbtmCj9afoKjrLvgwj7HAoF5eDnLuBTxjDYZoNJn/MW
qmh+vv6DlZuNB6j6fvyi1zNWUEUY7sDqhw0zpdHD0XZ+YSKfk2sBhortvhk1SrM/x+Tn6XPV
Brz7+Amok69iO3w+V9cxDg9Yc8OQOC9eTfNTcU0JzJTJD5B37foUE0dKi3L0Rnyr8LCufNpd
4STYrR9Lt1lvXro90D9tbNHNVWjogA9gw+fTydbhKDeUt5vb6fubtoG3ClUBcZtRHvp42ggu
rL6Igv5ONc6PuxoGfrWwQ50ftPl2T6PABWqbSEGfvZvydFP//zYf24zdTQndxPs/rovR3uL3
0LR49x+byOCyeX5a3yvwqiG7OE998/fR6/H2N+vXVNCXjY9P6R13Omxpxydt/lbHpQ4RwKbM
bwse5CHo4qO1kC+c7u9ORp6Bh/ziTxBt/h6dLsBDPHJe5ubvY9Uxb0P8cn7Kwc9E30/CgWPk
huzoeD/KGRjXQnZ0mvtBJy++zuvG72MyMHlD6nV80cGPTL75eUKeMv2depDnXJ/PeiTX13nw
muuvs56Z6Xv4QXxl8t2PFPBUc3k59Cl111b8gafuWvoZ19l6nkj9tQh0FpT6u1MQ8qm/w+Mi
8qm/OwchrxlPX/NJM6vHwANfuTx/NZRr/gF6FMQt/4RzQLln+rY7jobyyPT5a0KZcn0+6+Fc
/5SXXH7pV0NTh+VrQjl1WMrZn9Rh+RpQSf2VnU2BT/3d2w/51F/dARX41F+9Eio8kTqsO6MC
nzqs5ZRHh491N98xNSwwif4e6256mkca3cVdbX/gA18ojqt6vlNq4BV3L0YN41fHqKEN+Bhl
+npn1BBkFHMVBiXjBx08BivMYcbzhBymBPiQMUBej5in0Vg/qbe2RRDIjypAYj4d9SufKqZl
yL6G73ga4q9iVMZwbbxgstYFeLU+gvyOp+Kr6HrJiqb6u118nRztnU/FV8vFR1M7vFAafeXT
8Ooxo60WQVa0dbR3PtVnyGa0tfoNE/V3Op23qfNt6r8CDABvd13gDWVuZHN0cmVhbQ1lbmRv
YmoNMTU0IDAgb2JqDTE5NjQgDWVuZG9iag0xNTUgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgL0xlbmd0aCAxNTQgMCBSID4+IA1zdHJlYW0NCkiJjFe7blw3EO33K24pBRHNx/C1
peMUcREg0HZxiliwikCKEaTw7+fM8D5mdhUmMGQsdw+Hh3PmxdNfJ79E73wJeXnwLrTFLykF
18qSU3MlLk+vp3c/vba8fPh6+uXE+NBcTzkyPpLgowuAd+dpgxcDTy1WZT662ARPZcNXhS8u
WeM4K5N3aUc3hc6Ouk/GehV43+FdwZOr9Yp7J+DDcdfuFT44CrB0mE8uMB3ZtuLDgW8uN2U8
MelM5Hbb8cBmF4rBMjQru+nAyvE7iQgFQKJlV7ZLKg7B1XKLLS7m3jd07dp2fgNfXdtIGx5g
e4NtjjYsHdhqdIydr5tbcnmF6pCCuslry90lyNIirwdch1TkCCzGOPyem3dlg+uIIpd0iABd
i6D9hrYRBeNJKQOpaj+I6HCqrmYlTJIPuTZmv7ram1SgTFp0z57LtbIfV7xWEimSajL2i8A3
HwYVT8jjYG03EvB+y6CUjAgT8sVkvWcu5RAzKDUjsrYTKfthRBR2bPBs4D20YMwT08nw2BGH
StSIBAhUzQGlyY7DmUrVSC73elu2KilnNoOHrtdVC+g9ZIJSNiI7symKo2oBv/k+egOvldpN
2QJcpV1U2kaUud7qdeHCBr+xj9HA4Z1yU7hqYpVXfDL4nkO9KVyVy8wK1+oiSspN4dLgbMAI
43xdu4A+IscEZnO+mlhAFW6yYU+q0Lw5oCfq6gAasWk2hNkJXHKv8NEeUIx5oiu4Cc3mgk9k
zJdr+yY2UQCyCQcasZl2NsmgC4WozGdupRpNM9t5ROaBznPbZJmUue1qwHVuulkibWa6rAG5
o/vMNtJFg3WTfss0xotu8GFuvBoqPc6td+PBPtWyumC07FMt0TSNC/tUy8qtW6OnWqKlG/BU
S2RIvXLhVM3monYh/QfYxGD0fkaFvzBE+ty2CcLop8p3rnsaPVW+myCMfio8mrf1YPRT6bsN
wuin0ndnTc+UxzRsYjD6mfQ8alsiMy3J2xiMfpbGQFfDJMzymKf4KxeGmZqY4oPhEmZqAm2p
zNQEOJuwCjMtgW7GhWGmJVmoVtL2Kbw64nWfypa17VPYQNd9Ktu2bxstNpRiN8SrxmYbLTY0
ut7QzAl2VqDE86gdFnI1G/QkAniyY0u1U5GdcoifFwZtZyI7QwFdr2aoSgafSkrGeo92Rqta
WPQ/ZZxGMJoJsBYDtyMmdvCjR42Y1c67Zn4FOjc7wFY77trxGPh6NR7rVyDwHr5U9rPM3mF7
IelEhZdJPwTxbA1jVM+bbTOeRfMUBFqictPITGZ4lnSjaJbZshzxZUYnz71BW5ZoLIegZnTC
i68Yj5cxV1atkR6f8GKD0zX3sr166uF3PUJhR2qxmjNkuGyHK/XbtFjXlPHm2bnYhyl1/Y4F
WIbKvke7HqECgrsa6pUfPHj1qrvqMSqgHoauXoTYwINlk9K34pWqjb/W1vnB0+Lhej1FZfM2
BVhegbmRsr3qCpEY5WLq+B8n/v305yksHxd5oH5bThSIR8cQO5t7PZHvyJh1ST7z4yIgu7pa
BYn607YOlWmuG2GuLJtRWQAIHVEL1t+ivOa2Xetqt7mtx4nrxpWNofp0+vwdrtehKi7p+ZJc
+/h+CbZRmopP404piCPXdQJRHpZ75yP2VR4E9nXgLevO3NBmltXsWAAJqlx9x29cr8q+bVtt
Rrf1OHJs3OgYsuutrkR7/OFnyP5xSaKYL/xgColhohj6DJaYA9uSugx4geMzYhVlVYREK7Lg
hAYQkYhDMG+zlVQ924yh81sV2MJFLHORk0cOOgnxMJ243wIOHCbY4QOkXCrojXJrLIjrCBbw
40KodE+nx7fDkC2zyMi5zBdJyS8EPsjwF7GMDzDAjF5Oz2+JzX5hIL8fRQYYQe1NLBJqC7Mo
Mkq3xHyZvZQo8RGz76OMDyFS4C25FL5LSmImS1F7Eq6cklxB+aZVfsVogvDk0YoZoPyI73Ji
BxNCATs4STh2s5e8EK78XRqJ0fmsklg68mgqcG1gxgnXyehqbQTF479FOkoEhqdYPHc73L5x
irFy4kPEH+AxS10UH76/nN5dLtB9uTxzmUJJwx8+VBE2ggpIX17xG//jM/hMzP2XJ3x3+Xa6
+909fX0931/+YEtxWOJJAb9+GODK4Lv0/PzlHM7n8D1jvSNuuIEjH7gHBqIyMvD5S/Pns8fD
5Zy/YI8PPp598rSesbJ9gIYyXSGl1pOE1d3ntwmVlZIcBZcyFGfAdPbl7KtvB7dU/ye1bStv
Q1MgPCkfyLWcj5MGKUiMPPUYwAT7gCgN3C0RJIK981yBHbJ+3PPHy+pyjum9ONNQBcFIa6Yn
rBoH8wuCgrxkb6St0HXiS0Ty+Jn4l0RcokX6iC6LFM5ghu2vo9Lx2nM7YXPJN25S1MuoLFKa
sOTMehE810JPe0a+v+gYIpQ3qWsSP5s88iFy5Pw6Qmf5dHdPd+ke8/cdQuQejfFO4uTT/f1v
l4/sCRrRWLcKhzzFJB2QGn0wpSQ1D13cNwFItnJPEWrEgy86kx/Mb5kiD/NaMsB1KJ43tggG
jvPPK9mbmAHPIVgCm0Jr3QGjyJdvknqPXM1YlIKjgrh7VMfiRSK4k6UhWfdVoX8EGAB97UxS
DWVuZHN0cmVhbQ1lbmRvYmoNMTU2IDAgb2JqDTw8IC9MZW5ndGggNjEgPj4gDXN0cmVhbQ0K
g3ubHABPUTiIqrL9r7f/rbX/rrb/t8D/XWCNAAAADxIXmKXesrr/xND/S05qNTpQsLn/rLX/
jJCqkI6KCmVuZHN0cmVhbQ1lbmRvYmoNMTU3IDAgb2JqDTw8IC9MZW5ndGggNzkgPj4gDXN0
cmVhbQ0Kx8/ipKz4rbX/r7f/qLH2ISIxDxIacHmps7v/uMD/aHCYDQ8TAAAAHB4pfYfArrb/
p7L3JSo4AAEAEBAbLjBGUVp8hY/Kq7b+sLj/pa/7CmVuZHN0cmVhbQ1lbmRvYmoNMTU4IDAg
b2JqDTw8IC9MZW5ndGggNTggPj4gDXN0cmVhbQ0KpbHjrrb/rbX/r7f/qrP7JCg3AAAACwcP
AwIEMjdNrLz0srr/tL3/foa6BAQIJCU0W2OMo6zypq/7CmVuZHN0cmVhbQ1lbmRvYmoNMTU5
IDAgb2JqDTw8IC9MZW5ndGggMjIgPj4gDXN0cmVhbQ0K4uzvucrorbP/rbX/rrX/qLP8mqnU
CmVuZHN0cmVhbQ1lbmRvYmoNMTYwIDAgb2JqDTw8IC9MZW5ndGggNTUgPj4gDXN0cmVhbQ0K
usLoqbH9rbX/sLj/oKjsGh0oAAAAAAACWWKDsr//rrX/r7b/q7X9LTRHAQECWWGCrrj/qrL/
CmVuZHN0cmVhbQ1lbmRvYmoNMTYxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9M
ZW5ndGggMTc0NjQgL0xlbmd0aDEgMzQ2ODQgPj4gDXN0cmVhbQ0KSIlcVAt4VNUR/uece3dD
XgQEkmxQ7nJJhDwEgkiANASSDSgE8gDc0CDZPEiCJFmeJhpeYghdHiIfphARpYgEqXhDAwYK
LSpa+kESilTFWl5qAT+BtF8RKrK3swtS6J3v3jszZ+bMzH/mDAhACJZCImtS7sDEQrezEljx
b9ZOLKpwuac+NW0asPwmQEeKFs7XGmJPLuS1rwDLoJnu0orjNXmNgDWY5crS2TUzM469z3zi
UWCYKCtxFbdvjFkP1KezzxNlrOg+pLvJAWtZ7ldWMb869HFnKstvArb+s6uKXJS/uxooP85y
fIWr2h00jpo4n1Nsr1W6KkrmH026CtRxfNx0V82bz3nzU3fQt+6eW+LO8R65DDzK8QNN9QAi
+bWpOxCpxCACMC/ye8n395abl3zrvr/4jr1b775AE96lcryLP+JD6mSv97AfLTiKcKRjM2qx
AfWwYBprfoUcJpX1GyjSbMFAbOV8tqKNbZ/GYhxAL4owL2MJ6uSn7FXHSPfFaGShCmtogrkA
+TirLMcwTEAl3LTUdJprzfXmW9iO/fKoeRtBsKGIqc28qn5hfoUE9ngVm3CW1nfZi1SOspQt
X8dcNMrpCpml5o+cgR3PcQ4KMtFGh0Uc716CixRBtTKNd9lmGuYRtuqN6ShDIw7QUBor7Gq+
mWm2oRfHqOZdN2EP9jG14hC+pGC103zL7EQk4vEk19OCdjosvbeXeUcxYiqjNADDeaUKf8Cf
cIJ0+kBUqcFqopqqPm+eQg8MxhTOdgd7/oNuiMVMS+QnSoY5BqGMyys+tPExzpONBtIkmioG
iCqxRc5FAEcczFSMcsZ7I+9+huJonwgWHXKbsku5ZXnYe84M5ROJwWt4HR9QCFeq0Tx6kT6j
r0WamCFeExfkBmWnctLq4qqfQQXWYBduUHdKomz6JZVRLdXTK7SJ2ugEXRKjxWTxrLgmy+Qc
eUgZw5SrzFOWqyvUVZZLXqf3iPcv3htmorkC2dwPyzj7V7GFK9uPDpxmOosLpFIQhTJpZKcp
9ALTYlpDv6Em2kktHOUEXaDL9C+6TrcEmCwiSthFXyZdzBXPiQ1is+hgOiG+F/+R4bKvjJND
ZbLMk1WcVb1cx7RXnldsSodiMs6JaoP6htqk7lI/VDstwdYXAxBw/Kdtt2Nvn/HCu9Lb4N3j
bTHPoyefoY1R6INkzt7FNIvPu4E77j18SsGMnY1iKYUmMDIzaBbNoWpG8iVqpO3+3HfTQUbp
c7rGOYeI3v6cHxNDxRgxiekZUSLmiHVivWgRn4kfpVUGya6yp4yVY+V0WSLnyxrZIA15XP5d
XpA/yJ+YTCVQ6aP0VWKUOGWsMkNZoGxRLioX1Xz1mPqtJdBSYVlhabX80/qENcWaZc22Tre+
bN1nPRVQwN35Efbifdz30Dm5TDrkXqwVQ5RI0S7auZ9noFhmCu5U0UQrxSJqEf3UastIMZIm
olOJYaw/EW+IH8RImUnjKRezxOA7u1l6KO/wL1n5CFeUg1xbO+9cbQmmxeKaJRh7CGI4x/xY
DlLi5DF8Kc+SVdmKvymBFE5XxA6ZxV1wSElRnbDLzdgt59Ai7BUOnk63AlZzH0+kd3guTKZE
uilNSDGRu2iY/BrL8az4Alf4Hq/Er6lYKcVaDKFaXMTbfCsGqJWWWEtP+rMoVzziIWqBUHZy
dcOpH0m1B16i6bLRck2cxgJ0KIE4I3/L2XeI3TJT6VRzqIxvwCKswBxzGWpUp3KSSiFpKqKV
czzdamWiYuf/Ep4q+TzT9vHtPsBzYLTMZE0Ed84E7ospPCEamTbynFC4g8r5jj/NU6wdLZbJ
ohWlaijx1AGUY94cTDPfxiazFJXmeiTwPKg3a3nHJnyLl9FEdd4X4MYjfHPO0AQ1Q3SoGWaC
8IjTIlc0PHi+jHY0ReA7pt0spKi/h0f5HLkYZa42/8rd3Z8n7CYU4il8w1Ve5Qjj5GEM8U4U
zWaGdHO9Z5Ft7jD7UCDKzNmYhIPYblXhssalpk2ZPDp1VMovkkeOGJ40bOjjQxIHDxr4WEJ8
XOyA/o/GRPfT+9q1Po883DvKFhkR3qtnj4e6dwvrGhoSHBTYJcBqURUpCPEOPaNAM2IKDCVG
HzcuwSfrLla47lMUGBqrMh60MbQCv5n2oGUqW878P8vUO5ap9ywpTEtGckK85tA1oy1d11pp
WraT+TXpep5mXPHzmX5+nZ8PYd5uZwfNEVGWrhlUoDmMjIVlHkdBOm/XHBSYpqeVBCbEozkw
iNkg5oxw3d1M4SnkZ0S4Y0SzQEAIJ2XY9HSHEamn+zIwZLTDVWxkZTsd6VF2e15CvEFpRXqh
AX2M0TXOb4I0fxjDkmZY/WG0cl81WKU1xx/2rG4NQ2FBXHCxXuzKdxrSleeL0S2O46Yb4c9/
E/E/kTfvnuasv381SnocEeWaT/R46jXjzWzn/at23zcvj/dgXxGdUeDJ4NCrGcTxuRpHE3V5
ToPqOKTmq8RX1Z36SnSHT1MwSzO66GP0Ms+sAj4am8dATo19j82Wut88B5tD80x26nZjVJSe
50rv3dwDnpya30WmapEPriTEN4d1uwNsc2jXu0xwyP1Myb01P+c393Hjc+4hS76M9Ce5IQyt
SONMnDrXlOT7lCTBU5TEZvzkEXsZxXwi5UaXtAJP2Aif3udvqNFhuua5Du4A/cr3D2pcdzWW
6LDr8LG+PrnXarz+M2/ExRmxsb4WsabxmXKOKX55aEL8wlah6+4wjX8MH7IYW1feiIEMv93u
O+BVrakoZMFYmu28I2sojNqD/3Jf9cFRVVf8vPfue7sglIWwVNhBEsOnEBJggoQirARCSAoa
8rWJtISPWmqkUqnWdlCWiYSwJJ1WhYmANEmx0IQOG4w1ydgamNEUO8rU6WJb6Ycfmamm06oT
7QiS19+5771l94Ux1Lb/NLO//O459+vcc8+5975g5uyKqFrFNT1Ojb+Ua8JOTbx7VToiuYP4
KeuPeqfHf2N8E1JWbl0cVSZ8RvXXrPrC4vTCospQ6spIle3bwpIkyapfFK+zS9GU3JAWUO2S
GtBkLYJyfbwxC6FRUTENP0MG9ZZOjxdRKTVKal7UV5Vv/a8YmZZ2nZ06zfe5l6Sr3Wwzo4tn
J8tfSpKTzBsV0WAwrsHCkspIZGRSHULNmnC1TYh4KgmlpeZGqRSZOQ2/TrNnEaMiEA3CZbnc
APFnqWwxqWHALlfgj6MzY04eDrpIJC89NS9SFdnYaYY3paf60iNd6ln1bGT7yioncDrN7v2B
aF59BXy1VVmMpFBpeXu6UlfUHlTqiitDXT58B9SVhE6rippbtbyifSrqQl2pREGpVVnLShZS
WaBCBYs8rXpl+0AXvkbCslZIhZQ3dyokdV5Hp9DmTtXS+RydCp2wdEGp4z8+Y3JLQonRI1Oy
IoOvMnw5LR1cS7k+unRqcLpPahL/jIhhq/idYSOqvk5fFTvID6z2TKbv6GUUUvZSpdpKOxna
ZAqKk3Q/2rZCvh3czX3RvhT4M7AEKAMm2bo1wEagmGW07eK+GGM7jyN5B1V6p9B9epl5BfMd
1HvpbuAoyi3ibTph5NA2yMfQ7wWBjz9ugz4HjVZqhP4I6jdDdxQcgtyM8nr0y7LLIzwN+FYD
Awb0szDOfnu9M7QztFDsMN/EWiowZgFQiznuBOcBhWiTAl4O7FV6qU7pNVtQD6YazL+X9cAK
m/Mxzh7UL0O/qZBrUJ4EOwzwGCANmKmepBx1PD0PzsT6y611A720ldccXxPst20aCsvGwkRg
zl8A6WqO2QcekWCbGzUurNYWUBhcDQSAIvUV2ia+TAr89aTeRxrDS8R++hNwm9hCayErsLNY
76BDLANrJHaYV8QRatIGaBHqvmccxDq2wN94+aofU6b6N8owptEuxNcKjL8bOIox/yrjYQuV
YP654AWiT8ZQLVCPuf7h+Il9A3k39nUd5vrUyzHcSsXAKuxLGLiX7cH8mexz3nelbDAHbd9B
m/UM6L8ogbVzTHIf7o+xptlx2HKVqQVtGuDXv4AF4GcbHMg4s4G6lzDORMAAJgNzgT6gBagG
FgPPATMxN2FeTcYrYoZjU8YHYkPvhQ9hm4xZaw1H5X5aOdNsj8XzpBknqdpGGo/J+cIxC1va
nbE5pzhmHJbxXc1xr3zA6+SYijNyT/TTKrZB5iBiy2HOO9jM+XBQLaU68CHEcQ3HLNvnMPuF
Y036BDlh85KEtWbJHAFrROl2rNc47PgizlvpGMasMjbhTGmifPFtvL1/SJvE+7RCm0Vz9Szo
sB60jar9tM6Ldzn28g7IT7q4keGJKffoPVhnG/wZo6fg02+JmHqziCm63ma+q5NyTm9TH5Hl
IeyG0mPVMTMS6/5d/eeBekFvw5nZZr6nx0wT63mMc8LTr2QBqQ5DfxoIA7d4ZyuN3mql01NK
PoNoALhPBGmxHqRbRQ/2x49zHrkAfan+Jr2gNdA+ETN/r4QprMao1uOnjfh+GsNzqReohsHj
g7cnxFFSzLljyWEnXt3MZ74dU1PABvLvVRvv2PgY+Ahx9GPFmuNWPp/l/YAzGqi14tW8FI/P
c/Q0eL8Tn644rXbF5yh3XLpZ3i043508hR37nPXz+chnHJ+RfM7xOeO0d3NC/4jaijjmc/gV
qrTz+mYbBbDxLTv3cQ5jv8tN08gzjxsd5gltnHnCmI/y7wDdPI51PxS/U0PmoH2fznLuUktP
Nzj3qL6Attnn2TF53nxIT8h7tEzaN8I4Rbv0y9h3nIHS3iY7B+FP2F0tquDzQ1SPdUzU9iIf
oQfWs0/kXhDdyPcC34naAfiZ76IGqtHewHuB+y6gsfK+WEblsP2c1OFOZWadXk4tRj/NF6U4
a3toC+8Vr4Pt4b33PkCjvX6cEzGaJ36KNn4aiXZN0gdBOi7jgvtWE7EvPJvJg5hdizY8XrPs
E6Rxtj+OSV/I/niLcHyxLzCm4ad18j3RTz/SS6kcOdTsCVOzUYqc89MJjPE0+pWyLeg3Sd7X
B+gu5FcdzqY6nDkk47/SvKy1YT0P4VwHtDB81EY36mH4sFqufYWwzti9nD9aK03nGDEO4Bzm
98QBiojZtNKopgboGnSck5h3P3SPIn+zkLv70H+KfW4T5t4HPfddxm8ZfiNwvniClGKE5TuA
pA38TsH82rvUrBVQHeL4du8B+GEPZeC+UBB7NwHzLEj5ERv1FqTOZ7GSpvnoYalfQK+prdoN
iFu+Q7vEbvqGKKP52jyaKMZShvgNcvUTOqyNoQ3iZTosOqmeZZFCMzW80rUOvC1Zf57uZL36
GuRGqhRL0L+Ovik20A6tHbH3Wxop7sZeo5/+fcTJVPT/EOPaUN6mSq0MuVWL8ifmSW4n5+gw
yxkinzJkvwRIWx24bFYL4bcC7Cns5XKSvbA1bqdj4zXsk+vkcdGP24jDtITIvAhMs3iwSG2g
NqBJ/QPlamvou8oJs1s5QnlKH3DExs8oX3I7UIQ7PlvZCcwV2fQcsBvlOeBfAqcsGW+3bHoD
2IOxz4Cf4e8ChrqcFjJDdxRoBH7t1CWC57qWPhF6wOxOkp/FXQMoA1jDQHKdnHM33uXZwG1m
NwOxWMAwdtF4z4M0XpsB/U3o55L1APLpWZo6nD3DQTlPWdKHFoKJa3T2AzzhOnAxgVOZ7bvh
P7Lv8wD7uwv4ivTv38lvxRB9QblgXgSXKRfIpz2AGAQgZ0BOcfzp7BP0j0u9a/8QK6SR+U+3
3i2793U4WX2GNiTCiYN4PDxGSxliGdoDbtl7jpYyjBdR9+JQWRwfBpV0i3aIbUIMzhgqG3fQ
DIY6FbZO4j7IOSAun8cZAXBb2X80rWLI3AXUDnyvAfH6bFrJSPDrQvardsiqd/bH2Rf3/sC+
oHiVVoOng3PAxeACh+PxbZ8XSTFfZMV7XOazpM/V5mpOXM2N83zXXHvM/ycgd14GeoGX/tdz
KYRYBXyAcRHvkGV4R8bwPrmLaoiu4Cz5NBP4Cc6hEvDr0OH2HpwFjEZ5LHRfBz9FdPkjlO+H
PmbBVEWAmux35UTofm739drjFVv9L/+K6NIAcMrqf7kVuAflD4CHUf4j+Ay4Ee3fQ79HwWet
+isbID8IPA+5H/K9QAjlH4D94DlACjAO/Q8y+D0y5Dv0v87X/v64XsabZTPsnALuBu90f0Nc
Nzv7OQy7vzWc/R+OdftbYihbfsA301t490UTv30+6xvHYeznYCL+xXr1xzZ13PG7e078Ekj8
7EGSEcfvJU4MxJRQE2oggJ+DvUCtKgECi7NAwo9IDDrB5ADatMFjWrXRFoKYxjamNQhN07QO
9cWmmUOYkilbt2blh1bGNPoD2u2P9Q8aqAYFFfA+d7YDBFBGNz9/vp/v9+7z7s7ne3ffZ1md
uoOccjLPo3kuy/NnkT9mWLy/iTwW/RIyJcsYTx7PX3nuzPNXMG//e7k5YjyrMa4OMa7MuXH/
3kr/TV4BFKA0w1uhucWmp87gbLJhT72OXPPnHOJs4+cagHV/VtRfSA1yDfg04jLw9eyZlt1b
H9pjJzjT/t/xk56Rn+NM9WXQPg6PK89ifgbLOcafxU+Kic7uz32WP+aMvv+c/l/j7DmfxUR5
6UN5wATxRO09aTw+73jieFxeko3H46H68Wsvm89MI9PGMO65e1LwdwvL6/dy/+wYxj/HY89b
9h1hDwnfD+wDMzJn6DHsF3OAMgBnVOoQynbLt4lPPk58iF8HcG7evQLexOvAPXQ/IexG6g7i
7yBWLKeFtiWDTROt5/HrlufnIj/EnIl98CAfP6kB6gAH0At8Lftf83dI9P13hlOXv+daWlPX
LWeAcTnghDyPfB04jtiG2NbbbAtWSMVkFEgBElFha4BGoB3oBnqAXGLLlGwD9gCDwFVRo0vF
8UNz9SToJUGJLc/7RLg+HbatFWHiy9E0P7cizaHladnCtOzp2nTx7Po0T5+VZkeVz+CcX+Ab
ChZJReQcwMh2WMp+j52fEpUclaYSE2BSbqZElxyJSo+vZ1CyECoxiZJNRE0NSTReYPcF81mK
jRIHzvyP2ZV0DbuSKLT7eoLPsg/Ja8AgILEPcX3APsAL1mXkbgpsAOgBBoGzwCiQyy7juoTr
ffY+sbH3SA0QANqBHmAQGAWs7D1Yhb3L3zeF5X4AYOxdWIW9g5/1DqyNXYR3kV3E0N6O+xf4
+oXjrck4alXGKS7NOI4iX5L9JX5rpppk/0hoXvVocA47T0yAobPzaPw80YAmoAPYDuTCuwDv
AjGAg8BRwARycQ/eHAGNjQBvARfIHEAHmgCZnYujmyQ7G/fUq8Eidob9kRRjUk+zPwl+i70h
+M/sD4LfBLvAI+yNuEslwUmoJ7hHASvgGtTnsN8lKh1qKmhng5geFbYGCACNQDvQDeSyQVYR
36Q60MgAGUGSq7I4+UjwL8gxmehbVN2zFGtM48azcDE8mB6tx8N0z+GfIOTGc+AQPG48330Z
Hjeeb+6Fx43n+Z3wuPFs2gKPG09rOzxuPI3N8GCS7JXfVE5X/Y1bqRa0sV2YpV2YpV2YpV3E
wnbxi9yy8LH9NF5djRk7ontnVqvGSWqcosZKahyjRic1dlNjLzUWUWMdNbzUcFLDRQ2dGgN0
PqbCoPqJB8IFegk1RqhxnBoxanioUUWNSmpo1K8nWXl8+VxBYUGJIH+uwIuX+GwYYzlmtBzL
uhyP/SDsWSAlIh0irSIt/qKLc0WiOpCOZy/0bQsuY8O4cRh/wzC5BFjwBw1jGQ2jkWE0YIMN
AO3AEDAKpIBcqCsw8G5hbbA1QABoB/YAo0CuGM4owMi2zBBfEwOryQy6kUdsGFcFrnJWrpcp
TsWrLJO6ndTmoo2ulIv5SVERIcRhl+1JWtD3acHNTwtIXjCPHWDdpAx/xMEMd8dvlalJ+uO4
Z0ANTqU/Ii4LVh1dQDy0CjyfxEQ8jzhlzrXEyV4F++LONbjNFvfMUk/SQn5Xn3rL+U/1I2eS
wf2Xc0D9m5a00Lj6V5S82qeed+5T36xJyig55UlS0ElNSPud89XjI0K6FxVH4upuTn3qt50N
6lanqOhMV6yLIdJt6kpPq7oM7YWcG1Q9hjb71IBznboorZrH7+lT52AI3rRbjcHOdIpO3S7R
4Gp/km7WZ1kPW1usjdZnrD7rLGu5VbWWWUutU2SHrMiF8mQ5X5blXNkiM5nIU5Kpy7qX4K+b
kqtw4i8flFiErzBuYcS+RmVGniXmF6QIi6yqpxFzaCOJbNDMG6vcSZq/otXMcddT0xEhkeZ6
c743krSmVpp+b8S0Nn2lpZfSA1GUmuz7SUqaW5I0xYteKDUdS1v6CaX2F/aXcp7xwv5olJQU
7QyUBBxL7Au+FHqE6chY771PyQN+mXk4sqrF/FVZ1PRxJ1UWjZg/WKW1tfTTT+jVcKifXuMU
bemXltBPwit5ubQkFI1GknSN0BGNXoMOK+aa0MkuonEd0WRXWnckravC/dBVcoIuL49UCV1V
Xp7QWSjX9cYqw6HeykqhKdZITGhixdr9mpEqaKqqhKbIICNCM1JkcI25REicTkhcTiGh04hT
SJx0mpCsuSepyUj2jUn2iZ4kek/jTGsKLmc1BZeh8f63n856r5cm6qIb28Kd7nCHO9wJdJgv
7dxcYhobNK13Y5RXaKbk6diwcTPn9Z1m1N0ZMje6Q1pvXdsjqtt4dZ071Evaws0tvW16Zyhe
p9eF3etD0URDU63/gb72jfVV2/SIxpp4Y7W8rwb/I6r9vLqB9+Xnffl5Xw16g+iLiDXe1NIr
k/ro0rY0J9ikfKzXjtLyaH2Rsn2JWLx15SW7S08iIfklmeSNmpPd9WYBwKueCj4V5FV4pnhV
IYptmaqS3XXlpcjWM1UKiu3ueuLt2hHbQUrCXw2lvzF8UNS1g0942npjj/ugLmzq60OxLkIi
ZvWqiBlY0drSa7WitIP/JHNhtmzSpHAyNZQunI3ChbxQksaEvGwRL8vLywgf/v93ZHgpfwoM
NpCguot2kVhUMl2RZoatoLkVv7WtteUk0iV+PMSi+IEx6qWxbBti2CTtE/57s+jakfEy89CV
4fRduCWWnY6xD58lvk9hv8rBhcPFSki5vdxeBYM9jdzWpKHbeg75jGiWIb6pfevuCtaR8zZR
yGI9f7oNO57DKitKks5NkJ5CGazbrT2F64ikSJokSb+2/+zlEq9yY+2dG1eUG1dIYFFg0dNz
6FrqYfZa/zP+ublWXFMVSi/98Mxzraf2fmP6YreXeu+uOEVv0sKPL9757Fz0xcMDv72r3tUe
6L9TnzyDzVBYXr5CiSOPjyC/R6LgE0jW1xUmU1dPKApbDefmCZtNOP9hu1pgozjO8Mzs624f
d7N774fXa7uccS48gp/XXOpNA2pLIdAIA6ac3BSLEg4JURMaCARCCCZAg2kKAUQqQ6EpKYTi
2NjYJKGNC8XSKUqNkEKklFaGRigmtHJRJXLn/rO2QWlzp52b29mb+ef/HvPfUKemOZ3Pba8s
kwavp9hDPCeN8RhZSv4nTl8Z0qvKE/CuDIaCAUryL+JksvSx8g0vnl8y98PCD/B1/Lfz5/bv
XPKXe/lrtwv/KrggyrcKn+KXUA7J6MkuGZL6O7EHz7cTmEsTgmWcRjJU4lwaiXXSN+ehJrQa
bUbtAEC7cuQARDKSGRmiw2maRvWspcM0P4x1I/XI9MrqyoBflMpramrP5uYvmpGq4XK5NbsS
cyNP/xDW7QWIWmFdDk2yw4Qtkx6b/DTi22G8nXfmv5vJwA6Hx6brzeVywAHUMPoPXhcuQGaL
cMMZQp5YsNiWoyYv+E1NC7l7Rj9zssg6doSl0a0jld1BQVWFVmX30DRIYQ6aHMzPVoidEf9/
phGYSWQz3QQ8nM5tO6IoIpuSsjuIqipr2b37Uz6Ys1O0IjQOAHcQS3lv9DoKwmXA5YWj+ce8
2Ep2KDu8lz2CW1LCZJZvTmB25InYAt/SwNLIU7GslFWW+VYFspEfxdaTn4nrlA3eVvGAtJ9e
Dl8jV8Wryife6P1wW9x2SVnVdDdGbuom7rZivQWBvG0P3LWQDYlrMy/tGqMPMCezJjk8HibO
rEEZVMdeGK7GRh81aipnBIMG0EgsKy1P+GiwckaNThNlpZLYkB1sX9ex9tsrB49cWb/33ImN
G0+ceGHj7AwZxDx+7GTTO4XRa4VC4YNTB7rxG4XXv7iDV+CVt5/ZzlT5VwDwHmAno9O2xdma
XpXlN5M95KCLP8ljNxIFwrkFrBI8IDvRy2xPCDNFQTnj6AQ6t2zdATTuAOpxAIUs2xEG1wQm
Dj5RVbA1b5UwkYnpArYEWyBCROnFafwyCiefpEOQDMjLuNfAl/TcPFC6PpTCeorlB2WSJWW6
KErVwOdKcq/z8cEFr/992lr++W9tLH77OwNNbG9phHgJ9mbiS+NccutUC/t8YoPGqKTrTue2
7aYUeqZfMBlFQ+wB02SjZtwDI6bKIjd7SJ+tEjkUsoqpTohVDLqadiXH2hyaNswirWdt/wxG
XnJ/QdUwiLOg7fbqZGKd67Zi+EiD6Wf32NwdMDWTiqKQhhDzGSeLX7ca4zNbj63mLGbXPCo8
KvYJ74t90iXX5bj0PbVRXeDJqs2eDcYG3yvGeeNG9EbsTlR9X+n2kRgU+0XUpOJ7o3eQBOR3
wacb0IqaMnWJ4kA86o/Ho654lMPEFY1zmkl7yLF35ukY/gqEu9gOkJMOLyaq3BIahGwzruM+
8iKyEMV1tqp31ZMmsppsJjzpJd+Agn/PmTGyjwDZk2k6wqwyn64fzmeGdIMhC02rZ2rSs4n2
j3kWmlBAHcrgzE8bGycFShK1gHhNTXUVUN+xM9AFGBscBaLES1/WktCkXx/64rcHn996GJ/z
/eejwbvfffOPR5eap049nl524YX+G8uzrx3e6fvw41unFr91/tiOpx8BpiwcvckHgSlJ3DgO
nBIJ2yz/4TjCjKpJFb7gijJZ86peU5YrAmacNyviQoVWpqnhCBwkFmXkt6QEQ5E9npjG3Cc3
jb2RkaqvBzseBvyGL9KLRor2J2ewi+E3WdCC2ixtu8bP0hfp62LcU8FVdKW/Ofistt6/Xdvp
fyV2XJMFi3N4o6iah5cwrIsZLDZsoA+HUQXScHWnqgb4cC85hiJkhV0OUQoQpma0NFmrLWKF
GZOtLVJLwvGmBEYJmiAQ8Ug3G0m0TQn34LqOyCDuhT9uCDauPHCrh3vwL85MGJaDIvOskWRm
zLfyQ4yccOIwPMfgBKkCgKBWvKbRVxtknuUAJ9Xe705gyECUWIvKShMLO4v3ZTefPrqpco7f
UFp6tq98Zre/s+TW288NZJc3b20rfHb1D6P4pfDB1t9v3XjE/yvy3KZlW7dts7ou/aSjuenw
VPPdVy8U/n0Tgo6CB1ChF/xNwwm7xlisrlAPqSfUy6owh5uj/ZLnDOA4UkVOEmSFk5AKYh/g
eD/H8ZyGiKrxEtdH+pALip12W0Y8D4+gAZnvIcu7BUG2i4qr5AknlMcOJqdz2zmh5B5ca2uS
XVpWJW0pqZbavITRSdH8VYhQYhGOsB+z30Bn6Cz7Deny9ODdTqY/B/dzjHCE2Uua3qSOD9KR
9N20nmJJTqVapyZ5kIzX64V0O/WhNvpph5ECy7liK5UprnRKiuOLitJsikYAA56x/aqtpNQt
81OqnUippXH4nJJy3LYRCrhqXKlXBsp0Tsdkf34beeO1ixc7C9W46Th39svZxwtHQNT78lkg
Hjv7S4TfgMcuHFMO/K+E/WlsQzjukc1AIG4wq1C8PG/GNQ9GUhjOC6cicDqOypinMZUwHgGJ
8v2gDCaMCsPxXq/Tfj+6vmhn0X7fm74P1KvqJzGX2xf2PBTl3NOF6Uov+BgH6qA+OWD4fAMe
r9/j83u8GkjE9rFAbE87lGwerx3A40F1e3k8yOQDrmZbLDy9ia6mm+keylMQSdgRSRijMA2T
8IRIwm2WcR5XIy/eB6Sq6/B0fZ1Yir8qlgdyybDaDDTibDSjwwW2MNTqmpoUAEXkGJ/jeXgN
lJVfkQ1oxVcSKOFALyjgl6ASSDS8Gzi4amvnqd2Ldk8+8Sr5ON89b9veC9i19ucjf87jLXTn
rv6jhzrm1QfJP08W1i0t3P3o0t6O66xqmwvIBcDzitBDeN646xV7cTFuwhyOTTZtDWsaHFUx
odT0a7KJ0STKDjGngqNmiDIEQ47nhZwKLjRebuWu5OifJpDMDNP+DENySjaCZ0p2YGZkprXE
WGBluWap2bXSaLbWup6Nv+zaHr/quhLUJYuluHxME2JDmWN4rFfiDEhsoNwqs0rYgM6inK8R
iDOGB5sYkGB67omYoaKvsw3UNamFOkBCtU9BpbCLO92sIqFtD8sMOROn7GB9qCm0+r+MV3ts
FMcZn9nZ5+3at3fne/hsn/d89jn2Efv8AGPixBeRuKLExuFVjuaIAcWmEITxJUKhAczTkEAw
TUOomoKJWiCkFgYcYltIPGSlqopF2ko0hCJSidCQ1hENyFDA534ze2fc5o9mdbszO7t7M99v
ft/3/T73BjfvdtFnbhedzt3H5Z8MmSINPHF4fBOTEY9FOrAxuWPUfWi0i2IJdD+VZqJEg5ud
JqhAHrLpVTTU4YwJW0oenPRMmrFi/tPzlnBPn27pHV3z6Za/Ja7/asdX3VdHq2a91dD26/d/
uvYoPyd9ebg+/NQ3f13alLj7pzeG1+OZ+HX8wbkj5x9ejR2N9u3fd+wYALAY4p1LOIzSUGsk
fTAN8/DjZF6BWEa9MMxhXtHS4oRwFJJZLEUTzmuV48o/0CzY+xc5UgvNKrwBxGNmepLFDVBZ
rK6pvzPcoI9QNaYDADR7V9uqzVQNZHVM9jtFREQpMMVur1pMPtqZGJ45xdpPNt3ewd/v3vlO
wp540HelG3+Nf/cerRjnAAMzgYFuFEBhDpkc7NVQlq+ExkjQYdy8khK73ycKj/nsaT5Fo2Sj
VcApVkWErLRSozS0poQT7bCHVg9JlXEk9RYZpy/Jd2r0dSf7Ryejr/NRtfDfpQhVXMPV1eMV
ycdsIWJqIaK5kOusMrGmYnhyfjoGnYeRPDpIp6VfOlk4czJLH9mXmgzmwqXJBaRO6kFVk124
yDXDNSN4Q7sZFpQwXofW4df5V+TVapv2atpa95voDbyT3yZvVLdo29J2uS/YPnHY88BTTmQb
XtoYRiltHjeC1H18RYaGfB6kwTK6SvAEpONnFKz0cS0RPRS3RgzwHStGVt3KWfvwnlPlnngP
FKHw/ER+3Dle0jgjTs7ZWTZe0twB379jhrzhpG0xZhxNWkmPYXEu1rYarY5GcTA4uTIp51JK
AMGII2OCt0x0Hby89eUbZ85+vWJlx67EyOXLiZE9S7atWLZ1R3PL9mkzOudsPNK9acNhklW0
b3nX59e6mt8tmjS4/fQYwvjs7nN47rItm19c2rHl4Vh956xD7ZuOHqFRsR+k7DY+COyU0FTI
CQISJYUTa3hSg0XewtVAjkIcrX4Oygf3gaVgIfUFUHbMLmaaY3KFk8DZPzQ0RKJDQw8PDw0h
bmwUISEKWkRC6bjlFE636izpf9ub7NxjIY+jLI0ygjGyCOxaqof1FnmZ0qRvJ53674VPxLP6
LV2VhSiezzXqy9Qe/bZ2O+12usJrfBqfTlSLIvA8KEVZlCQN+rKoSRhBVXYvYmVVmiFpGfCI
I4SOOekYMXgtA75SfIIg+0Qi9nGtEQXJ2s0IhzluAKsAnhqxawZ6SSKzG/mL/DWedPKY78M4
ojZqZ6VrGunUsEbvdat0UeI2SO0SJ71tvfQXE61MOOHnAcS8mfrwMPLU1niHa6/X6MPw6xBK
QiHIgx0lHtYyUEHpdOiDg+mDgx2C2QJ9Zvaoc2b2+J5fuKCXtxJZGoAiBo3do4yK4jaaO+kR
wBU4QPzE4SfBQlEiXMUfuQVXPxz95cHL+F+/qMvLrhAG7tfh04lnuIV4b/+aXW/SyLQXouhN
2Ckby46OfsTDnvxAVcV5PF8XmB9oDsSVLYr4E++rQqsSVzcLm1Wx0KUQT2Gxz5WjKA67r7i4
qAhl5/gAt1woJpHsCYoaDUciaMRIBY1Hop3GHVGkyIsy/XeR7bWYQXkgzi0Iatn0C81C39Mo
L5z0Lc07KcdnYEpCgz6HPR1hAY516LvQud/LNtnsiLRzK2Kh/4tioSdeMBMaPWIQxRvYTf3w
HXMolKzM4IRwVAOSs7rUVk01vSnpIcOFKmz+CZo9nQtgf7lZlgUDICDLq57izP5eLnjkD/Hm
lq27f9R+bmfibfzkxqk/nFm3aX/iCl65KDh94bS57+xMdAsD0f6XFh2qKDzd3nK8qYzMtrma
62esKnrQJWlTV9TNfq2Meud+8KCFsC9W2JcvI6VGLp4umxjbdJ8Vye6goeBcVrgpDBrFQnFR
PGyEAcgcy5ubo39vAO+mALyXAtD3vwAm+7FHwJWFp78WmUKyJFmUBZmXeTHT4/VwomqB3bQQ
0enKcDlcRMwibj+2p8PFI2f7scti8yMQEaFQMRwbcYzi7Ha5XSAhOEC5wF8+xYQZ9IV/P/73
hwvXR1+JN6zdM7Q1cRxX7/lN2bP1777c0J24IAw4c55bkrg4eDiR+GBxefeUsmdvHrpxt9gH
VkOo47cCjgraFQmJgk+Wd0tYkhDhKZZIlt6DWlHlOK/KK/8Xp4jKgNIoNeE+8R2+WShcoCBC
KcDqGeVi9ddNEUElFGVZWRisdfrZeYRcffgl1zPaKAx0J6Z1jzbDGlaO/V3oF/6MCrAj4s3K
yHJyTYV4kezAdpKfj/x2N1eAYP00IRl0DRiLbl86gaymYBwsLMg3CAG7CptY0XWdWcLib7L6
+pztOIu/WfR7rq29EBfmBA0Ltuh0wJIZXPpj05RY/XC9HhtJ2gOLp0JwXC7UsHvqMXBSeQRk
eIYPZGV7szOziagF9QJnMDcoF/DBQIEnLcePXFaHH17OcBgS3OUJBX6crQIrMmxw8Sl+P8on
cEFMYoZCeo1eE0odlCcohicX2EQ+kJcPjmfPryjnXW6phIM0KUqiM8POQ9qsspHnuJW7E592
fZY40HsSN145gPHPgsf8S06t2np+jX9qB+b2rL/1FFf7Wzz6RVu8Hy/67BKO97b0/Tzc2l7/
/JZZ2w8MJu61L67CNtiPM5ArNwKLCLrwEWUNJwD0J6c+WcnaikqzfTxsto8VmW2gwGxzfGbr
8bI2UpymVxpCp3BMgF2CRLUbdaEexJdCOdWIrqFbSLAbMNiJCHtdZfTzJGn5zxQtv0nRciSi
m1mO0fJ9/lJ0gstOf2HBiXZIZbHo6raa0VgKSKjMaikJK2xnztO0ADaCUBVyqafgdcftKp3Y
4nBWyh7NxfTkVxE/7cmQRA1JhnQqcxIhssJznCLJPDFEUUitDjrfmssW7HRpcH834qXLE2KG
ig21UW1SW9V2VVBl8DpEJ0uDyb6f+/FJ9/tutLI8McH0UIySU4cUzAwG4kLIqgUXBKpCluVL
Qh3rBk2d24/I2Bcfa7ZK2YALMC9aFqbkA/B65UhdNZh/9lRdtRwpN7vl1VJe5n8or/agqK4z
fs997N3du/fBvh93d1n2zUp4LeIaDLdREEUjlqBB2YpRJIBRAbXVTgrWSEWbaJ3WmcSmSRqb
Nj4KtkKs2oltnVjbWp02tY0TU6eRadJIdVIyjcqj3zkLmJn+Ffb17eXCPed+v8f3SwF93h90
QVmUKfHRICk1IZjiJSu8LPj7yKAFSm+m9EJpw+VnJ2ypyZWizAeBfD00BUFfgijr+xcY+vSF
0XHu9P0dbNe9Srb7fvekN7Bj0CmRclI/02Y0ZbVZ6Wql2rpSWWllBZNPliTK4czomzmiJ56q
V/Bd008zXu/OdiN4up3iF5W9/7dZ1+ddYtJn29MZp50WPmIVmL5E6H00yHwgkAX1tMbT8QOL
1x+o//f4xfHd6Otnf5BeVPjseC93WjI3DT59Znxs7BiDvt3VsNMmAh2pBshUH4NGFtA2LbqG
WcN2MptZNhwtYVLqXGYBv8hb4Z8XqozWMvV8g3d5rNciBbEE4n2GporwVBGZKqJTRZDcgszJ
mSI8VUSmiihmXyWuYmIkRIeYaHimnAzOC1fkr8heFqwLrxdaxTZpnbXJuU3YLm6Xn1G2hDrD
PcweoVfcIz+n7ArtDB8QD8oHbb4MFLW8QMTsibgNkTiKUFTcbWaLCiNUE7RdzNvm6fXQnrBd
zPNFwyjM2Tncz8zs7Msz+Hx2hghzArQ4nZFl/JEGuXVA2so8PFpeOCSJAheAecKj53UsQ+tQ
OJQDx8AgPXluDbd7H2Bj2E7lEZMhLFZQNqpBjWgT2o906BTq1yx5+JL40rDihYYIFUfxUxP/
OilJdF0cL03Efxd3F8GeUMSM5QH/yjwFLvP0iG5+HGPQVThpOmCYeDhThsm8Bg40kslVCijY
Tfw2gneU5cA7JLMaEJaCADb9g9LtllIfDU6QQVcoSiIXzlxgFhGcqWxWh511kMlOB14SaXhT
XPXbZzYeqa1peHh8/dKW5m988t3X7vZwp+Xjb/S/mpqF3n2ie3vP/ZcujP/nBfRXZcNzyx/t
nFfRHHSsTpS+1rTxV2tb/rBD2vv8jpVLiovbYg8PbN1yuXPzRxipceBrP/AVwsIJs4Tvpyxm
JavQfH2VgTHqBQM92XvJREkiEnwmvZ7z6WiqHCassUww8GiJoyxiaIRYg5HVG40RbyAZM6K7
4NjZiLXCcWNMUJMIvwHN//Zz+GThU7Pgo/AnnI/X0YLRZ6L0xjNoANbFogHNQ/EFek1P6xea
ygUkuCVEcbqllEscfIF0YvEI+C8eYcoWj7SXKTeV0enBrywrRYQLBxm496CmEqQZeJ1HHdAP
BMEEBFQz0DmBFHIGUjCVvj8AsgnSmRG6EjSzNFASsCE+YIvTt2uqRv/Iukcv1jM/OckcXbvw
+PFRvvk4AH/hxIesyj5CxahSOk+bYRANuS7RnRsXc3NT4kxbqWd27oLctJjObRVbchsL9og9
8Rfth9xviLYY+NZJLFtRbGAuXL3uOhIbdJ2JnXddjv3Jdj2mn2dHPozVLEwjs/lBEC05NXFD
q8OV3+F3JmbkJlNsasYCtmrGMn19Yp2+JbHV9C3TRdNd8W4iqzQpIVbJDyUdRQGrc1V8Y5yO
q/lSubRPelmakLiXpT7ptsRIJqyuEiYJ1hiJDOqKoquTTFhKJZ0sw7ukMo5T9JFB5/esqspT
+CQ30dyKqLFIZYT4amU1pSPyHA6EMK0mRe1WxnVDLOZUCE9+gkCKEXIXoHhPE/DlQuRC8H2U
iHnoFL1Sk6IaFVEi2ZGCSF+ESwFOCVtB7K4OkqIwRYzaF0wWpM6l6FdSKOXAa/sS/o+OsDMn
P/SW7rKO9uvKdbROIsHPRIKfkwQ/E16MjtiITiLBj8yausJZD7yjHaieANNOYN5PxzRw8sTQ
EJaAm4ny4bGbeASdOr89I3QpInJYBgj/AXwJqj2MqU2IX0oeJckopj4ffYQmSmC32ax2RzDC
6HgJDMmOJ8eZJUzZ2l+09p2d31lV0natGRVX7O7a5u13brjSu/tIjWJw5JxVHU+e39hQ9HTL
Uz+MeHfWVR7d9diOx6yS6A6FjRvy5tS3O9v3VmurFz70tTv3d82Zha7HVCW2OL+qceWSOV8F
RPcAovGspVBe1K0dQpxJDnElXAXHlfv7/bTfn6MWq4+qm/z7/brZljJ7mXuRfZE7rU+LT8hp
+1fcrfr14lPyBvsG9zn/u6Zrjmuuf1huOW65PvDe8E/4XdlcvpxvLeDKZY1bJNdw67hr3k/Z
e4pJsUks6IpH1fHIaFMlwRm6IiBF0GAe6xbYTJ4UCEYFkiQFLNW4eVDcIRgSMJgweKC4QcCD
j2j5uJ/CZphcKDYzpZHRoJgJ0/Q5BI7xCupHdxDrR+VoCWIQTk8YtFCMal4ML0Sggsgsi8wY
KohABc747CRGGDnVji+NnCT0WPElkMs3v/TzoYugogMnFTgCZvHgIPEQeGZhvGCkgEt0UO2B
IIxb4AwwkihUMCfKgDEUk6kEoILyfnyy48STfe3a+Ce/PNtGJ+u+s/XYj7ZsPcadHvt035J9
v+scvz1+9SV08K26vZd+f+XtS6CrNRMfMsOgV2604gRNhD0pdclIFhAe8DdBimDNqsA7VVZA
ko3X493zZPe8Ce+eV/DueYLwS++8nXG+8+ki/Cos8GjzDSbkV+da5jpqLbWORkuj4xB9iHlR
PKwcdpv0osvYSrcwrdwW0yaxW3zdNGAYNA6YTHZTj+kDmpFyVskb5S6ZkRFIjLatgKSORljW
foghNyB9GChZFqgHa1Rh6SFJT/QpxwP7CwkJP0IQKpBGGqSR7lSRnrhJTxaottBlHvn5cp7m
JXwSb8Qn8URe+UJP8vzkwAhdyZA/3VFdG6xeugKGcTRxblb9cMdIYrhjKmdmpfKV9E14Ep+H
vtUjB+Y2lZU0Y1Of9nTcOabshPf2T6+N/7fjo97j7/n7XF0rdh85/Gzr82iX483LyIuMxxC9
o+9VT9v63/z56q+/iWfqSujZ34GRWcDIOu2wkWbFsJgU54lcibVEXU4/bvyytVZtptdyTYY1
1kb1nP8d7i+W664hy5D1tuNj1xBhnt3vT7gxXavdmLuQSkPiQ/bZdIlYTVeIldYF6nLjMrFZ
HNL9034PjUgKsjGSoMjASIH/H9nVH9vEeYa/7+67n/Yld+ezfY4d7JA4IMxWwA4kyBrHyo9K
NOHHCiMDt9CRrgOyJTAg3UYLooVu4o+sGmPr1gbGxlo0iRAiBhFSM6nqpIqJaCrTilagImNj
W7poq7wRcLL3/c4hQbWS+94729/53ud93vd5LAKUFANulpK0VZk2zSGLmpZnbbEOWEBNrAmf
oJaNzLH40EKqWjJWkMUJa3HrhRm3KjDjFhpFTLqFWuuLiI71LbvuHeWqclOZUBhCtFoRlRm8
5HifVmb4pchh42NJ4dNHic3IrZnGtEJn80hpOunyJgi0/DBilsf/KZ51FoBmDdiLoRn7gAHn
qDPFM7Gx7d2Xru3Z/sGhLT967Hwp9es9e3/51ne6Th5+8+j9Uz1U/P7apULF2ArBvvL+b9+7
fuVdxGwVdNEZwLMwYPYlL5okiTBY1YJU0NYH2sQd0je1toAaxinIHxsCbx1G1Qk8zrI/lMac
YhWbby+OzU8stZurlibW2ptj6xJb7faqrYkuuStcFIquSSK00ohG10S2RDoiYiRR2W2eMAXT
ZPGErpAB4QxW7GQ3GwQ2QN5NYMexELAn6hkwdbncNRALvLWB8x9TauDntVlzcr0GNaqScHY+
XZ/D1VuKYzZJk5GsWad4dXNyk0ilpiGV4Ej5BEtwjCIcL0Bqek8sZJpLw2DJMpki18joykZA
RWeGObnAsHXmucpEuNCi8Qm6a5JiJskuIJaj1EQQL1pTz4eo+PTA3E8u3R3/F3X+fI1W0Ad/
0/te+erR0nVhbbBxw/e++zbdED3VT5PQ7IN09viN8Xtm6uzA8/TY4cefPw1dJAQQHgD/FqWG
N8PRaGXssdi8mBfriP00+DPjbUOtMmYbvbHBGIthPmZXJXPVqiEGKxM6DQsZJ8REmeg9DnUm
Qh6LphkRhdegLWES5zfmcPUyiWSum9CYhzSJeQbQhDjc6M7mLncmEofMLRvdf5eNrlM2un/n
YweCO3zgQTD2Gy7DTrmxy3SA1JAi1YmbyRQz02gAYsVE0QzuZaRAlizJ51EvjzRZkNvHX/Ac
05I1RVZBIZmaHSeWXBmnGZqZc/AgzQBPdmWt2oZsQ24RmhVoa9jVwtlwrdXX0xOqOrT3yc3x
xgXrll29Kr5+tHNHbsWX7Tf0FVuePfrgOWDEq2A38tDFRKKQ33tPawuxVlZr3doJrVcb1G5q
o5pCtKTWoR3QesqXbmkTmp7UoJ8rTBA1WXyRElmSmS4raYmwHnaC9bJBdovJg2yUCYSl2BCc
MebPZWE9BGNeFDPJ+OhnOt6V8SyyySwyHPhYmwynuI5pZC3qyjXlMfBwbJfymLIlI7wc8R8L
cldnJtSQDYvQM17t7+9n/7h69X6Y1d+/ju4Knln8HzxzQNjqxWW/X8kb5K9oYqXxH6koi1oQ
f6WMugV/nj4ZaJOBiObAxC+uF/fpgi2nQjXooUbP27NyGgofWG2JX6jhF7yX4YrMmMTkRdpK
JqXlz+kb9X3iHv26eFtWTsu0Vq5X0mqT3KgtMVYbraxV3qi0avvZC9JPtPfkP7A/ysPyXeW/
8j01bOu6JIpMkGVF08DZSZqqphXZURRZZCwt6Y4k6ToAw1QK6ZdkRVUDAaKzi7TS0yTGHctM
Fc9qUnziclmtVHVDUwmkiZAG/UXoErIaKgRg8Obzqjd51XO5RThixOZ1z0c04eOexILGxzUr
n4MSb/l0qs03Q58fgXZSzBSaQaJDM4FyN8ETQsuPNqEdZPvBCUqfdzMVECimmlfzIj+Wja6x
SqNJ7WVR0FzDyhHYFA0jukVdm1vdpKnV1XkA7EZfdRMsH/Sl+HKuhhvHTCtME5gpJIP+8hKR
Jwb7apoAxMG+CC43+swm2V/4WZAv5wL+lzOtaFrxVvZHjKpOBO7mOHl+gG8V+1z88j/Pxf2P
00Kr7ygg6sxkcWplKa2lClQiPXN3fDt958b4yZekgQeXae/43tI2Ifnt8U1Yl4fgsIhz8fYF
iRNRwta0qDHH11yDv86b768z03z10uForlJKSj3STYmthsOoJCalDumANCExSoguiGm/yS0q
N7kwdIseQgdBugmEpMgQqDhGJtmJXcsX2GVh7mPt9zi13OB8akIwwccSechR0sIe5SiSFO0Y
0hSpiWf4wswc6pcGxlbgsx8hRK6HyVxLf3eJGEAz3F69WA6AQX/ymgNGLs2G2bD2cfQvKema
VEwJUTVVq7nxlCaKtTMScjgBP1Khcm1VzNSH0rQ7fSItpKPRqop0t0UtxlWQyxUQIOYFuApy
8CEtZHQUH9QSuBYKci3ETS+8N/ZQEZWVAS14QTfdHadxvl384XZxvh2cf+JZuF2c4XZxLmbj
yKUAbhAP4sZw/oBvHMf9IkTI1qbpEKGoq4UkQf6JnH/Vn+FfkGMSKc+dB5Nz51PP4YPHh6LC
p2Rd+iLtOl+DsEyxsux5SsPTbFBhZLolKrUsb1t2B/wODiRosZzEQFdstLY/miqCTqjeCVpx
ahvhOCUwlTIHy3IA8A0v5MIND2Gr1sr5iptHEEB05OSC09v3Hk+++P6bZ87Xbv5Cxw/7N257
8uBiVn+s5ZlnNw6cvVCaJbyx85nFx35ROi70dXWtef0HpQ/L9SLegXqJ0P1eSBLlkPCWedG8
Lf41NCoWQzLDlpuHgnnBpD82h9xb7oTLUqpT4UTshAQVEjF0oyJYUed6WBMu18qB2RgHHEx2
AAG1uKHlJAjM5J/ADHOtHHAw43B+zwc0oJcdbtHj7TDgZRfmJgIU/gItLpKuKrcw1+uOukKH
e8LtdQdd5opCNhzh3Cz2W5bPvCkKRj9DQVaGewxVPEQCR5mVmTjo2XDPUUjOQ0q3RM1ioXMK
U2AhCA248shVeI1ANwacwetaTbQMbkS2NF3VFV2UzXpwDHFaqdtlkOcAyp3YhTnKgG8k+gjE
R36+56MtJ9eYev+cHU/s/hWrP352eUfzgv2l3cLhb7Qvfe1K6TLq8WWgx2cBigaJ0R0Xwi4+
SQiYyElWiZTcjVGMv2Ereiy4Un5C3SC3ql+Tv66qOXOxvTjS4C43V9mrIsvdzdJmbZ1ZsAuR
dW671K5tM9vt9sg2dx8Na7JkbBKfkp7SNwV3im1Sm74zqEcTTLGgZTh1cW6T4rwMFFAgvk1S
uEFSzPLV0X4umzHgmgEDxIEHfIAiCKG6dG6eQoli/p/98otpq4rj+Pec9pZ7D+VPaSldq6xr
+FMooSPtRBZMLw7HMGTgMESMjYFECJFsyRJhzuiD0XXDxKBPPGhilj0Zo46pExOND2LU0URN
5sMMmwYezDbedA9qwd+59240mgb3Ynw4h3zO+d3TXy/9/X73nvM9ZVES3x3XaI2Q8/1SnpNd
2QBvpZSSNdbr7LXqe49VX0uWO2+ttf4gaFXYpFvK5YCjIyxlOhV1u3Ik0rO3stmiWsrj1AYt
tfIMJbctY1gbNsa1ccMt9ybp4q/upKKhNmDJdX/Rqar33JnlH1nwuRuvXNvcWFrMnVq88HJu
kftZ86szmz8X8jdeZPWsYuXSynfLl76hRy1M7+Ev7iYIdv08t3bqOk2H0D3MI0C6RGNca5C5
1JKJ1Xz1at6XStFGkJHPWOTiPo0h5usigXXVrPB1GfRypnXZcarBBRqZMwq5ARj1e9KIUyfk
k2HQ/ocgdXR1xXwh3p5GlLoqbwviRpPowj5xCH1ihI3wUf0xY4JN8Cl9yjiBWTbLn9VPGLMi
x3L8lOtM2Wl9zngTC8Zr4h2cFZ/iYtl58TWWxRVcFjexJv7Ar6KNwhEhBEUcTaJTDIKEh2bW
BNMaLQBpR6UYFI8MHVIymlWykAKWwJS5kHM11r5GWbFmuaZ5y2k5Ta4mKDdEPpFPIJnJ+Kz8
mJ2ClFujIQKGIeiwQroMATqwkLiDIM3HOfOUCcMFpiW9zBvTTdMknc6Nj1nkQ5MEANfIMo0o
N1ms/Pr38snZCO8qZAvZcGhjPWsf4LruqDGfJcVyz3+RIyFGA0ksyHNdtnipQHZ0D0v5aVnv
9JOweXdz+rP1xt2hxM2lzaPupsJLk8ceneGnpdK+3VrvgrdpcR8q4isb7rZxfQ643yCt8CWg
v0Xahr5S/glQMQ9UdgPV39r42kpT8wMQOGpT+5FNcBqo+9Mm9NM/Cc/ZROa3qd9fmt0nSxMb
ABoo1sarQPPrQAvF2Xpum8SCTfteIEm/t+MJIBUD0uul6eQKhUKhUCgUCoVCoVAoFAqFQqFQ
KBT/P8DBIFsALmmxMOHBjs3ljOVeoAo++AO1wbrQrnAE99ofNDSiGS2taJMXHUgB99kfPGAP
vQ8d7DvUDwzg8ODQI0fsydGd//F/1dx4n/omRMnyUN9CkbTjfuzHg+hFH/pxGEMYxuOYwBSO
YWZri/yjiFt+e8mvh/wOFvmNkd/T0m9rbec/pyr/prl29NDpNzLHl+rl2G6yvY7tISsknwC3
QTMhNDg2RyW6HdtF8w87tpvsccf2kH2yr79nYPBAouf41Nh0KdvKWg9VfBAHkCDrOGVkDNM4
gqcwiWfIGqO5Ul53O0+Reeaoy2AGZRRJNZIYobArqFIuuqYg2Dw06G6y5NXtERO8hpJ0p/09
nRlqMKnWM7q8zYrudS04WaVatGhJ8WRV9296RLe8z641t8px6fIHt35/rzBZDV3WQObZuvNf
AwBMATCMCmVuZHN0cmVhbQ1lbmRvYmoNMTYyIDAgb2JqDTw8IC9MZW5ndGggMTMyIC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAHUAiv+De5sgAFU5F2NFJG1JKnRkTZei
qvCvuP+ttf+wuP+dpek9RFYBAgAAAABGTmelre21vf+utv+osfdYXX5KTWiwuf+zu/+xuf+i
quqGjsFgaIwrMkYAAwYICQyOltKyu/+vt/+jrPVeXoBMS1Fra2p8fH2Tk5ECDABo4zvHCmVu
ZHN0cmVhbQ1lbmRvYmoNMTYzIDAgb2JqDTw8IC9MZW5ndGggNDkgPj4gDXN0cmVhbQ0Ks7/q
qrL/rbX/rrX/tbz/dXyqAAAADA0RfIe2s7z/s7v/UFd7WV57wM3/rbT/q7P/CmVuZHN0cmVh
bQ1lbmRvYmoNMTY0IDAgb2JqDTw8IC9MZW5ndGggNjcgPj4gDXN0cmVhbQ0KcF+LIwBWQBxp
hX7Isbv/rbX/r7j/sr79SU5rAAAADBAWHiMzRkljtr7/eYK2Jyw8WF2Bs7z/sLn/kpzQamxs
f4CACmVuZHN0cmVhbQ1lbmRvYmoNMTY1IDAgb2JqDTw8IC9MZW5ndGggNzYgPj4gDXN0cmVh
bQ0Kh3qbIwBVNhRfTjJ9oqnzsLj/rbX/rLT/uMP/cHuiCQoOAAAADhEXlqPgsrr/sbn/mKXe
HyIxMjhNsLn/rrb/qbP8cHmKeXx5lZOTCmVuZHN0cmVhbQ1lbmRvYmoNMTY2IDAgb2JqDTw8
IC9MZW5ndGggNjcgPj4gDXN0cmVhbQ0KtL/rqrL/rbX/r7f/p7H4HyIxAAAALTBEcXumCwsQ
SVBqs8D/rrb/sLj/prHwIiQzAAICMDNFeoa4rLj8rLX/q7P/CmVuZHN0cmVhbQ1lbmRvYmoN
MTY3IDAgb2JqDTw8IC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9MZW5ndGggMjU3NSAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuA
sAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbX
jp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIR
ADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM
9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4
X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1a
VW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHBQn8f0TuF
+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+Hb74zn34
pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo26rFanUyu
xIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68Br9gH
sC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0
WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsY
A7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEs
qAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6B
U+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelG
BpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbg
RQgjSAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZ
EolkRfIiRZDSSTKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAo
rpQwSjpFQWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh
2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVT
mLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuX
vYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMe
aJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+
tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlpC9t62mbZNtt+YHvBdtbO
3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2hJ3GZhxtHZMcjY47
HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252Pev6zE3glu+2
ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7BXmqvrV6X
vAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8tEUeULOoQ
HRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhLSEnI
eyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJ
SCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdN
xHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPq
mapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3Z
T3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8
XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIV
A4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0
R7UcbaX2dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V5
9Yca2A3ahguNno1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2
yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osev
Z7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvO
DQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf
+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr
6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4
WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F
S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/S
wdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg
veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTv
QO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+
S/7c/23//wIMAPeE8/sKZW5kc3RyZWFtDWVuZG9iag0xNjggMCBvYmoNPDwgL0xlbmd0aCAx
MTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAZgCZ/4d7myAAVTkXZEAe
aFM3gJ+l7LC4/621/661/665/292ogUICgAAABESGouWx6Ww8SsuPwQDB4GIxLS8/6+3/7W9
/6Wx8XF6pT49VwwRFQABAE5XdbS9/6Kq8mZjfGRjY3t7f5WTkwIMAI2KMFsKZW5kc3RyZWFt
DWVuZG9iag0xNjkgMCBvYmoNPDwgL0xlbmd0aCA0OSA+PiANc3RyZWFtDQq/x+Wlrfqttf+1
vf+AiL8AAQAAAAARFB2frOG4v/+1vv9gZ5EkJTWKktOxuf+qsf8KZW5kc3RyZWFtDWVuZG9i
ag0xNzAgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA5NzczIC9MZW5n
dGgxIDI0MDkyID4+IA1zdHJlYW0NCkiJfFUNeExnFn7Pd787E5FERMgvvZMhzcqEJi2CIJKZ
kFURoppEdGdkogki0wrFtrIi1u7QLZXa7lKLVqmf7g1ZlCK6jz5q/eWhqlbbPEr9VHazrNVV
mbtnhlr2ebb3e+7M+b5zvnPe83tBAELxCyjIH1PQN23ylUIPMKmeT/NKK12eWaUyCSg+DFBJ
6exq7e+P1R9l3nnAPGiK5/nKoCt7mB8UDaifPT997pQ5L+U2Aelbmf+38jKX+/gFyybWd5Hv
9C/ng4j5EQYbbON9z/LK6jlrTWmrgLBIIDZpelWpC6knTwKZq3lvq3TN8YTW0Qq+X83y2gxX
ZVnqzoongRI74+nrqZpZzbj5Kenp53teLPMMt7j5JCkDCK9S9yA+8G5EvExEPGBc/OH1VRgX
/Tz/v7jG2rrfe+8/27EVn1ESadhBdxCF7yiGUpELidts8Y9oxxuIxHispAj0RDc8g1ySLJOM
pbTKmG1cxRC8jvXGLqo1NjP/NXyM7xjBl5IwAHks/wzKcFW5hCLj9wjCYnTEYIyjbnDhDK9b
jGEF6rGfXja+Y6uRqGV9GRiO4cZB4y56Y6lcpp7t8Ccsx14yGaVGBXogAV6RbJwxvkIiivA2
tjKmZGqSI2HBNCzCmxSjfMzUG3gHPgoRk5Rs9QBbysUEzMBL8GIzjlAE5atn1Tbj58ZlmNAF
SYypAlepH40WG2SIMdQ4h4n4AIfZX/9qkhPlRnWib5jxlvERumIXBdOHdFBNU3/TvsBYZ7yP
EMaTyhHJYzuTsRAH8Qn+gRuixqjBSBSw5UPUnTRK5IifETFivpivnEIf9nYSo52FP0DnjOzB
Xuzj2PwVLbhEkRRHP6XJtJxuiBDhFieUVUqjclqSfI/jbUUvjlE1NmAnjuIYTpDK+p+gfJpK
VfRbeotahC6ui9sySC6U38t2NdHX4vveyDNuIRqxeBrzUMOxfRs70Ijj+BQ3cBP/onBKp3Ja
Rzq10HXRQSSIMcIjVooNYpuSpyxXDsp+MktOk8fkOfWX6hKzy+y7+65vhW+br9nYZTRz7YSx
/kTkcEQXcFVswAGcYu2f4wtc8NcP6x9MxfQcW5lJv6J62kaHqJmusZcIrAQxWNjZapV4keNU
K1aIerZ+gtdJcU58Ib4VtxRVSVD6Ky8o6xRd2a2cVL6R4TJR9pGpcowslgZnJk0doRaom9Qt
6kdqmynD5DZ5TFfMtea6oKPtvdu/9MFX7tN9O7h2g7iS5nEk1mA9130j5+AIR/Q4I27BPzkL
sWShxxn3QMqhUTSanqUSKqNaWkyv05u0itbT++wB+yDMjD1ZDBcFwiXKRJ1YLF4Vjbz2iE/E
GXFWtDLyKMWqJCupSq5SrExUZrAP1cp8pY4ju1zZrJxQTimXlStKK2ctSvaQs+Q8+Tu5UTbK
ZvVptZLXevWA2qQ2q3fVuyZhijXFm/qappo2mS6YTeb+5nzzr82nzTeDPBRPvRm5hoceEcM9
2ENsFpGyhlr5oDtJdGLPkzkPBdwVNzFM8XFewvx8xtZVxMgu/pumTKnz/Wrai350CDUmofBU
lS3YTudFi/yzGIJPyUkxcqMyQz0iLNjC02iZ+FDspSw0igwxQaxWQJdoEy5xvc9BPU2jmdhC
rTSIXqEBVIPToptSQHXIMNYLSR0ol9rACLBAuvEcfvShgTytr/rWyFD5Ms+n3VjJGd2Kr+g9
3CHVuM7TTeFp5OIps5TrfRH8U28S91kN92MMT5DpphNoJBNP9AGmoXIe2vBvXFX3cEVl8SS9
7KuQa+TXxgAjhTuMuwybuO/KMYI75hJXyT7e+3cl3OnBPEvSuKvzUQw3XuGpt9zQjdXGQmOu
UYW/8N07ZKM7tJY7YjffyMBhXq/hc1rCfTjix/38f4/PjSZco2jqRWncD63qbHWZulltVPer
x0ypHO06rOKKvsDVHMwelKIZ13Cbgjg3MbDhKcabztgLMV0UKfuQTbHwcM8m8RzPuu/JTNZS
y9Fbzf28j3ujjedECfbjLAmKYo9K2X4Q6xnFcf4ZS7/LGVxIO/jEzVO7N75lv8MoXVSzvUzW
tJKnVhNjOo9vONpGAJeN54KdJrCu23gWbrbQH/nUwBnYiYE8We3KUY53TwpHFiXQO3zPyR0a
hu4YqH5NAjZfnpEuKpR9/I0x+Hwtf73iMIReYBSd2I92dKUx6OcbxxhO8Rd4+PjMYUOHZAwe
NDB9QL+nnkxLfaJvnxRbcu+fJD2e2KunNcGiPdaje3xcbEx0VLeukV0iOod3CgsN6RjcIchs
UqUiCDaHNcep6YlOXSZaR45M8e+tLj5wPXTg1DU+ynlURtecATHtUclMlpzyP5KZ9yQzH0hS
uJaBjBSb5rBq+jG7VdtNxWMLmX7Vbi3S9NYAPTpALwvQoUxbLHxBc0SX2zWdnJpDz5ld7nU4
7ayuoWNwtjW7LDjFhobgjkx2ZEqPsnoaKGooBQgR5RjUIBAUyqD0WKvdocdY7X4EutLL4XLr
+WMLHfY4i6UoxaZTdql1sg5rlt4pOSCC7IAZ3ZStmwNmtAq/N1iiNdiavEt3h2OyMznEbXW7
Sgp1xVXkt9E5me3a9ah5F6P/u2XlEdmFix/mxileR3SF5t96vYs1vWls4cNci/+3qIh18F3R
K8fpzWHTSzmIowo0tiYWFRXqtIhNan5P/F7d86/M6vCfOKdqegdrlrXcO9XJqYn16hg317I9
NjbzA6MFsQ7NO77QatGHxVmLXPb4hkh4x83dEZOpxTzKSbE1hHe+F9iGsE73iZDQh4myB7wA
FRD3U6PGPYgs+RFZc7kgdK1UYySFVvYp3f9Tlv4f7qs+KKrrip/33n3vrcQmm1qowiQu2UBE
sKiJX2h1kYHaMCGigAs6CeJHI7aVhokTOxNCM20li7TiJypamzQxAdMuxj9WsO1aOzWa0mQm
Ic3YTMZiTVW000y0SSH6+jv3vbcuq9ammf7THX6ce8+5595zz/3dj0ehZdPRDL9KBV7h5ViR
VeERBdUhbx7r2T+sZ3j9vtBlAgP8Fy8M1yx1NEaG9zJxkXkSoxrsbjmcnR0eP54pYhZgTRHj
bFmfMiFnbUSd6q/z+iCQPpqP3C6tzMtF+tPTeYGbIwGqQSXcWBq06z6qSTtAgdzsyrBazZao
a0kuZ0uja4m5V/vB5IPEj/rksCcz9neHN2VU4WN5YSXl35hX2Pbihf7i0qqgrzBU7eS2uGxY
zbZPj9mcUnhUQVBLU52SmqZJK0i5JNaYK8GRYZGBP0OSenlYAymlQvEVhb3V8+z/lUnp6Tf1
iZieOKeI9Xf2kuKamxNlOC97eH3msPqw6EaGNMQrMtXisqpQKGmYrQgHUChU5PcVhapDSyNW
Y43f5/WHDqn71H2husJqd0EjVndzWrhoQyUm8ZiSB7KqNLfLrzSVdgWUpoVVwUNefKk0lQUP
qIpaUD23sute2IKH8BQJSK0a03LNxzUqVkD0A6pHmtIOBYgapVVIhawviygkdR5Xp9CyiGrr
vFKH3wTitTdnXy2hAi8NDl7N9EpN/M8IGY5KneGggyLa61Qn6umLQJF5F1Xqx6hK+SstgW01
UKDdhW+s/VSO9k+gXg+5WZ1hXUH7CuA54H7gISATWAwscrAQyIfPcaADfTzK/Uh5mmrNXvoq
xiJgG7AU2KJX0FbYthszqIb1GGsD+vCjvAP63UYHtaLcBnslt5WS/SvoQdhzUN6sV1iW2UIm
dITyFehTMP4mjhkyE+PXi3rrIsrj0ffXYV8PWQ5Z5sQ7WpZPs4+cK8/xWS4jPw3QtwILgGZg
MfLD/hPhNxb1FpRvQ1wjIEcCtwuie9BmFt6KYcgJGL/AmTfJeWMesTkhfhnTjcE5zY8HYuJ5
nQN6gTfjYktEyzDU41Vxv1w/nvMXgJlqL81FXq7yvPQz1scMD9G7mFcPoOM9OslDVgfinKMf
pDbUJwOzJOpJEe20RruENThI3zW20U+hJ3US8A/KUC9QqpFB05C/IPpfBKxAn0clH5ZzDNYF
yLHiDKWir2qgFmMfd/PEuUF9HtY1iLafooxHLX0fWIUctAGPc3wYP5dzjnX/WKm4+jLansI4
xQyMOVYCc7fXlZ6A/3fQlyLHsdfBlgDstcjpz4FfA0c4BheSZw5kXx2kqR3WR5CjgFSgF2hl
vgHVwF5ug/GT0D5J8hWcYW4yP5gb+jHJ1YUcuz0HuReanT3zLfgvBsYA44z9tMTBOLTl/NQw
Z3m/uH0zt5jXrpScXs28V87zPJlTcXKLHqVSjkGOC265kvcd+l3HEt8lHNNOrY82MmeZb67k
vDDXeD/ynnDk/Li55jh7JAf+d0uug4uudHMRk2/QTvRZYbSCpwNUIk5SCV7CJfo6yE2Y3yHo
MB+BLwotmx72RCkLa/kwfHckyDaG2afUYqwfi07koo92y7z2qfeIPkXXO61zOinH9U61QZav
k4lQoraNJSPe9ln1/w3Ud/ROWonyeb3PsjCfTbwnzAFlIuBzJfQHgEZgvCdbafOsViJmOXnx
yXcJWCMClKcHaJqI0hyRTAHkKQP6cuNr8tzdiP6PKQPUgvX6oZlMfu0czkaMpb6D+wHg/iEf
iuPRMM4lcsmVLl8TJXOGz11IHXIM9l030AOcdPBnoB98/Lbcv7gb+HyW9wPOaKDF5qt1McbP
49QO+SOXnwk8HZ/ATzORl4mS7xY+3+Xdgn2KOFrc+fP5yGccn5F8zvHd57ZPlHH+W3F2/FGe
w71U5ezrLGAikIs+DjvnSI8WsS5hj5413rJ6zDlWj3bC6jF2WC+aq63XjINWO+adFbtTo/ZZ
xvvJvUs5T3wvuveonkkrnfNsp2yL8eU9WiHPATLWYf/VUg36/T3fq7wPtXbsO+QT/T0jXqJv
in7aiNjv0H5h68VCKuEzUaxFGXqc6Wy/Tdso7QvER7RWZKH8EuQuutMwaa3xG/axeqXutG1j
nV5F28G7XPEs/UzvoiCvFc9DnWKd4LXHnk/1NNJuk8DhftopBjHnKOZ4TMpdkk/s+6o1yPMz
Z9KXdQ3z4zYA++i7yefkY5vMRVTmaKvkMHLBfRpvy/cG6e+i/U/oKU8S7fTch/PpMqWaOEvk
WF20yBOQeRfyvv4Q+2MAHCunJv1L1j8l//dbljaIPTSA/cXA005PpjH6AO3CXmqS+bFlM+8f
bYCSmSOYX5l8TwyA4y/Q40YnbTCi4F0f7oI+rNsA5rKapqPcKjqtIbQtRB/EY0NfKt8nfE8F
rDd5v5hRGm0GMD7acAzy/YdxtTOIdzM14SzJ9wzQ84aP3zWKAu7dDUyyIetPAw3ABhtS57Wl
ko4+npL6FfSa2qGp4Dfbj4uXsfd2Ub62j5LESrwfztMzai6t10rAu4u4MzT4oS5yaJx2kYq1
T+T9s15PommyXQru8bM0X1TCP0rLxQFarlkojwa2go/w0yNUpS/DO+sR9ONAnQqfETTfaEY5
19rP7eQYn1gpDLGOJku/OMhYXXDMz8XFvBW5/R74wPGiHB8vxxqL04nxRvHJeXK/8JNt/kT5
RNZ7QIYtr5aqLdQJ7FVP4h0epQZlm9WttFORcgZod/AKzZOyCyilItGgNAHzASEaaA/kBMjz
QB/QDhwG/iam0A/Q9xHIV/m7gKH+CmcXJOwvAL8E3ndt8eCxbqSPh/jA6o6v65NpBkPNwZme
M9wm2++hB8STOIcnWt0MbS0lMYzbKcv0UJbaD30F/BLq+jjaLtag3S3iuRWUN2iizKGNQPwc
3fWATPkP8F6c9LHE/prA9/PnjfGzAuv7NPANmf+99BXJobN4k5vWUeUwPaKcsgZxnhsMu06p
Mp976E53naBvkvqE9QNXpmoLSEvUozyL4dYT1/VWdfS7Kh4uD1yYkynAEO+jPZBYx30QYBjM
sZzr67Fxb4YyegB5KhJliKX/+rrhpVyGWod6G+wf0H2MWL2MshjcloHc+hnIdTdD7ad0hrYA
tgWy/WxGXF6DnFctyr7SX66Py/PE9YEvid/iPPoL3sxllJooY/x2zothnC+1+R6r81lyJqHN
tT1xbW9gr9ysz/8nYO+cAI4Bv/ufjgOeKwSuAl7Cm+4tvDfCeKs+j2/M16mF6EoT0dARok8f
xTk0CfIV6MpRzoT8EBgN3SpI3EZDp1Cug+1toBfYK9LoSeddOQb1Qtv3yotOfxm2P/sN4rUz
NNX2H1oP7EL5DwBYNnQUcgvkZbT/F+3lG9vkccfx+2P8PEmT2IRgXEK4pwmOiUMazw0zDCl5
HCjVmk1xIUXJGKpH20nbtGKNpGzQkpQpEgkldVdNWtep8SYtQmI0Tx6X1FnC4q6rhFoxvE7V
YNI0v2AvplHBi7JpEp33vbPNkClN022Jvve9e5773HPP3eO731ngBuBHce0YvAPlKLQT5d+h
3Akx5L8A/RVCP28ijLnZDv5V6GkZj3zMOfR/63c5f3xaRx+/Ce1TMSf6W36G+NRems8lvPys
UZr/pbx0lrjDi+OAmO8dqdvOPp94xik55vOfRX0IXXOM5T9CTKmpOBqxrIq5ZfxYdBVvv6/i
SapiyqJjPGU/qmTsLONX+E/UOe8i+nOQfAn92qP6VdpHbltb2SbyJOQpCuse2Y4676E/1+kp
4qKn8jcQWyak5N6m9jEI++67cBfW3EW6kL8Bv4ByA/ayitKeVlpb71hj79zT/q/l5e6Rn2FP
7S3qG2UqXf96UeX324tqlCrfi5erpfbuz7yX32WPvn2f/m/LpX2+pKXi0vI4YKnyUu0tt1we
d9xWnpH6hPuqXB6XlMrluuP+nd9eIZ5Zi99bSWW/u+UKv9Nux4H85dLvtdSH8t/xrd9b6Yww
THZAD5Yc68dGrCMt0PPFc1cT8tgD84fl/qbfJCH9DAmhfBaalWsOfKCw9+Wfp68jlv4HAnvy
r1GUNccFVbe/qIGlvufy71bG5yo+xJipvicwFx+SdmgbVAvNQN++Ndc4Q+LZ5zl2XnnO5Vfy
N9DWjbvFgndznPO+I897KLtQdv2K9PEfY+mkROQz/Ecpd13ITPOXU65VITPi5j8kUYgRi3+Z
ZCBGDvAXyTDEUL3HbvtcaE5mUpU1ITfqnyAGNAJxkkRKVdmEZP0TqVUe2fz3bddKxR2xgx2F
TMrtDUUjdfy7hPIn+VOkiQh+FL4e/ji8Ab6fP0GqVT/NlMsdGsHzulC9i68mLbgd4R7MieA7
8N3Vq2pDdk3hOUP2xkAoUsm3c6+q4uLVpAOuc80OCWOem+ipyY+nKu6R/Ttuu1eHzvFRrpE6
1BpBrTXCdY5XknZIvklfqqI6lIhU8T68Zh+GRaCPlEyq1ORP2WgIz3uQryMe3PsWbyCr4Tv5
enu1yMzzl1S1H8hW8LxOW39AWqq6JpSJVPBO3LX4BEZ8Qj0tkWreEiKRZr6RBCGGQR1Gbhg5
Nx9HbhzTNI6pGcfUjKMX44g1CR/DnTHUaeeHSZwfIgloEnkHmlxtYwTnVGbDxtAcv5d7MRLu
eYwdxdW1qYoa2TOvXbtKVfOmqmpCXef4QdILMXR+MLXGGzowzwPqVTalvPUSiNsVVRi6NYW5
AOiRc3COr+Pr1Ug0qBGwIgJlSlxcEMreYVk5Ouz37H05v+wiytLfLfqFov+24PkMy6bwFDPN
3pOei6xjf0Fjj7E/kUnkGJtnb5EggD+ytOwFu8zmSBf8EspPwOfgD8B/ad93XqRZOgVD31+x
qz3yZdlbdmt7MSN8xcya+mKm1hOK+Niv2ZtkHZr4A3wD/E2WIY3wRbgXnmGD5Dz8LNtMtsFf
L/pv2IL8ptkbbJZsgafsGtkFy9akTdtOaa/ZpFCKtosF9ho7Tdai6hm7eS2unko1bxCuebRH
2c/ZoN0gaiOV7Ke0H8uFYElySTqpZT+zw7KRhL1giDmWYAnTGzZ9Zps5xYO+YFtwihs+o80I
G1NGxM0myAoMHn6w7ATSMDEYvh7IhBJszHaErchHeCf5XoyMIE2qXAxpXOUIUvetu9dVrouN
IuQYRS7BjkLD0Aj0HHEgPQwdgZ6BnlVXBqEh6BCWjziIOIg4iLgi4iDiIOIg4oqIq6cPQZKI
gYiBiIGIKSIGIgYiBiKmCNnfGIiYIqIgoiCiIKKKiIKIgoiCiCoiCiIKIqoIE4QJwgRhKsIE
YYIwQZiKMEGYIExFBEEEQQRBBBURBBEEEQQRVEQQRBBEUBEGCAOEAcJQhAHCAGGAMBRhgDBA
GIpwg3CDcINwK8INwg3CDcKtCLeanyFIEjkQORA5EDlF5EDkQORA5BSRA5EDkWOHZng28jaQ
LJAskKxCskCyQLJAsgrJAskCyRZffVANBsNncxQahkYgyWbAZsBmwGYUm1Gf1xAkWQuEBcIC
YSnCAmGBsEBYirBAWCAsRSRBJEEkQSQVkQSRBJEEkVREUn24Q5Aklv9RLntq2HO0X8fmykZo
i/JhclX5UXJJ+bNkRvkzZEr5EXJM+WESVn6INCtHe8oHidCpLcKuiAdLQC/0GHQAmoSmoUVI
U7mL0J+hPNtsNjpcWq82qU1ri9qKaS2nMZez1znpnHYuOldMO3NOZkTqWbVaR7G0kBdUOoz0
GoRNBGmXynWxDjy3A+vsZvx3sA5z5QfGtQC9GKCLATodoC8EaKSCPUQdaqUzSJih47TfrGru
FJegcLO/EyvTxOzVNcJu/rxI04WCtZit8KvQDDQFHYPCUAhqg3yQUNcCqN9vNhabXID80H2Q
IR9BPB7EarUrdXOOVdOp1NvVpEI+x78R3LztD8LStr8X9obt3y8iFXSW+GUYRM9i5k7Dp21x
BbfPFOwXtpiHnbJFB2yf7b8fttf2XxCRavooEQ6J9hV9N95b+i5b7EG1R2zRAmu1/c2ydgAP
8uFuC+0nV+C+IrWh8KQmW2yDNdpiq6ytE7+ceOokbap7KyDpPIUOXZuj/Q5q3iM+EC+Jq8D/
hoHF53HZSDtgF31pusesFAttr6JyRNiRSlkf+8NM0S3pZ8WUb0y8graob1a8LO4XE21pHZdP
ot9j6hG2OGak2WlzlRgRQTHYdkUcFA+Lr4ldYp8P123xVbEgu0kGaD87PSuiaPCLeAufLR7y
pVUXd4rvCVP4xVZjQY4v2VJoN9y2IEeAhApP34TxDfjS8ht/NJymK82Adl1LaHu1bm2b1qQ1
auu1Bq1Or9Xdeo1epVfquu7UHTrTiV6XzufMVoLPtg7HOZjTIVOHyruZTJEgJYzqjDxMrFW8
h/Xs7qY9VuZx0rPfsP6+uylNKx/5irWiqZtatT2kp6/b2tLak9byu6xwa4+lRff2z1A6MYCr
FjuepqSvP03z8tJovVW7HTfJ6Mn6OULpvaMnBwaI1/N0l7ertnPl1p07PiaJFdPW//x5/016
tQa1cV3he1er1QO9hR6rB0iWtIuy5iEQkh2UaMEStY3xI2Cqta0aJwXD9AcQIJ78CHHb1I7H
bceJPbbzqknGxW7SmQiIHWDixmNPneZHJp3MtHWbzrhN3WIn1UxmyuBkikTPXYHjTvnXFXfP
3XO+e87l3O+e3ftg15s73daRyb3plXL1pLPsldpy3+/w7cvMUkZKn07NUgYipMwsPUgZ048R
PT2YkgB2W4YBmw0AQzwRAFO3IB+BQT1pITBYoxKOg+GA8xMBOK0ecTKO0+plHI0JbvKmL52a
9PlkDByjbsqYmyH0AAYYA2NTkxwnowI+nCEonAn45ImFZUeVlQCprpQhGL7rZEeVWA6Wq/0G
ElqBNN6HNMqxFPgbTGUJU161iimvAozwf149LQKejoyOXU/3BNLdgXQPtO7c8af6nLnDj/t8
k2OjxODLKbjux5/oI/JAT2400JPKjQVSvsnI9TXM14k5EkhNouvpzszkdbEnNRURI+nAgZQ0
nUxkmv8r1rH7sTKJNZwliLMMiZVsXsPcTMxJEquZxGomsZJiUo6V7ie835mZVKMWadO+kpym
yrTA4W63X2qxmwYfJYSebfI7x9xzNMIXUZkg5XSBlpweGjFVN1c3ExPsM2IygNq4YnKONfnd
c/jiiskEanOgBa2mFhFQW65xV1vO37EnQ6iSEw+svWbD5JLNTpTuT8EfPI/IDX4PItHwmtfI
Wtfo6OgwuY0Kwwi15R7qaMvFdsFMVCoI1Z2SQFezqlMoZN2kRpOeWb4KRgEmgUdIONITsAAZ
FLVw6lJR48y4iiJHhZFpl7d+4Aq8wZ+FBuc46tBUbUQ+RRyaXhci55eR6drGkoTzKZFTLn89
RJiOw1AiQyUpmquhcyJ0ovpEfDw0Xj0eZ0B7eQKUlRPkVTpVO6FAI8LwaiKgOyJBsmFaJN7r
Ux6vHHicdARBEoaxnK//TTZeTfr9xA6veB2W3Y+sLkhJP4xK4JJRGF0dNLoyRDaOykPkgFB6
oQQr4QdfUyrU8g6Fi4xqhkqKVqSkiwqkVdFFjFg1oyxSivcwhzQ4h53IKZgWE4XEdtNCor2Q
QEnom5bgFqnzm/3mENyg0KMln+LqkqhE/0Y++iqp9Cfh9kvMQqygaKM2IC3FGeFd44PjIY1Y
+uBTTgFcZtsLKNmej9Q1gK+TmMVscR5mij6E0Z/RnDzTGtGt2IAZZgOt1bytoCiGwz5lnZJS
vq3+6C0yuyyZUmIRJfNJ8GQFTxjah8QXZhV6Ipf+tep5y/IduoZ+FAXgtTck9qlcao/Sa3dt
dW/2bAl9arpl1sTYVvbbXC97kDvCvciedE24Zt0fuH7j1jGM3mZnWDvPhG0Se4g6Qk0wl5gb
jO796B9NlDdYHzGv1wdFoSYaFNdVwY31RgeCS0Eq2OolVKozGKOPeDHymrw579de2utdjxuQ
CFqSGQrt9osec9Ivuk1wc7qifqDlJVql02vXE0aCTZZgliUg1gNCFMvLKiKcOqyp0kuVunM6
qlKHl3VYJxrsUZ1rRxRHu2E9flqHMW4I+/c78C0H3uHY7xhwKBxsQ39zaSGGnmzPLwzls9tN
2UWh9HSbLHceuJNMJAsgFrLCbcvG2uyQMMlQmzozU7VePCTlSw+zKLh89V23N9oZ/G6QygpS
FkaYLRsVBlMiAWTBQ1mUHcJ8LNZQb7fbFOV2h5/jOZ5hAuu4xmgsFo/FG6NcYB0DS61ibOX2
hnpQxRpxz7LwycfvzbQp3KHi52UmlWLz+ez5K12vvPjrbTsH2jrxd2KfB+OZ1LZ0g6mM+qzm
5VPSsXeLMz/+0TZPnFW3tk49v+cnbZ6Qz7Mr3VT8xFLv5BNNXfVcPNgDKT8KbDilnENG5EGv
zSLL8ldipGxj3P0tN2XpYrq0XfYup+S5p2Ia6SZ9k7XRnabb9G3WtPuU6iWNVmfAsKlcpHoo
VeVkLaxlZUakdfjVrsEKXGEKUwrOSL6udXgQHYZ4rDdZyvdQoj1fSPxju2losT0Pm4pwNwlp
QkNZnN2UEct6mV5tr73X2e9RZiWUFcgGgdRZzCYECeNt1nIHZChWStlRzP5g6lqxWJjdOyla
oluezv7wuYM9R5RzhS9PFeeLXxe/LP5pr/Qq9dDPdwyee+vy66+RHbob/vck7AQW/VXclTFK
FsneZ+y39NufcT7NnqHO6G6Ybjj/YPq98y5zV33Xetf2FWPdYN1g22rZam91Srp+nephS9we
dyoOKQ8ZjyqPGI+xFy0X7LOWy3aNQWaoO0rkJUt51NCgJxq2IipLozmqn4NjihZyZjGXIRGg
SAQcajgBPJ2D72waTD6HChMt9qNaPeno/TsM2OByq/zlrCtTSmV7fjvUgPa8sJAXULKwkL0N
jC0sCAJISCiQDnKq5EieZFbF4kpCOgSZBCrSkeIXhid29D/z7Pd29tpwubDw0d3iF9iev/Z3
6p/1HZ0vvHnl1b0Dtb+6hjlMYxUOXSC5G0OIOQu543HTLArD3s6atUlwq7Mxdl1UEVVHndFA
ikqr085UQOdT1IY7NN3hw+Fz4fPMBdWE7hJzSZcL/zb8l7ABhWvDO8HwfvhWmAmLLk80Cc+H
ZaNS5adVLq+dMEyrIvVArKBVJrOZd3s8HK+FD22jibOYxT2N3WY8AHVvhmoVjS435/WAbsCD
uz3YA7p3QhzHY2DiFEK8vACaJJFiDObNA5QXm6EloAX5KC8+/Ei0lv+Yv8UrjHwlf5hXIN7H
1/HLPM2zVX9LrJaMlVdOot2UNxUSi1AZoBQvDmWJIKROQF0mP8JuDMUAQYNS8KRAigEWrH4b
qQYOuSY47DageJQn68TIXW61O4YVx6/2nq5rfWPf6BtV3uK8l9/V1FdTnK9Ixpr7qovzNPfC
Lzp37+7cvy91tiBR+39Wk9h8/HSRolpf2bO+9bmXCkuw9x4Dvr8Ma6YHxp8RN9/B8+p71ns2
+gPqjpKysEpWQ0mmLmuXXXKeoc4yZ9VndDOa31GfKv+s+Q+7ZfDaRBCF8W92J5MpxpikG6sN
gobqpUUP7UUJaFLbGg8iBY+ioTUlEBMt9D9oDw09iNCeioiXLj23B88FpbTXXjx4KVgPolQQ
odiNbzbbVL2kgQoK7y2/zDcvMxn2ffvYbEV2Qjvq48nYkt6wNtWafhMJTelZNa3tuO/NiS7j
jSPDztVw98PUk5SVil7Ab49oo9H9V5Tf5E+pyztKsWKieLp0RgrT5OJ+50CCaoGkQ03ec+mi
c9jio7X9xV0x4K1/eu59r4nzC5XK/HylsmCl54SqeW+/7Hpr03X3heu+XHRdNKN8DCy3h5D/
LnYCkFH6H3T7aCivQfgzwzAMwzAMwzAMwzAMwzAMwzDM/wUsCJhwYBslugmFNiP+iz53tC03
h4ab+i5G2z3xr4fELfqMQFOFJC7jGsbwGNV6nbJmVmjM6tsHV1DHw7BbnqFRDHbZfglFcHKc
roZWpNLGGdlBmTT6A20hinuBtik/FmhJeibQivTSSD6XHcz3ZidLhXJfrloeb53ACPLIIYtB
GntpnESJbreMPspWaRwnux5hAlOkC/Rt6/XHscJURNXwFRlKKKpADFeoBlB3yBOb5nTz4hlC
0JKUmR2MKFoJ2t6MP224ToEb5GrVmI1NnZRW4Ib1YeL9Ss+7B6cy3/RZ7a9+tZ3xH/HXW6ud
e3s/9mPQSZoaf/xf/inAAPV6OjoKZW5kc3RyZWFtDWVuZG9iag0xNzEgMCBvYmoNPDwgL0xl
bmd0aCA2NyA+PiANc3RyZWFtDQpsXoskAFJzaLCwu/+utv+ttf+stf+xuf+ktOk6PlUAAABv
eaG2v/+ttv+vuf9udaEMCREtMUSttP6ut/+QlcWEiIMKZW5kc3RyZWFtDWVuZG9iag0xNzIg
MCBvYmoNPDwgL0xlbmd0aCA1NSA+PiANc3RyZWFtDQqyttypsv2ttf+yu/+OltIICQwAAAAE
AwhLVHSaqOaut/+utv+yuv9KUXMiJjGDirq3xP+rs/8KZW5kc3RyZWFtDWVuZG9iag0xNzMg
MCBvYmoNPDwgL0xlbmd0aCA1OCA+PiANc3RyZWFtDQqmqdOmrPyutv+ttf+ttP+xuv+xvv+I
l8g6P1YNCxKCicGzvP+vt/+rtvYwNEcAAABmb5W0vf+rs/8KZW5kc3RyZWFtDWVuZG9iag0x
NzQgMCBvYmoNPDwgL0xlbmd0aCA0MyA+PiANc3RyZWFtDQqZoeOwuP+ttf+zu/+iquhHS2Zx
eaavu/+utf+qtfu0vf6xuf+stP+psf8KZW5kc3RyZWFtDWVuZG9iag0xNzUgMCBvYmoNPDwg
L0xlbmd0aCA1OCA+PiANc3RyZWFtDQrJ1uSlsvettf+wuP+hqfEoKz9CRmB+ir6tu/mxu/+t
tP+6yP9teJ8AAAIAAAATExyKkcy0vP+kr/cKZW5kc3RyZWFtDWVuZG9iag0xNzYgMCBvYmoN
PDwgL0xlbmd0aCA2NCA+PiANc3RyZWFtDQqZlLOYneuvuP+ttf+stP+zvv+ls+96ibNARFoR
DRcAAAAeICumr/SwuP+0vP9pb5wCAgQNDhaIlceyuv+rsP4KZW5kc3RyZWFtDWVuZG9iag0x
NzcgMCBvYmoNPDwgL0xlbmd0aCA2NyA+PiANc3RyZWFtDQrKy+Wnr/mttf+yuv+Zot0LDBEA
AAABBAYtM0xocKGYoOSvt/+utf+zvf9ARl8CAwVVWncrKT5bYoG1wf6utv+nr/0KZW5kc3Ry
ZWFtDWVuZG9iag0xNzggMCBvYmoNPDwgL0xlbmd0aCA1NSA+PiANc3RyZWFtDQqwtdWiqPmu
tv+ttf+ttv+2wv+ntfV0g6tudqixuf9mb5UDBggAAAAREhyOncq3w/+stP+rsv8KZW5kc3Ry
ZWFtDWVuZG9iag0xNzkgMCBvYmoNPDwgL0xlbmd0aCA3NiA+PiANc3RyZWFtDQq8xtinsfet
tf+utv+zvP9KU3AAAAAEAwYnKjlZYYaBicOZpuars/6yuv+DjMdXX4alrPWvt/+yvP+Pmc4m
IjcGBwxcZIa0vPior/wKZW5kc3RyZWFtDWVuZG9iag0xODAgMCBvYmoNPDwgL0xlbmd0aCAy
NSA+PiANc3RyZWFtDQq7xOGkq/uutv+ttf+stP+xvP+2wf+rs/8KZW5kc3RyZWFtDWVuZG9i
ag0xODEgMCBvYmoNPDwgL0xlbmd0aCA2NyA+PiANc3RyZWFtDQrE0emnsfuttf+0vP+EisEE
BAgAAAAQDBZHTGyOltiyvf+wuf+ttP+0vf9GSWdsdp26yP9DS2UJCQ6BirK1vv+osP0KZW5k
c3RyZWFtDWVuZG9iag0xODIgMCBvYmoNPDwgL0xlbmd0aCA1OCA+PiANc3RyZWFtDQqtvOSr
sv+utv+2vv9YXIUAAAATFyFeZ5CfrOqzvv+vuP+stf+ttf+ttP+2wP+Cj7sJCQ48QFmwuf8K
ZW5kc3RyZWFtDWVuZG9iag0xODMgMCBvYmoNPDwgL0xlbmd0aCAyOCA+PiANc3RyZWFtDQq7
vfGosP6ttf+ttP+vuP+2wv+zvP+stP+rtP8KZW5kc3RyZWFtDWVuZG9iag0xODQgMCBvYmoN
PDwgL0xlbmd0aCAzMSA+PiANc3RyZWFtDQq0veSpsP+ttf+stP+0vv+WoNJkb5ijrfOvtv+s
s/8KZW5kc3RyZWFtDWVuZG9iag0xODUgMCBvYmoNPDwgL0xlbmd0aCA0MCA+PiANc3RyZWFt
DQq1xt+ps/umrvWfquittv+ttf+utv+ut/9dZooBAQMpLj+eqeastf4KZW5kc3RyZWFtDWVu
ZG9iag0xODYgMCBvYmoNPDwgL0xlbmd0aCA2NyA+PiANc3RyZWFtDQpsWYY8IHeosfqut/+t
tf+xuf97g7cMCw8AAAAOEBaWnt2yuv+stf+3v/+QmdMQEhoKCw+LlM+zu/+ttv+ss/6UlaoK
ZW5kc3RyZWFtDWVuZG9iag0xODcgMCBvYmoNPDwgL0xlbmd0aCAxNiA+PiANc3RyZWFtDQq3
xeiqs/6ttf+stf+vt/8KZW5kc3RyZWFtDWVuZG9iag0xODggMCBvYmoNPDwgL0xlbmd0aCA2
NCA+PiANc3RyZWFtDQqEd5gvDWWhpu2wuf+ttf+vt/+mr/A7PVgAAAATGSGdpeixuf+yuf+o
s/VHUGwEAwctMkmqs/6utv+rsvyYmKcKZW5kc3RyZWFtDWVuZG9iag0xODkgMCBvYmoNPDwg
L0xlbmd0aCAxNiA+PiANc3RyZWFtDQrE2OOosfOttf+ttv+crOgKZW5kc3RyZWFtDWVuZG9i
ag0xOTAgMCBvYmoNPDwgL0xlbmd0aCA3MyA+PiANc3RyZWFtDQqzv+qqsv+ttf+utf+osPqN
ltGwuPyyuv+ptO8pLDwAAAAWGCKVnuGzuv+GkckHCw0DAwU8QVeJksyuuP60vP+vt/+ttP+s
s/8KZW5kc3RyZWFtDWVuZG9iag0xOTEgMCBvYmoNPDwgL0xlbmd0aCA2NCA+PiANc3RyZWFt
DQptXot6csazvf+ttf+vuP+dqOpWYoESFB0AAAAqLT6osPivt/+zu/+VoNkXGSEpLUItMEVu
dqS1vv+utv+iqOcKZW5kc3RyZWFtDWVuZG9iag0xOTIgMCBvYmoNPDwgL0xlbmd0aCA3OSA+
PiANc3RyZWFtDQqGgaqZnuqwuP+ttf+vt/+4xv+XpNtXX4IjKTkEBQkAAABgZoy0vf+ttP+y
u/+tt/hIS2cLDhR9hrG2wP+0vv99h7VITm6osPmut/+qsfsKZW5kc3RyZWFtDWVuZG9iag0x
OTMgMCBvYmoNPDwgL0xlbmd0aCA1MiA+PiANc3RyZWFtDQqaouawuP+ttf+ttv+1vf9eY4gA
AAACAwR7hq21vv+wt/+eqepDTWiIkMG1vP+zu/+qsf8KZW5kc3RyZWFtDWVuZG9iag0xOTQg
MCBvYmoNPDwgL0xlbmd0aCA1MiA+PiANc3RyZWFtDQq9yOiosP2ttf+wuP+gqOwcHikAAAAz
Ok6lsPSvt/+utf+stP4sLUIUFR2VndWzu/+rs/8KZW5kc3RyZWFtDWVuZG9iag0xOTUgMCBv
YmoNPDwgL0xlbmd0aCA1MiA+PiANc3RyZWFtDQqhsdattv+ttf+wuP+vt/+zu/+hqeklJjUA
AAAqLT+mr/OqsvwhJzUeJDNeZ4qVndu0vP8KZW5kc3RyZWFtDWVuZG9iag0xOTYgMCBvYmoN
PDwgL0xlbmd0aCA3OSA+PiANc3RyZWFtDQp/dJZrWrO1wP+ttf+stP+yvf+3xP+hq+hsdJwq
LUQFAggAAAAgJjKqs/Svt/+0vv+tufg0NkxBR2S7yv+lsvAxM0sZGiWosPSutv+kreAKZW5k
c3RyZWFtDWVuZG9iag0xOTcgMCBvYmoNPDwgL0xlbmd0aCAyOCA+PiANc3RyZWFtDQq4xt+o
s/uttf+xu/+lsexseKOqs/uwt/+Zo+MKZW5kc3RyZWFtDWVuZG9iag0xOTggMCBvYmoNPDwg
L0xlbmd0aCAyMDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAwAA//6mm
sS4KWTkYZEknclI4eFo8gmlPi29WkHtinINtpI52q5qDs56UuqiXwbenzsGw1cq82dXN4uDX
7uri8vLu+vHv+e3p9eTf7N7a59zV5dDO2MzJ1MO8y727xrevv6+nt6uls6WfrZ+WqJaOno6K
moaCkoR7jH52h3NvfmtjdWpicWJZaVhRY1NKXkhFVUJAUUA4STExQzAtPSokNCUbMBsUJhcW
JhAIGA8GFhgRIisqNT83Qk5GVF9bY3Bwb4KCgQIMAOuhYQYKZW5kc3RyZWFtDWVuZG9iag0x
OTkgMCBvYmoNPDwgL0xlbmd0aCA1NSA+PiANc3RyZWFtDQpsXIovCmOUk9+xu/+ttf+2v/9d
YIoAAAA3PlGtuP6utv+/yv9GSWFhaJG0vP+ut/+jq+uLjJMKZW5kc3RyZWFtDWVuZG9iag0y
MDAgMCBvYmoNPDwgL0xlbmd0aCA2NCA+PiANc3RyZWFtDQqHe5sXAEt0arm0wP+ttf+utv+q
tP9iaZEDAAIAAABcYoi2vv+vt/+6wv9/iL4LDRN1fq+1vv+vuP+eotWQj4wKZW5kc3RyZWFt
DWVuZG9iag0yMDEgMCBvYmoNPDwgL0xlbmd0aCA2NyA+PiANc3RyZWFtDQp9c5NGL4ivuP+u
tv+ttf+utf+rtf1+i7xETmcREhoAAABcYoi2vv+xuf+rtvg3PE87QV0zNk51fq+1vv+stP+a
nscKZW5kc3RyZWFtDWVuZG9iag0yMDIgMCBvYmoNPDwgL0xlbmd0aCA1NSA+PiANc3RyZWFt
DQpsV4VjVKSzvv+ttf+yu/+BiL0MChIAAABfZ5C1vv+1vf+Ai7wRExw3PFattv+utv+ut/+g
o9EKZW5kc3RyZWFtDWVuZG9iag0yMDMgMCBvYmoNPDwgL0xlbmd0aCA3MyA+PiANc3RyZWFt
DQqDe5wcAFA3FWGGhMqxvP+ttf+stP+2wf+WqNc2OU8AAABPWXW4wv+vt/+lsvVZXYAKBw8E
BQeGjsi0vP+wuP+Xnd19gIORk40KZW5kc3RyZWFtDWVuZG9iag0yMDQgMCBvYmoNPDwgL0xl
bmd0aCAxMjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAbACT/4h7nBwA
UTcWYUEgak4ueEwtd3Zqra24/662/7XB/zE4RgAAAElLabbE/rK8/6y0/621/661/624/KWw
9bC3/7O7/7W9/6+3/IeQxk5UdBQWIExQbbS8/622/2ltkT46QlpaWWdnaHR3e5OSkgIMABmi
Os8KZW5kc3RyZWFtDWVuZG9iag0yMDUgMCBvYmoNPDwgL0xlbmd0aCAxMDUgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAWgCl/3FejCkDWj0aZGJNlamx+q+3/621/661
/7C6/2VslAABAQAAAF9miJym4hseKW5zprW9/6y1/7O7/6u29m51nyoqOwACASkuPqaw9q62
/6qy/XFxkmdmZ4iHiQIMAAYlLg0KZW5kc3RyZWFtDWVuZG9iag0yMDYgMCBvYmoNPDwgL0xl
bmd0aCA2NCA+PiANc3RyZWFtDQpxYIwoBVZJLXehpvCwuf+ttf+lsOsnKzkAAAAWGSKeqOqx
uf+yvP9kbZQCAwSFjca0vP+vtv+nsPdyeoeGhoQKZW5kc3RyZWFtDWVuZG9iag0yMDcgMCBv
YmoNPDwgL0xlbmd0aCA5OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBU
AKv/iHycGwBRNA9iQyBpfXO9sLv/rbX/rrf/ucb/c3uoBgcMAAAAFBwmJCk7TlBtt7//sLj/
mKHlT1h4HB8rBgcJjJXPs7v/sLn/jJfJaWlpc3Z2jY2LAgwAWt0n9QplbmRzdHJlYW0NZW5k
b2JqDTIwOCAwIG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCnlsmpGO4LG6/621/6y1
/662/7jF/5+p5FdegQ8OGQAAAAoOEY6WzbO7/665+S8xRA8QGZ6r3Jyn3xUWIgsMEZad26mx
9AplbmRzdHJlYW0NZW5kb2JqDTIwOSAwIG9iag08PCAvTGVuZ3RoIDI4ID4+IA1zdHJlYW0N
Cr/A7KSr+662/621/6y0/7G8/7fE/7W//6qz/wplbmRzdHJlYW0NZW5kb2JqDTIxMCAwIG9i
ag08PCAvTGVuZ3RoIDQwID4+IA1zdHJlYW0NCp6l6q+3/621/662/7G5/2NpjnF5prC6/6y1
/rC6/LK5/6y1/6qy/wplbmRzdHJlYW0NZW5kb2JqDTIxMSAwIG9iag08PCAvTGVuZ3RoIDQ2
ID4+IA1zdHJlYW0NCqSy4K21/7C4/620/7S8/5GX0RESGQAAAAMDBX6FuVVdgi82S4SMwK62
/rO6/wplbmRzdHJlYW0NZW5kb2JqDTIxMiAwIG9iag08PCAvTGVuZ3RoIDUyID4+IA1zdHJl
YW0NCpSd3rG4/621/7a+/46WzhESGQAAAFFadbbE/7O9/2Vxm0BIYY+XyrG5/7e//6y0/6iw
/QplbmRzdHJlYW0NZW5kb2JqDTIxMyAwIG9iag08PCAvTGVuZ3RoIDIyID4+IA1zdHJlYW0N
CrjA6Kiv/q21/6y0/7C6/7O+/6yz/wplbmRzdHJlYW0NZW5kb2JqDTIxNCAwIG9iag08PCAv
TGVuZ3RoIDYxID4+IA1zdHJlYW0NCpyaw6Sq+K63/621/622/7G8/o2dzkVLYwoHDgAAAB4g
LKev9bC4/6+3/6iw+DM2TQgJDoaRxbO7/6yy/wplbmRzdHJlYW0NZW5kb2JqDTIxNSAwIG9i
ag08PCAvTGVuZ3RoIDk5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAFQA
q/+HfqB+f8qyu/+ttf+utv+3w/+xwPqHkMVTW3stNUgPEBoAAAEAAAABAAF0fau0vf+4xf+W
n9swMkQCBgdRV3ezwfq0vv+lse47QVhaYIqzu/+nrfICDABX4CvGCmVuZHN0cmVhbQ1lbmRv
YmoNMjE2IDAgb2JqDTw8IC9MZW5ndGggNjQgPj4gDXN0cmVhbQ0KpabHn6P1rrf/rbX/rLT/
s77/sb3/labaW2aJKCc4AgACdnyvtL3/ucT/Z3CVAAABAAAADg8YipfHtb3/qbL/CmVuZHN0
cmVhbQ1lbmRvYmoNMjE3IDAgb2JqDTw8IC9MZW5ndGggMzEgPj4gDXN0cmVhbQ0Kt8Dcpav8
rrb/rbX/ucX/jJPFVmGClqLir7f/rLP/CmVuZHN0cmVhbQ1lbmRvYmoNMjE4IDAgb2JqDTw8
IC9MZW5ndGggNTUgPj4gDXN0cmVhbQ0KrrTfqK7+rbb/rbX/rLT/sbv/r739e4q3f4jAsbn/
srr/k5zXGBwlAAAARk5ntcL/rrX/rLP/CmVuZHN0cmVhbQ1lbmRvYmoNMjE5IDAgb2JqDTw8
IC9MZW5ndGggMTAyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAFcAqP9x
X4wnAFo/HWhQLnlZPYJ5dbewuv+bpOQcHyoAAAAuMkSsuPKxuf+ttf+stf+vt/+1vf+cpORX
X4QMDBQaGySlrfCwuP+uuP9jaJM3MkNTTllraHCHh4gCDAAWzCsPCmVuZHN0cmVhbQ1lbmRv
YmoNMjIwIDAgb2JqDTw8IC9MZW5ndGggMjEwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJAMMAPP+He6QiAFQ3EmRBIWpNK3ZWOYBbRIVpUIt2XZZ/Z6CIc6mTeq2birep
lsGxoMq8q87HutjSyt7d1ejl4PLx6/v18P3v7ffp5PHg3unb1eTWzd7Qz9jIwdC/vci6tcO1
rb2tp7elnq+jmqualqOOipqKhJSEfo9+dYZ5dIJtaHlrY3NmXW5dVWZVTWFPSFlCQ1JDPU03
NEUxMEAtKDgkIDIgGS0XEiMRCBgIAw8SDx8iIC82MDtHQklXWlpoZml0eHuQj48CDABstmHD
CmVuZHN0cmVhbQ1lbmRvYmoNMjIxIDAgb2JqDTw8IC9MZW5ndGggMTYyIC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJMAbP9tXosnA1dAH2lOLHdbPYNoT45yWZaEa6KS
fa2ijbyrm767rsrHvdfSy+Pf1uvu5vb18P3s5vTk3ezZ0eLPzNjHv9K9t8i1rLyup7aloq6a
lKOSjJyLhZaFe415dYJuanplX3BbWGpSS15FR1ZBPlA2MkUyLjsnIDMcFysUDyAPBxYVDR0n
Hi4+NkJVT1hua3KHh4gCDAAUY0lcCmVuZHN0cmVhbQ1lbmRvYmoNMjIyIDAgb2JqDTw8IC9M
ZW5ndGggMTYyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJMAbP9wXosm
A1dAH2lQLnlaPoVpUY53XpmEbKOReKqciretnMa5qdHGttbSyuDh2e7w6Pj08Pzs6fPk3+zZ
1OXQztnIxNG+uce3r8CxqbmjoKublKWSi5uJhJWDfI17coVvanlqYnJdV2hVTWFKRlZDPEw4
NUYvLDwnHjEfGC4VESIPBxYUDB0nIzE9OEVTT1praHCHh4gCDAAqjkmlCmVuZHN0cmVhbQ1l
bmRvYmoNMjIzIDAgb2JqDTw8IC9MZW5ndGggMjEwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJAMMAPP+He5sgAFU5F2NFJG5OL3ZWPXxbQYVpUIt2XZZ/Z6CIcqiTgbCb
jbiplcGxoMq8q87HutfSyuLd1efm4PHu6/j28P7x7fno5PDg3unb1eTWzd7Qz9jIwdC/vci6
tcO1rb2tp7elnq+jmquakqOSipqKhJSEfo9+dYZ5dIJtaHlrY3NmXW5dVWZVTV1PSFhCQ1JD
PU03NEUxL0AsKjooIzUgGCwZFSYUDh8HAg8SDBwjHi4zLT9GQkpXXVZoZmh0d3uPko4CDAB7
+GHmCmVuZHN0cmVhbQ1lbmRvYmoNMjI0IDAgb2JqDTw8IC9MZW5ndGggMTYyIC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJMAbP97apgmAlZCIWtPLXhaPYNsU453XpmE
a6ORfKycibWrmsO8rNDHt9fSyePh2evu6Pj28f7s5/Tk3+zc2OXQztjIxNG9ucm0tMCrqram
oa6clqWUjp6JgpODeox7coVvanlqYnJfV2hVTV1KRlZCP08/OEkwLj4pIzIhGSoXFigQCBgU
DBwmHi46NkROTlZra22GhYYCDABKHUnqCmVuZHN0cmVhbQ1lbmRvYmoNMjI1IDAgb2JqDTw8
IC9MZW5ndGggMTU5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJAAb/+N
gZ0vDFtEI25TN3phRYdvVo98Y52HcaiYgLKfkrqvnse/rtPLvtrZ0ufo4PHy7vnw7vjm4u7f
2ujX0uDMy9TEv8y7t8SxqbqqpLKjnKuZkaKOipqGf5CBeIl0b35rY3VlXG1aUWRQSVtDQlI/
OUoxMEEtKDglHC8bFicTDh4PBhYbFyY2MTxMQ1FhXmV4eXgCDACicUi4CmVuZHN0cmVhbQ1l
bmRvYmoNMjI2IDAgb2JqDTw8IC9MZW5ndGggMjA0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJAL0AQv96dYwsA11FJW5OLXdWNYBbQoRtVI90W5R+Zp+McqmSgbCbjbip
lsG0pM6/sc7JvdfSyuLd1Ofh3PDx6/v48P/x7fnp5PHk3u3b1eTWzt7NydXGvM6/u8y6ssO1
rb2tp7elnq+fmqeakqOSipqKhJSEfo9+doZ3b4JvbXtsZ3ZkXW5aVWZVTWFPSFlCQ1I/OU03
NEUxLDwtKDgkHDAgGCoXFicRCRkIAxATDBwmHS4yLT9GQUpXXVZnZmd6eHsCDADM819jCmVu
ZHN0cmVhbQ1lbmRvYmoNMjI3IDAgb2JqDTw8IC9MZW5ndGggMjA3IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJAMAAP/94b5ElAFo9HGdKKXNSMXtaQYRoT4xrUpR7Y5yG
baSQdqiVgrGjkL2vosK4qsvBsNXNxN3UzeXg2Orq5vbz8fr17/3s5vTn4O/g2+nYz+DUz9zM
ydTDvMu9t8a3r8Czq7uno6+imqucmKWXj5+OhpaGgpKCeYp7c4R2dH5uaXlmXG5dWGlZUWNP
Sl5CRVVGQE1AOEgxMUMyLT0rIjQhHDAcGioTDx8MBRQKBhMaGCotJTQ+NkJOR1NfXWFta3Z/
gYMCDACSZmBxCmVuZHN0cmVhbQ1lbmRvYmoNMjI4IDAgb2JqDTw8IC9MZW5ndGggMjA3IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAMAAP/81JF8yC2E+HWZHJnBSMnta
QYRmTYtwV5B7Y5yEbqWPd6yWg7Gkkb6wpMK5qszCstPOxd3Z0ePj2u/r5PP08Pz06/zr5vPm
3+7e2efXzt/Sz9rKxtLBu8q8tcW2rr6wqbmmoLGhm6mblKSUjJyMhZWFgJCAdoh6c4Nzcnxr
Y3ZjW2tbVmdWTmJQSVpDQ1NCPU42MUYxMUEuKTklITIgGCwYEyQRChoIBBARCxogHiwvMTpF
PUtWUVpnY2t0d3uNjooCDAD0aF+9CmVuZHN0cmVhbQ1lbmRvYmoNMjI5IDAgb2JqDTw8IC9M
ZW5ndGggMTU5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJAAb/9HNGk1
EGJFJG5TNX1dRIVvVpF6YpuJc6mahrWmk7+yocnCtdDMw9za0+fq4vL17/3v7ffl4e3c1eXT
z9vJw9TBvM25tMOwp7ippLGhmamSjZ2LiJiFfo58doVsZntqY3ZfWWpYTl9MSllCQVI4M0cw
LzwpJDQfGisVECEQBxYTCxwnHzE8N0VUVVZsbG2GhoMCDAAr6kf8CmVuZHN0cmVhbQ1lbmRv
YmoNMjMwIDAgb2JqDTw8IC9MZW5ndGggMjEwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJAMMAPP+He5sgAFU5F2NFJG5LKXNUN35iS4hsU4x1XZZ/Z6CIcqiTgbCbjbip
lcGxoMq8rM7HvtjSyt7d1ejl4PPq6/f39P7u7Pnm3/Dg3unc1eTUy97Lyti+v9a5udOxvdSq
tNClqc6hqcqcp8mTmsKUlLCPk6GGhZh+dYZ1c35ycHlnYXFgWmteVWZVTF9PSl1CRlVBO000
MUUzMDwqKjkoIzMdGCkbFSYUDh8HAg8SDBwiHi42LjtHPktXU1loaGh0d3uTkpICDADDh2Kr
CmVuZHN0cmVhbQ1lbmRvYmoNMjMxIDAgb2JqDTw8IC9MZW5ndGggNjcgPj4gDXN0cmVhbQ0K
cF6LJgJWQB5oTy13WTyDZ0+Mdl6XhGqik4m8p7T2rrb/rbX/sLj/nqfvPTxdDAMRFAwcKiEx
PTdEU01ca2duh4aHCmVuZHN0cmVhbQ1lbmRvYmoNMjMyIDAgb2JqDTw8IC9MZW5ndGggNzYg
Pj4gDXN0cmVhbQ0Kh3ybHwBVNRBjRSVuTix3VjmAW0OEbVSOdFqXfWWek5jJrLX+rrb/sbn/
rbX/XWOOBQELEwsbIxsqMTA+RkFKV11WaGZodHd7kJGOCmVuZHN0cmVhbQ1lbmRvYmoNMjMz
IDAgb2JqDTw8IC9MZW5ndGggMTExIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJAGAAn/+He5sgAFU5F2NFJG5LK3NUO3peRIdtVZKOk9Kttv+1vf+AiLUVFiIGDBBlaouz
u/+wuP+ttf+utv+stPyLk8VWXoCHkMm0vP9zfLMqL0EzLTZHQUlXXVZoZmh0d3uRko8CDACJ
6y6tCmVuZHN0cmVhbQ1lbmRvYmoNMjM0IDAgb2JqDTw8IC9MZW5ndGggNzMgPj4gDXN0cmVh
bQ0KbV6LJwNXQB9pTix3Wz2EaVGLdVyYmpnas73/o6rlprDnsbr/rbT/rbX/rrb/srr/s7v/
fIS9GRgqJB0tQDdDVU5abm1xh4aJCmVuZHN0cmVhbQ1lbmRvYmoNMjM1IDAgb2JqDTw8IC9M
ZW5ndGggMTExIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAGAAn/+He5sg
AFU5F2NFJG5OLXdVNX9fRohrUox1XZZ/Z6CIcqiUgLGkkLuiptaqtf6utf+ttf+utv+rs/1q
caEvLUMVESERCRkIAw8SDBwhHi4zLjtHPktXU1pnZ2Z7e3ySkJECDAD9WChtCmVuZHN0cmVh
bQ1lbmRvYmoNMjM2IDAgb2JqDTw8IC9MZW5ndGggMTY1IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJAJYAaf+He5sgAFU5F2RBIGpNLHZVNH9iRYhsU4x1XZZ/Z6CIcqWT
ga+bjbiplcGxoMq8q87HutfRyuLZ0Ofh3PDv7Prg4/zBz/+vuf+stP+ttf+stv+grPGPms1u
dZlXVW1ASFlCQVFBOEo4MUkxLD0tKDgkIDAgGSoXFicRCRkIAw8SDBwhHy0vMTtGPUxXU1ln
ZGt8eoCRk48CDAAPQEZDCmVuZHN0cmVhbQ1lbmRvYmoNMjM3IDAgb2JqDTw8IC9MZW5ndGgg
MTQ3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAIQAe/9vYYwpA1o/HWlP
LXdYPoJnT4t1XJaEa6OSea2iirurnL+5rMrFu9fSy+Ph2evx6Pj38f7r5/XU2fO5xvWuu/is
tv6ttf+jrvebqeiMlch3gqNuaHpYVWdTSl1KR1ZDP084NUYvLT4nITQfGi0VDx8PBxYUDR0q
IDE9OURTV1hraG2Ih4cCDAA9NUHpCmVuZHN0cmVhbQ1lbmRvYmoNMjM4IDAgb2JqDTw8IC9M
ZW5ndGggMTE3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAGYAmf9xXowp
AlpCIWtPMnZYQoBnTot2XJaBa6OQea2XirSrnMW6qtHFuNfMx+m9yvuvuP+ttP+ttf+vtv+i
q+5/i71WXHs3NUcvLT0pIzQhGCsXFCUQCRgUDB0nITE/N0NVTVppaW2ChIUCDABK4S61CmVu
ZHN0cmVhbQ1lbmRvYmoNMjM5IDAgb2JqDTw8IC9MZW5ndGggOTYgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIkAUQCu/29hjCkDWj8daUwrdFg9gWdPi3hfmYJro499rp2N
uKubw6uz6Ky1/621/662/6y2/XeCtCsrQBsWKBQPIBAHFhQMHSMjMDw6RFVXVWtocIiHiAIM
AObcIqwKZW5kc3RyZWFtDWVuZG9iag0yNDAgMCBvYmoNPDwgL0xlbmd0aCAxMjkgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAcgCN/4h7nBwAUTgXYkUkbk8ueFk4g2JJ
h2lQkHRbl4BooIxzppN6rKOKu6iWwLGgyb2t0bPA6Ky6+q20/621/6+3/6Cp7mdvnTQ1Sign
NiQiMiAcLRcVJhEJGQgDDxMPHyYeLzYuOkc+S1ZSWWpranx8fZWTkwIMALZiMHUKZW5kc3Ry
ZWFtDWVuZG9iag0yNDEgMCBvYmoNPDwgL0xlbmd0aCA3MCA+PiANc3RyZWFtDQq2wuSosP6t
tf+wuP+LlNKaot62vv+stP+3v/+hreUjJDMAAABSWX+vuP+utv+1vf9ndJwKCQ9ARVl8hLuk
sPGwuf+rs/8KZW5kc3RyZWFtDWVuZG9iag0yNDIgMCBvYmoNPDwgL0xlbmd0aCAyMTAgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAwwA8/4N7nB0AUTgXY0Egak0sdlU1
f2NJiGlQkHBXlH5mn4xypZOBr6ONvKiWv7ClwcCzzsa81s/H4NnR6OLZ7u7m9vby/vHp+enk
8eTb7dvT5NTO28vJ1sa80L+7zLevv7Oruq2ltaejr56ap5aOnpKMnIyHl4d+joJ5inZzfm1q
e2ljdF9aa1tXalJKXUhJWEFDUkE7TTQxRTUwPC0pOCQbMBsYKhYSIxAIGA8HFxUNHSQcLTIq
N0c+S1ZRWmpnb3x9gJKSjwIMAEO2YWMKZW5kc3RyZWFtDWVuZG9iag0yNDMgMCBvYmoNPDwg
L0xlbmd0aCAxNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAkwBs/3Fe
jCkCWkIha08xdlg/gGVMiXdel4JrpI99rp2OuauZxLmozce619bO5OLc7e7q+PXw/ezn9OHf
6trT4tPO28jE0b67x7iwwK6ouKWer5+Wp5SMnImDlIF6i3p0g25oeWphcl9XaFVNXUpGVkM/
Tzg1Ri8tPikmNyEZLRgUJQwGFBALGSYhMz05RlVYVGlqbIKEhQIMADIaSboKZW5kc3RyZWFt
DWVuZG9iag0yNDQgMCBvYmoNPDwgL0xlbmd0aCAxNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4gDXN0cmVhbQ0KSIkAkwBs/3FejCkCWkIha0wrdlo/g2pRjHZdl4JrpI99rp2OuauZxLmo
zce919bO4eLb7+vr+PXz/ejk9OHd6trT4s/K2sHB1re61K2506aqzqCpypegxpSVtY6RoYJ9
kHdzf3FueWNeb19XaFVNX0pJWkE+UDcyRS8uOykmNh8ZKhkUJQwGFBALGSchMUA3Q1VQV2lq
bIOEhgIMAFpASkgKZW5kc3RyZWFtDWVuZG9iag0yNDUgMCBvYmoNPDwgL0xlbmd0aCAyMTAg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAwwA8/4h7nBwAUTgXY0Egak4t
d1k5g15Fh25VkHdel39noIxzppJ6rJuKt6mXwbOkzbyr0ce21s/G3NrS6ebd7/Hp+fXw/e/s
9+nn8eTe7NvX59PN3s7P1cjB0L+6yLqyw7WtvbCnuKSjrZyWpZuSo46ImIqHl4R+joN6indv
gm9qeWxkc2RdblpVZlVNYU9JWUJBUUM5Sjc0RTEwQS0lNCQbMSAYLRcWJhAIGA8HFxUMHSIf
LjUxOkM9TlZSW2dka3t8f5KSjwIMAG75YcgKZW5kc3RyZWFtDWVuZG9iag0yNDYgMCBvYmoN
PDwgL0xlbmd0aCAxNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAkwBs
/3JhkykDWT8daU8td1g+gmVNiXdel4JspI94rJ2Kt6uZxLmozce619bO4eLc7/Dq+vTw++zn
8+Hf6trT4tPO28jE0b67x7iwwK6ouKWer5+Yp5GOnImDlIF6i3p0g25oeWphcl9XaFVNYUpG
VkM/Tzg1Ri8tPicjNB8ZLRUPIAwEEhAOHSckMkA6QlVWWGlpbYKDhQIMACvmSaMKZW5kc3Ry
ZWFtDWVuZG9iag0yNDcgMCBvYmoNPDwgL0xlbmd0aCAxNTkgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIkAkABv/2VUhC0GXkgncFM0fGFIh2xTknxjnYtxpZR/r6SSvbOm
xb+u087E39nR5+jj8vPx+/Ls+uji8N/a59fP387L1sO+y7u0xLSsvKijsKCZqZmSoY6Hl4Z/
kH51hnZzf2xldmBZallSZEtJW0RCUEE5SDEwQS8nOCMdMBoXKA8IGAsHFB0bKzYuPExFUGJf
ZXV1fAIMAG7jSEoKZW5kc3RyZWFtDWVuZG9iag0yNDggMCBvYmoNPDwgL0xlbmd0aCAyMDcg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAwAA//05Aay8HYD4dZkcmcFMy
fFhAg2NLiXNak3hfmYRupY55rZ2LuKeRvqycxrmqzcW40cvB29bO5uHZ6uzk9Pfv//Dv+Ovn
8+Le693W5tbP3s7N18e+0sK9zby5xrWsva6mtqmksaSdrZmQoY+MnIuJmYV/kIR6jHdzgGtk
e2xjeGRfb11WZ1ZNXlBKWkNHV0I8TjUxRjMxPSspOCkhMR0ZKhcTJBAIGA8HFxQMHCUcLTIt
PkVBSlZZWWpoa3x8fJGSiwIMABUnYBUKZW5kc3RyZWFtDWVuZG9iag0yNDkgMCBvYmoNPDwg
L0xlbmd0aCAyMTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAwwA8/5eK
rB0AUDcWYkUkbk4td1U0f2JIiG9WkHZel39noIxypZJ/rpuItaaVvrKiy8Cv0ca11s/G4NrS
6OXd7e3p+fjw//Ht+enk8eTe7N7c59XP3s3O1cjB0L+8y7m0wq20va2ltaejr56ap5qSopKN
nIqElIR7jIN6i3dvgm9qeWxkc2Zdbl1VZlVNXU9IWEJDUkI9TUA4STIwQSwoOCggMCAYKRkZ
KhMPHw8GFhUNHSIZKzItOUA8TU9PV2hoaHt7f5CQjQIMAKM/YiAKZW5kc3RyZWFtDWVuZG9i
ag0yNTAgMCBvYmoNPDwgL0xlbmd0aCAxNTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIkAkABv/zUeXzcTZEUkblM1fV9Hh25Vj3xknYlyqZWAsaWUvbSnxsCw0s/G3d3V
6Oni8vTu+/Hp+efi797Y59bP3szJ1cG8yrqzwrKru6ahsZ+ZqJePn4yFlYR9jnx0hHRxfWlh
c15YaVdPYkxHV0JAUDczRzAvPyglNSAZLBYQIQwGFA8JGCIiLzs3RFROV2lnbn+CggIMABxL
R8MKZW5kc3RyZWFtDWVuZG9iag0yNTEgMCBvYmoNPDwgL0xlbmd0aCAxODkgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkArgBR/4N7myMAVTcSZEEhak0rdlY5gFtDhG1U
j3RblH5lnoxzqZN6rqOKu6iXv7GlwbywzsS61tDI4NrS6Obd7fHp+fjw//Ht+ebk9NLY8rvK
9bK89627+a21/661/6Ou9p+s8Jeh2oeRwXWDp3ZwhWBdbVhTZlJKXU9JWEJDUkM9TTc0RTEw
QC0oOCQdMiAcLRcSIxAIGA8HFxUMHSYdLjYtOkNCTVZcWGdiant8e5OTkQIMADSWVpwKZW5k
c3RyZWFtDWVuZG9iag0yNTIgMCBvYmoNPDwgL0xlbmd0aCA2NCA+PiANc3RyZWFtDQpxX4wm
AFpBIGtQLnhYPoJnT4t1WpeEeK2lsPCvuP+vt/+ttf+wuf+apOYkJDkNBRImITA9OUZVWFRp
amyChIUKZW5kc3RyZWFtDWVuZG9iag0yNTMgMCBvYmoNPDwgL0xlbmd0aCAxMDIgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAVwCo/4N7nB0AUTgXY0Egak0sdlU1f2JJ
iGxTjHJXlI2Cvqu1/rO7/6Wt55ig1bnF/6y0/621/662/7S8/6+3/1deiBANHCAbLDYuO0c+
SlZPXWpqbHx9gJKQkQIMAFiXK2QKZW5kc3RyZWFtDWVuZG9iag0yNTQgMCBvYmoNPDwgL0xl
bmd0aCAxMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAZgCZ/4d8mx8A
VTYQZEIhak4sd1k8g1xFhYSJy6+4/7K6/2hwmQACAgAAAElRbrnG/6+3/621/6y0/7O7/6Co
6Ghxni4zSQIAAw8QE6Gp6bC4/7C6/3iCtjMuQ0E9TVZSW2dka3t8f5KSjwIMAFR1L/sKZW5k
c3RyZWFtDWVuZG9iag0yNTUgMCBvYmoNPDwgL0xlbmd0aCA3MyA+PiANc3RyZWFtDQpxXowp
AlpCIWxML3RYPoBpUY+SldazvP+Rmc4YGyckKDSepd+ttf+wuP+0vP+Xn9phao+TnNt3gLgr
LTw9Nz9VWFVpamyDhIYKZW5kc3RyZWFtDWVuZG9iag0yNTYgMCBvYmoNPDwgL0xlbmd0aCA5
OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBUAKv/iHucHABRNxZhQSBq
Ti13VTV/X0aIa1KMdV2WgGegi3GmlpPFqLb6rrX/rbX/r7f/o6z2UVN8EQgXDgYWFQwdJh0u
Ni46Qz5OVlBeZ2Nre3p9k5OQAgwA7f4jMgplbmRzdHJlYW0NZW5kb2JqDTI1NyAwIG9iag08
PCAvTGVuZ3RoIDE0NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQCBAH7/
h3ubIABVORdjRSRuTi52VkF8W0KFbVSPdFuUfWWeiHOpk3qulIqzppfAtaXNvKzRxbfWzsXk
xcr1ucn+rrX/rbX/rrb/pKzwipTLa3egS1BrNjNDMTBALCg4KCAyIBcrGRYnEw8gDwYWFQwd
Ih0uNS47Rz5KV09daGdpdHd7kJGOAgwA1T45CAplbmRzdHJlYW0NZW5kb2JqDTI1OCAwIG9i
ag08PCAvTGVuZ3RoIDEzMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQB1
AIr/cV6MKQNaQB9pTix3WzqEalCMdl6Xgmujj32snY65q5nEuajNyLvX1Mzk3tjs7Or52N/9
tcL/rLT/rbX/rrX/q7T+m6bleICnVFVtQUVVQjpMOTFIMCs7JyMyHxkrFREjDAUSEQsaJCQw
PDdFVVBXa2hwh4eIAgwAZdE4CwplbmRzdHJlYW0NZW5kb2JqDTI1OSAwIG9iag08PCAvTGVu
Z3RoIDEwMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBXAKj/cF6LJgJX
QiFrUS96XD+FaE+OdVyZhWyjknirooq6q5nDuqnPtL7nrLn9rbX/r7f/p7D3aG+dLy9CJiMy
HxwtFREiCwQSEQ4dKiIyPzZDVVBYbm5uiYeIAgwA7iIlWAplbmRzdHJlYW0NZW5kb2JqDTI2
MCAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCnFejCkCWkIha08teFk8g2dPjHZe
l4Jro5F8rqKSvaWs5q22/621/7G5/4SNxzIyShMNHQsFExALGSUhMT83Q1VQV2tra4eGhwpl
bmRzdHJlYW0NZW5kb2JqDTI2MSAwIG9iag08PCAvTGVuZ3RoIDExNyAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIiQBmAJn/g3ubIwBVNxJkQiFrSShyVTh+W0OFbFOOd16Y
f2egiHKok4Gwm424qZS/ranPqbX0rbX/rrX/rbf/jJfSRk5uIhwvGxgpFhIjEAgYDwcXEwwd
IR8sLzA7RkFLV1xXZ2Jre3x/k5OQAgwA3XUpowplbmRzdHJlYW0NZW5kb2JqDTI2MiAwIG9i
ag08PCAvTGVuZ3RoIDEwOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBd
AKL/cF6LJgJWQB5pSyp0XEOKn6XsuML/g467AAAATlBut8X/r7b/rLX/r7f/qLP3rbX9rbX/
sbn/tr7/o6vsYGeOFhkjSU5qs7v/rrb/sLj/nKTmS0teUlBRaWpsg4SGAgwATRA0tgplbmRz
dHJlYW0NZW5kb2JqDTI2MyAwIG9iag08PCAvTGVuZ3RoIDExNyAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIiQBmAJn/trq4k4Cvp5TBtaXMwbTS0Mjd3tbm6uT09+//8ez5
5eHu3dbm1s/ezcrWw73Mu7TEtKy8q6OzoJqpmZKij4qahoCQgnmKd3J/bmh4Yl1tWlJlU0pd
SUZVQDtLMzFCLSo6IxowGBMlAgwAsOA8wgplbmRzdHJlYW0NZW5kb2JqDTI2NCAwIG9iag08
PCAvTGVuZ3RoIDE1MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQCKAHX/
vMe5iXCklIKypI28qZfBsqLJvbHPxrzX0cnh29Ps597w7+j39vL+6OPw493r2tLj0s7aysbV
xbzPvrrKubHCsai5qaW0pKGtnZiml5ChjIiYjIOThHuMfXSFc2uAamN6Z19wYllqV05kUEpf
Q0ZWRkFOPjZJMjFCNC46KiU1JRwwHBcpDwgbKjQsAgwAySRODAplbmRzdHJlYW0NZW5kb2Jq
DTI2NSAwIG9iag08PCAvTGVuZ3RoIDE2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry
ZWFtDQpIiQCZAGb/nKKscViUf2ihiXKmk4OwnZG6ppS+saDJvq3TxbXW0snh39br5+Lz7+z4
9vD+7+r35+Lw39/r3tbm08/bzc3Vxr/OvrnHubHCtay8qqa1pKGtnZimmJChkIiYiIOTg3uM
fXSFdG2Abm16a2NzX1prV09kTk1fT0pZRD5PQThJMjJDMC0+KiU1JRwwHBgqFxcoEAkZDgQW
HyIlAgwAuy1UGAplbmRzdHJlYW0NZW5kb2JqDTI2NiAwIG9iag08PCAvTGVuZ3RoIDEyNiAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBvAJD/v8+8gXGfi3OqmIWzqpnD
uKjNxLbU0sri3NXr7uj59PD87On04t/r2tTj087bycXRv7vHt7DArqa2pp+unJalk42diYWV
gXiKeXOCcGx4Zl1uXlhpVE1dSEVVQD1ONjNELiw8JSEwGhYnEQscDwoXAgwAsGI+0wplbmRz
dHJlYW0NZW5kb2JqDTI2NyAwIG9iag08PCAvTGVuZ3RoIDE0NCAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIiQCBAH7/zeXEnJ2vpZXAsKDKva3Sx7bW0Mfg2dLr4tnw7+r2
8/D77+j36efx5ODs3tfn1c/dzc7VyMHQw73Mu7nDs6q6q6W1oqOtoJqpm5KjkoqaioSUhH6P
f3aHd2+Cb2t7bGR2Z15uXVVmVU1dUElYQ0NTPzpOODNFMTBBLSk5Jh8xIygtAgwAzYBN4gpl
bmRzdHJlYW0NZW5kb2JqDTI2OCAwIG9iag08PCAvTGVuZ3RoIDY3ID4+IA1zdHJlYW0NCrbC
5Kiw/q21/662/6y3/yMmNwAAADA0SouYziUmNVlihLjH/661/7C3/667+CIlOBQWIEtSboSR
x6m4+rC4/6uz/wplbmRzdHJlYW0NZW5kb2JqDTI2OSAwIG9iag08PCAvTGVuZ3RoIDc5ID4+
IA1zdHJlYW0NCsDI6Kiw/K21/7K5/4+W0hETG1RbgLS9/5+n5SQoNQAAACQnN5Ga3LC4/661
/662/623/zI4TAIEBiIiNE9XeZCb27G6/7G5/620/6ix/gplbmRzdHJlYW0NZW5kb2JqDTI3
MCAwIG9iag08PCAvTGVuZ3RoIDEwOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiQBdAKL/8v/u3vjS3fTU6fLs8+/88Oz46OPw5N7s29jk083bzs/WzMnUv7rIu7PDs6q6
qqW1paOvn5qnmpKjkoycioeXhH6Pf3aHeHCCb2t6bGV0Z15vXlZmYWZidIlvnbyMAgwAZrI/
agplbmRzdHJlYW0NZW5kb2JqDTI3MSAwIG9iag08PCAvTGVuZ3RoIDEwOCAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBdAKL/5vbgu8O9uafNyb3a1c3m49ru8un69vD+
6+fy4N7p2dLi0s7ayMPQv7jHs7PArqu4pp6unJalkYyciYSUgnuMenODb2x6Zl5vXVhoVk1e
SkZWQj1NOjVGKyc6UVxPAgwA1I06ZAplbmRzdHJlYW0NZW5kb2JqDTI3MiAwIG9iag08PCAv
TGVuZ3RoIDEyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBvAJD/4vXY
wczAxLrX0sri3dXo497y9Oz89PD87uz26OPw49rr2tHj0s/aysbVxbzOvrrHubHCsai5rKW0
pqGuoZiplpCgkIybiYCQhHuMfnaHb257bGV6aWJzX1prW1JkUUtfQ0ZWQkFROzNJOjdDfI9v
AgwAaWhG5wplbmRzdHJlYW0NZW5kb2JqDTI3MyAwIG9iag08PCAvTGVuZ3RoIDEzNSAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQB4AIf/pae0bVWOfmSfjXOplYKxppW+
tafHxLPUz8bd2tPo6uHy9fH97+736OHw39bn1s/ey8XWwrzLu7bDsqm5p6Kyo5qrmpGij4qa
hoCQgXmKdW+Aa2N4Zl1tWlJjUUlZRUNTQDpLNTFALik4IxsxGxUnEQkZCAMREQwbAgwAxeFB
bwplbmRzdHJlYW0NZW5kb2JqDTI3NCAwIG9iag08PCAvTGVuZ3RoIDE5OCAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQC3AEj/hn6XNxNkTy54WTiDYkmIbFSNclmTfmaf
iXOpk3mtm4K0ppS+rp7IvKzSx7bW0Mbg3dXn5eDw8Ov69PD88ez56efx5N7t29fk083bzs/W
yMXUxL3Mu7XEsqq6raW1paOtoJqpm5KjkoycioeXhH6OfnaGd2+Cb2p7bGR2Zl1uXVVmVU1h
T0lZQkFRPzZKNzRGMSw8LCk5KCMzIBgpFxYnEAgYDwcXFAwdJh4uNjE6QDxNTk5YZF9nAgwA
NLhdQwplbmRzdHJlYW0NZW5kb2JqDTI3NSAwIG9iag08PCAvTGVuZ3RoIDE1MyAvRmlsdGVy
IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQCKAHX/dHSKPBtoTi13WkGEaVCMeWGaiG6m
loKypZG+saPEva/Py8Pc2NDm5eHx8PD78+z66ePw4Nrp19DfzcbXw7zMu7TEs6u7qqS1oJqo
l5GhjIeWhH+RenWKcW17bGN0YVxtV09hUkpaR0RUPDdIMTBAKiY2IRsvGhUnEAoZDQYVIxwt
OzM/UVFTZGJoAgwAKgxGMgplbmRzdHJlYW0NZW5kb2JqDTI3NiAwIG9iag08PCAvTGVuZ3Ro
IDE1NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQCNAHL/aFuBNhBkTSx2
VjeAY0uJdFqUgWegj3msmYy3q5jEuqrOyLzW1Mzj3tjr7uj59/D+7en05d/t29Pj0szaxr/P
v7nKuLDAr6i4pJ6tnJalk4ubiYSTgXqKeHCCb2x7aGJyW1ZnVUxfSUZVPztONjJELyo5Jh8x
HhgqFA8gCgQQFg8eLCU3Qj5IWV5Zb21wAgwAxLZHIAplbmRzdHJlYW0NZW5kb2JqDTI3NyAw
IG9iag08PCAvTGVuZ3RoIDIwMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
iQC6AEX/TzdrPBhpRyZvUjJ7W0KEaVGLcFeQe2OdhG6kj3eoloOypJK9rZzGuKvLwrLUy8La
1s7k4dnu7OT09+//8O/46+fz4t/r3dnm1s7ez8/XysbSwb3KurbCt6/ArqW2qaWxoJmpmpSk
kI+cjYaUiIOMg3mMfHWEb2t7amFzYFtsXlZnV05iSUlaQkNSRz5LOTVGMDBBLSk5KSEyHRku
FxMkEAgYDwcXEw8gIR0uNi05Qj1NVVJaZmdnd3d6AgwAeqRdqQplbmRzdHJlYW0NZW5kb2Jq
DTI3OCAwIG9iag08PCAvTGVuZ3RoIDE1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry
ZWFtDQpIiQCHAHj/Z1iBRyZxWD+AaVCNd1+YhGuikHurnJC5rp3HuqnOyLvY1Mzi4tru7+r2
9fD96+bz4N7p2dLi0MrYxb7NvbjGt66+rKe4op+um5Sjkomah4KSgnqLeXSBbml5Y1ttWlRl
U0tbRkRTQTxMMzJDLSo6IxsxGRcpFA8fCgQSFxMkLSo4SkROXFpdAgwAk1hFFgplbmRzdHJl
YW0NZW5kb2JqDTI3OSAwIG9iag08PCAvTGVuZ3RoIDEzOCAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIiQB7AIT/k5GfWT6CblWQfWSdi3KolICwo5C8sqHKwK/QzsTe2dHp
5uDx9e7+8u366OXw4Njp2dHhzMXWw7zMu7XEsqm6p6Kyo5urmZGijoeXhX+QfnaGdG9+a2N3
ZV1tV05jSkhcQkJSPzpKMi4/Lyc3JR0uGxcoEg0dCgQSLig3AgwAIJNCZwplbmRzdHJlYW0N
ZW5kb2JqDTI4MCAwIG9iag08PCAvTGVuZ3RoIDE4MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIiQClAFr/2OjTbGCDZkyKclmXfmahiXKllIKwo428qJbAsaHKva3PxbvU
0Mjh3dXn4tzx7uv49vD+8en56OTw4N7p3NXk083bzs/WyMHQv7rMurLDta29r6e3p6Ovnpan
mpKjjoqajIaSh4GMfnWHd3GCb256amFxXVprWlVmVU1hT0hZRENRRDtLNDFFMTBBLSk4JCAy
IBktFxMjEAgYDwcXFBAgIxktO0I4AgwA2rhYuQplbmRzdHJlYW0NZW5kb2JqDTI4MSAwIG9i
ag08PCAvTGVuZ3RoIDE4NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQCr
AFT/k5SeTzN6YkiIb1aQd16Yf2ehiHKllIKwlI21ppa/saDKwK/SxrjX0Mjd3tbm5tzu7un2
8/T77+n36eTx4N7p3NXk083bzs/WyMHQv73IurXDrbW9sKe4pKOtnJqlmpKjkoycioeXhH6O
fnaGd2+Cb2t5bGRzZl5uXVVmVExdU0paSERUQjlKODRFLzBBKik4JRwyGxgtFxYnEAgYEAcX
EQgZIR0tNTE6PjZJAgwABQVZjAplbmRzdHJlYW0NZW5kb2JqDTI4MiAwIG9iag08PCAvTGVu
Z3RoIDE5MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQCxAE7/cmaHSCRz
VjWAYEeIaE+QdVyYgGihiXKmk4OwnI25qZfCsaLJwbXPx73X0cni2tLo49/y9Oz89O/87uf2
6N/w497r2tLj0s7azc3Vxr7OvrzHvbbGsqq6qKS0pJ2tnZiml5ChjIybiICRg3qLfHWEb2t8
a2J3aWNyYFtrV05kUEpfQ0ZWRkFOPjZJMjFCNC46KSU1IhwtHRcpEwwdDwcXEAgYGBMkLCU0
PjVBTUVSXF5bAgwASF5asQplbmRzdHJlYW0NZW5kb2JqDTI4MyAwIG9iag08PCAvTGVuZ3Ro
IDE0NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQCBAH7/fXSUTzF7YUiH
b1eQf2efj3WrnoW3qpnAtabHxLXV0srj39jt7un59+/+7er14uDq3dXm1M/cysXSv7nKt6+/
rqW2p56wnJSkkoqaiYOTg3uMe3WEcGx4ZV1uW1VnVEtfSEVVQT1ONTNELiw7KCAyHhgrFhEh
CgUTGBMiLic3QT1FAgwATd1DRAplbmRzdHJlYW0NZW5kb2JqDTI4NCAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEgL0hlaWdodCAxIC9CaXRzUGVy
Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExNSAwIFIgL0xlbmd0aCAxNSAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr+/ztAgAEABd0C7gplbmRzdHJlYW0NZW5kb2Jq
DTI4NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMg
L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExNSAwIFIgL0xl
bmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifry/8vX/19//f8I
EGAAK6sIuwplbmRzdHJlYW0NZW5kb2JqDTI4NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv
U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg
DS9Db2xvclNwYWNlIDExNSAwIFIgL0xlbmd0aCAxNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIifr8/zNAgAEABc0C5gplbmRzdHJlYW0NZW5kb2JqDTI4NyAwIG9iag08
PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEgL0hlaWdodCAxIC9C
aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExNSAwIFIgL0xlbmd0aCAxNSAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr+/T9AgAEABdUC7gplbmRzdHJlYW0N
ZW5kb2JqDTI4OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp
ZHRoIDE3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTUg
MCBSIC9MZW5ndGggNjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAMwDM
//P3+OLt6Mvg5cDV57TF6K2966297q2+76q27qeu7Km17Ka346q62rDF1L3W09fp3tfp3gIM
AEERKVAKZW5kc3RyZWFtDWVuZG9iag0yODkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1
YnR5cGUgL0ltYWdlIC9XaWR0aCAxOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN
L0NvbG9yU3BhY2UgMTE1IDAgUiAvTGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJevb205k7r7ce/rRm67+1W//jQuu2/V+69vuC9Xc2nz4LRAABBgCx4yr4
CmVuZHN0cmVhbQ1lbmRvYmoNMjkwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl
IC9JbWFnZSAvV2lkdGggMzAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv
clNwYWNlIDExNSAwIFIgL0xlbmd0aCA1MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry
ZWFtDQpIiXr1/tOZ268Pnvq+afe/NVv+r91KJlq39f/KbX/mr383b/WVJTuPAhFAgAEA5JxH
NwplbmRzdHJlYW0NZW5kb2JqDTI5MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw
ZSAvSW1hZ2UgL1dpZHRoIDI1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s
b3JTcGFjZSAxMTUgMCBSIC9MZW5ndGggMzQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIk6e+/x2l0/1m75v3YrmWjNlv9z19wHIoAAAwDXqjswCmVuZHN0cmVhbQ1lbmRv
YmoNMjkyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg
MzcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExMyAwIFIg
L0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGLGC1hY
2dgAAgwAB5sAcwplbmRzdHJlYW0NZW5kb2JqDTI5MyAwIG9iag08PCAvVHlwZSAvWE9iamVj
dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu
dCA4IA0vQ29sb3JTcGFjZSAxMTUgMCBSIC9MZW5ndGggMzMgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIl68u7V1qMvV2/5v3Yr1RDQtDmrrgIRQIABAKA9SYsKZW5kc3Ry
ZWFtDWVuZG9iag0yOTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl
IC9XaWR0aCA0MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug
MTEyIDAgUiAvTGVuZ3RoIDE5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ
YmBkIgows7AABBgABxgAWQplbmRzdHJlYW0NZW5kb2JqDTI5NSAwIG9iag08PCAvVHlwZSAv
WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM0IC9IZWlnaHQgMSAvQml0c1BlckNv
bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4OSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZMIDmFmYmAACDAAEbQBFCmVuZHN0cmVhbQ1lbmRv
YmoNMjk2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg
NDcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg0IDAgUiAv
TGVuZ3RoIDIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkIgows7Cy
sXNwAAQYAAjGAHcKZW5kc3RyZWFtDWVuZG9iag0yOTcgMCBvYmoNPDwgL1R5cGUgL1hPYmpl
Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l
bnQgOCANL0NvbG9yU3BhY2UgOTEgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmHFBdjYOTi5uHl4AAIMAAzwANMKZW5kc3RyZWFtDWVu
ZG9iag0yOTggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0
aCA1MiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgOTkgMCBS
IC9MZW5ndGggMzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFl
Y+fg5GLCB7i4eXj5+Pj4BQSFhAACDAAT9QEeCmVuZHN0cmVhbQ1lbmRvYmoNMjk5IDAgb2Jq
DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDAgL0hlaWdodCAx
IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDkyIDAgUiAvTGVuZ3RoIDM3IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5kEHvHz8Aqys
rIJCTEwAAQYAG2oBfwplbmRzdHJlYW0NZW5kb2JqDTMwMCAwIG9iag08PCAvVHlwZSAvWE9i
amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSA5NiAwIFIgL0xlbmd0aCA1MiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIiWJgZGJiYmZhZWNjY+fg5OLmYWZCA7x8/AKCTELCIkAlbKJi
4oJMTBISAAEGACCvAacKZW5kc3RyZWFtDWVuZG9iag0zMDEgMCBvYmoNPDwgL1R5cGUgL1hP
YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w
b25lbnQgOCANL0NvbG9yU3BhY2UgMTIxIDAgUiAvTGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmJiZmFlAwJ2Dk4ubh4mKODlY+MXEAQKCwmLALmi
ogABBgAU3wFBCmVuZHN0cmVhbQ1lbmRvYmoNMzAyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0
IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50
IDggDS9Db2xvclNwYWNlIDEyNSAwIFIgL0xlbmd0aCA0NSAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIiWJgZAIDZhZWNihg5+Dk4maCAx5ePjY2fgFBsJyQsAhEVFQUIMAA
IlwBewplbmRzdHJlYW0NZW5kb2JqDTMwMyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi
dHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v
Q29sb3JTcGFjZSAxMjAgMCBSIC9MZW5ndGggNDIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g
DXN0cmVhbQ0KSIliYGQCAmYWVjYoYOfgZOLiYmLi5OaBCPDy8YOUMAkIAAQYABPsARAKZW5k
c3RyZWFtDWVuZG9iag0zMDQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA2MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgMTMxIDAgUiAvTGVuZ3RoIDQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJYmBkggJmFlY2GGDn4OSCiXPz8MKE+fgF4MJMgoIAAQYAIL4BRQplbmRzdHJlYW0NZW5k
b2JqDTMwNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo
IDQ2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMjMgMCBS
IC9MZW5ndGggMzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQCAWYW
VjYwYOfgZIIALm6ICA8vEx9EhJ8fIMAAEmgA7gplbmRzdHJlYW0NZW5kb2JqDTMwNiAwIG9i
ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYyIC9IZWlnaHQg
MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMzYgMCBSIC9MZW5ndGggMzgg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSCA2YWVjYIYOfgRAhzcbPB
AA8vH0KciZ8fIMAAHkEBHgplbmRzdHJlYW0NZW5kb2JqDTMwNyAwIG9iag08PCAvVHlwZSAv
WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ3IC9IZWlnaHQgMSAvQml0c1BlckNv
bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAzMiAwIFIgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZIIAZhZWNhBg5+DkYmLiYuLm4WWDAD5+AS6IGkFB
gAADABXXAR8KZW5kc3RyZWFtDWVuZG9iag0zMDggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg
L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg
OCANL0NvbG9yU3BhY2UgMzQgMCBSIC9MZW5ndGggNDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4gDXN0cmVhbQ0KSIliYGRCAGYWVjY2NnYOIMHGycUNEeThZYMDPn4BQWaEeiEhgAADACPC
AVUKZW5kc3RyZWFtDWVuZG9iag0zMDkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA0OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgMjkgMCBSIC9MZW5ndGggNDYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIliYGSCAmYWVjZ2Dk42NjYubh4mJl4+fjYQEBAUEmYWgaoRFQUIMAAZfgFQCmVu
ZHN0cmVhbQ1lbmRvYmoNMzEwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J
bWFnZSAvV2lkdGggNjUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw
YWNlIDQyIDAgUiAvTGVuZ3RoIDUwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJYmBkQgbMLKxs7BycXNw8QMDLx8QPFBIQBHGEhEVExcQ5JFCUM0lKAgQYADZKAfgKZW5k
c3RyZWFtDWVuZG9iag0zMTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA0OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgNDQgMCBSIC9MZW5ndGggNDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIliYGSCAWYWVjYmdg5OLi4ubh52Xj5+LgFBIWERUTEmBBAXBwgwAB3vAXkKZW5kc3RyZWFt
DWVuZG9iag0zMTIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X
aWR0aCA2NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzgg
MCBSIC9MZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRC
BcwsIJKVjZ0DCDi5WFi4eTh4+fiZBZiwA4AAAwAg6AEGCmVuZHN0cmVhbQ1lbmRvYmoNMzEz
IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDkgL0hl
aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDI3IDAgUiAvTGVuZ3Ro
IDMzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQgXMLKxs7BycXNw8
vHz8TOhAQAAgwAAR4wDXCmVuZHN0cmVhbQ1lbmRvYmoNMzE0IDAgb2JqDTw8IC9UeXBlIC9Y
T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjUgL0hlaWdodCAxIC9CaXRzUGVyQ29t
cG9uZW50IDggDS9Db2xvclNwYWNlIDE3IDAgUiAvTGVuZ3RoIDM0IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkwg6YWVjZ2DmADE4ubh4capiYeHkBAgwAF0oAzQpl
bmRzdHJlYW0NZW5kb2JqDTMxNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv
SW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT
cGFjZSAxMCAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiWJgZEIHzCysbOwYolDAwQEQYAALTgB9CmVuZHN0cmVhbQ1lbmRvYmoNMzE2IDAgb2Jq
DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAx
IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4IDAgUiAvTGVuZ3RoIDI1IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYiYAWFjZWHBKsrMDBBgAGX0A
0AplbmRzdHJlYW0NZW5kb2JqDTMxNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw
ZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s
b3JTcGFjZSAyNiAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry
ZWFtDQpIiWJgZMIOmFlY2dg5MIQ5OQECDAALbwCFCmVuZHN0cmVhbQ1lbmRvYmoNMzE4IDAg
b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdo
dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5IDAgUiAvTGVuZ3RoIDM3
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYsYKWFjZ2Dk4gQxOLm4e
Xj5+AezKBAUBAgwAJDABPgplbmRzdHJlYW0NZW5kb2JqDTMxOSAwIG9iag08PCAvVHlwZSAv
WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNv
bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0NiAwIFIgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJGBiysbOwcnFzcPLx8/Pz8AoLMaEBICCDAABpa
ATAKZW5kc3RyZWFtDWVuZG9iag0zMjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgNzIgMCBSIC9MZW5ndGggNDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIliYGRiRgcsrGzsHJxcXNw8vMzMfPwCXEAgKCSMoQ4EREQAAgwALmMBjgplbmRz
dHJlYW0NZW5kb2JqDTMyMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h
Z2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj
ZSA2NSAwIFIgL0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
iWJgZGKGARZWNnYOTi4uLm4eZl4+fgEgS1BIWERUTFwCrkZSEiDAACPvAccKZW5kc3RyZWFt
DWVuZG9iag0zMjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X
aWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzMg
MCBSIC9MZW5ndGggNDkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRi
hgMWVjZ2Dk4ubgjg4eUDC/ILCIL5QsIiotxi4nzMSEBCUhIgwAA+kgJACmVuZHN0cmVhbQ1l
bmRvYmoNMzIzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgyIDAg
UiAvTGVuZ3RoIDQ0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYgYD
FlY2dg4I4OTiBonw8PIBOfwCHByCQsxQICwiAhBgAB4vAXIKZW5kc3RyZWFtDWVuZG9iag0z
MjQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAv
SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzQgMCBSIC9MZW5n
dGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZoECVjZ2DgTg
5OKGSfDw8vHDhAUEWVngQEhYRAQgwAA1JAHgCmVuZHN0cmVhbQ1lbmRvYmoNMzI1IDAgb2Jq
DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAx
IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc2IDAgUiAvTGVuZ3RoIDQzIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmYBA1Y2dg4w4OTihojw8PLx
g0UEBIUgIsIioqIAAQYAHykBkQplbmRzdHJlYW0NZW5kb2JqDTMyNiAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1Bl
ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MiAwIFIgL0xlbmd0aCA0NCAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYYUBNnYOTijg4uZhRQAWXj6YBL8AG1y5
oJCwMECAAQA3VAHwCmVuZHN0cmVhbQ1lbmRvYmoNMzI3IDAgb2JqDTw8IC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDUwIDAgUiAvTGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhBQI2dg5OLjDg5mGFAF4+fgGIkKAQWA2rsIioKECA
AQAj3QG6CmVuZHN0cmVhbQ1lbmRvYmoNMzI4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T
dWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg
DS9Db2xvclNwYWNlIDQ5IDAgUiAvTGVuZ3RoIDQ4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJYmBkYmZhZQMDdg5OLm4o4OHlY4MDfgFBbgQQEhaBCIuIiolLSAAEGABG
pQKdCmVuZHN0cmVhbQ1lbmRvYmoNMzI5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0
eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D
b2xvclNwYWNlIDYxIDAgUiAvTGVuZ3RoIDQ4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJYmBkYmZhZWVlY+fg5OTk4ubk5OFlhQI2Pn5OKBAQBAkICYuIigIEGAAitwG1
CmVuZHN0cmVhbQ1lbmRvYmoNMzMwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl
IC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv
clNwYWNlIDU5IDAgUiAvTGVuZ3RoIDU4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl
YW0NCkiJYmBkYmZhZWNnZ+fg5OLmAQJePn4BHkEhYXYkICIqJi4hKcUDAdIyEEFZOXkFRUWA
AAMAWTUDcAplbmRzdHJlYW0NZW5kb2JqDTMzMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv
U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4
IA0vQ29sb3JTcGFjZSA1OCAwIFIgL0xlbmd0aCA2MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubhBQI+fgFBIWERUUEOVCAmLiEpJS0DUiIrJw8U
UFBUUlZRVVMDCDAAY84ECAplbmRzdHJlYW0NZW5kb2JqDTMzMiAwIG9iag08PCAvVHlwZSAv
WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNv
bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NyAwIFIgL0xlbmd0aCA0OCAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5wACTi5uHl4+fgEUICgkLCLKwSEmLiEp
JS0jKycHEGAANpsC6AplbmRzdHJlYW0NZW5kb2JqDTMzMyAwIG9iag08PCAvVHlwZSAvWE9i
amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSA1NiAwIFIgL0xlbmd0aCA1MiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh4eHl4xfAAwSFOIVFRMXEJSQFpKRl
ZOXkFRQVAQIMAGyXBDQKZW5kc3RyZWFtDWVuZG9iag0zMzQgMCBvYmoNPDwgL1R5cGUgL1hP
YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w
b25lbnQgOCANL0NvbG9yU3BhY2UgNjIgMCBSIC9MZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OJm58EBePn4BQT5hIRFRMXExQECDAAu
pAJVCmVuZHN0cmVhbQ1lbmRvYmoNMzM1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0
eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D
b2xvclNwYWNlIDYzIDAgUiAvTGVuZ3RoIDQ0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcgAggKCQuIiIqJS0hKScvIAAQYAGvWA/MKZW5k
c3RyZWFtDWVuZG9iag0zMzYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgNjAgMCBSIC9MZW5ndGggMzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIliYGRiZmFlY+fg5OLGB3h4+fgFBIWERUQAAgwAK84CGwplbmRzdHJlYW0NZW5kb2JqDTMz
NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9I
ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NSAwIFIgL0xlbmd0
aCA0MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh
5SMK8AsICgmLiIqJS0hKSUsDBBgAYhADnAplbmRzdHJlYW0NZW5kb2JqDTMzOCAwIG9iag08
PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAv
Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0OCAwIFIgL0xlbmd0aCAzOCAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubBCXj5+AUEhYRF
RMXExQECDAAvQwJYCmVuZHN0cmVhbQ1lbmRvYmoNMzM5IDAgb2JqDTw8IC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDQ3IDAgUiAvTGVuZ3RoIDQ4IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcgAASFhEVExcQlJKWkZWTl5BUU
FQECDABufQRDCmVuZHN0cmVhbQ1lbmRvYmoNMzQwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0
IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50
IDggDS9Db2xvclNwYWNlIDUzIDAgUiAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHlwwb4BQSFhEVExcQlJKWkZWQAAgwANdgC
ywplbmRzdHJlYW0NZW5kb2JqDTM0MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw
ZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s
b3JTcGFjZSA1NCAwIFIgL0xlbmd0aCA1NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry
ZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhHFDsTEJSSlpGVk5eQVFJWUVVTV1DU0tbQA
AgwAh/4FgAplbmRzdHJlYW0NZW5kb2JqDTM0MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv
U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4
IA0vQ29sb3JTcGFjZSA1MSAwIFIgL0xlbmd0aCA1MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSRgARUTFxCUkpaRlZOXkFRSVlFVU1
NYAAAwBELgPKCmVuZHN0cmVhbQ1lbmRvYmoNMzQzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0
IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50
IDggDS9Db2xvclNwYWNlIDY0IDAgUiAvTGVuZ3RoIDcyIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaBAlk5eQVFJWUV
VTV1DU0tbR1dPX0DQyNjE1MzcwtLS4AAAwCrDwdzCmVuZHN0cmVhbQ1lbmRvYmoNMzQ0IDAg
b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdo
dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc3IDAgUiAvTGVuZ3RoIDYx
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQ
FBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXTNzAACDAAUYoEyQplbmRzdHJlYW0NZW5k
b2JqDTM0NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo
IDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NSAwIFIg
L0xlbmd0aCA3NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj
5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0srax
tbN3cAAIMAC7YghhCmVuZHN0cmVhbQ1lbmRvYmoNMzQ2IDAgb2JqDTw8IC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDc4IDAgUiAvTGVuZ3RoIDYxIC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRS
VlFVU9fQ1NLW0dXTNzAACDAAUYoEyQplbmRzdHJlYW0NZW5kb2JqDTM0NyAwIG9iag08PCAv
VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0
c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MSAwIFIgL0xlbmd0aCA3NyAvRmlsdGVy
IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQ
lJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbN3cAAIMAC7YghhCmVuZHN0
cmVhbQ1lbmRvYmoNMzQ4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl
IDgwIDAgUiAvTGVuZ3RoIDYxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ
YmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXTNzAACDAA
UYoEyQplbmRzdHJlYW0NZW5kb2JqDTM0OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi
dHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v
Q29sb3JTcGFjZSA3OSAwIFIgL0xlbmd0aCA3NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN
c3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS
1tHV0zcwNDI2MTUzt7C0sraxtbN3cAAIMAC7YghhCmVuZHN0cmVhbQ1lbmRvYmoNMzUwIDAg
b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDkgL0hlaWdo
dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY3IDAgUiAvTGVuZ3RoIDYw
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQ
FBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXT1wcIMABMwASYCmVuZHN0cmVhbQ1lbmRv
YmoNMzUxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg
NjUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY2IDAgUiAv
TGVuZ3RoIDc2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn
4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXTNzA0MjYxNTO3sLSytrG1
s7cHCDAAswAIIAplbmRzdHJlYW0NZW5kb2JqDTM1MiAwIG9iag08PCAvVHlwZSAvWE9iamVj
dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu
dCA4IA0vQ29sb3JTcGFjZSA2OCAwIFIgL0xlbmd0aCA2MCAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZR
VVPX0NTS1tHV09cHCDAATMAEmAplbmRzdHJlYW0NZW5kb2JqDTM1MyAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY1IC9IZWlnaHQgMSAvQml0c1Bl
ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MSAwIFIgL0xlbmd0aCA3NiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKW
kZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbO3BwgwALMACCAKZW5kc3RyZWFt
DWVuZG9iag0zNTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X
aWR0aCA0OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzAg
MCBSIC9MZW5ndGggNTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRi
ZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0tbR1dMDCDAASCcEaApl
bmRzdHJlYW0NZW5kb2JqDTM1NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv
SW1hZ2UgL1dpZHRoIDYzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT
cGFjZSA2OSAwIFIgL0xlbmd0aCA3NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcw
NDI2MTUzt7C0sraxtQUIMACi/gehCmVuZHN0cmVhbQ1lbmRvYmoNMzU2IDAgb2JqDTw8IC9U
eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDcgL0hlaWdodCAxIC9CaXRz
UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIxIDAgUiAvTGVuZ3RoIDU4IC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CU
kpaRlZNXUFRSVlFVU9fQ1NLW0dUFCDAAQ74EOQplbmRzdHJlYW0NZW5kb2JqDTM1NyAwIG9i
ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYyIC9IZWlnaHQg
MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMCAwIFIgL0xlbmd0aCA3MyAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQS
FhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxAQgwAJtcB2MKZW5k
c3RyZWFtDWVuZG9iag0zNTggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA0NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgMjIgMCBSIC9MZW5ndGggNTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0tbRAQgwAD+E
BAsKZW5kc3RyZWFtDWVuZG9iag0zNTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA2MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgMjUgMCBSIC9MZW5ndGggNzEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0tbR
1dM3MDQyNjE1M7ewtLICCDAAjNEG6gplbmRzdHJlYW0NZW5kb2JqDTM2MCAwIG9iag08PCAv
VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0
c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyNCAwIFIgL0xlbmd0aCA1NSAvRmlsdGVy
IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQ
lJKWkZWTV1BUUlZRVVPX0NTSAggwADeZA7IKZW5kc3RyZWFtDWVuZG9iag0zNjEgMCBvYmoN
PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OCAvSGVpZ2h0IDEg
L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjMgMCBSIC9MZW5ndGggNjkgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYR
FROXkJSSlpGVk1dQVFJWUVVT19DU0tbR1dM3MDQyNjE1M7ewAAgwAH82BnUKZW5kc3RyZWFt
DWVuZG9iag0zNjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X
aWR0aCA0MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTIg
MCBSIC9MZW5ndGggNTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRi
ZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVTV9XQAAgwADPaA4IKZW5kc3Ry
ZWFtDWVuZG9iag0zNjMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl
IC9XaWR0aCA1NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug
MTEgMCBSIC9MZW5ndGggNjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli
YGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0tbR1dM3MDQyNjE1
MwMIMABygwYECmVuZHN0cmVhbQ1lbmRvYmoNMzY0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0
IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50
IDggDS9Db2xvclNwYWNlIDEzIDAgUiAvTGVuZ3RoIDUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFV
U1cHCDAALQADNAplbmRzdHJlYW0NZW5kb2JqDTM2NSAwIG9iag08PCAvVHlwZSAvWE9iamVj
dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu
dCA4IA0vQ29sb3JTcGFjZSAxNiAwIFIgL0xlbmd0aCA2MyAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZR
VVPX0NTS1tHV0zcwNDICCDAAW7UFLgplbmRzdHJlYW0NZW5kb2JqDTM2NiAwIG9iag08PCAv
VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM4IC9IZWlnaHQgMSAvQml0
c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNSAwIFIgL0xlbmd0aCA0OSAvRmlsdGVy
IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQ
lJKWkZWTV1BUUlZRAQgwACPYAr8KZW5kc3RyZWFtDWVuZG9iag0zNjcgMCBvYmoNPDwgL1R5
cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0OCAvSGVpZ2h0IDEgL0JpdHNQ
ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTQgMCBSIC9MZW5ndGggNTkgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4ebl4xcQFBIWERUTl5CU
kpaRlZNXUFRSVlFVU9fQ1NLW0dUFCDAARY4ERAplbmRzdHJlYW0NZW5kb2JqDTM2OCAwIG9i
ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM1IC9IZWlnaHQg
MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAzOSAwIFIgL0xlbmd0aCA0NiAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQS
FhEVE5eQlJKWkZWTV1BUBAgwABwGAlMKZW5kc3RyZWFtDWVuZG9iag0zNjkgMCBvYmoNPDwg
L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0Jp
dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNDAgMCBSIC9MZW5ndGggNTUgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROX
kJSSlpGVk1dQVFJWUVVT19DU0gIIMAA3mQOyCmVuZHN0cmVhbQ1lbmRvYmoNMzcwIDAgb2Jq
DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIgL0hlaWdodCAx
IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDM3IDAgUiAvTGVuZ3RoIDQzIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIW
ERUTl5CUkpaRlZMDCDAAFW8B8AplbmRzdHJlYW0NZW5kb2JqDTM3MSAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM4IC9IZWlnaHQgMSAvQml0c1Bl
ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0MSAwIFIgL0xlbmd0aCA0OSAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKW
kZWTV1BUUlZRAQgwACPYAr8KZW5kc3RyZWFtDWVuZG9iag0zNzIgMCBvYmoNPDwgL1R5cGUg
L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNyAvSGVpZ2h0IDEgL0JpdHNQZXJD
b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE1IDAgUiAvTGVuZ3RoIDk2IC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAFEArv/j9dnR1tHe1e3s6ff28v3v6Pfj4Ozb1uTU
zt3JwtHAvcy8tsWzrLymobGfmaeWj5+Lh5aEfo56d4J1cn5rY3VfWWpWTmNPSVxBQU5rf2Jr
f2ICDADqlTR2CmVuZHN0cmVhbQ1lbmRvYmoNMzczIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0
IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50
IDggDS9Db2xvclNwYWNlIDQ1IDAgUiAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZMDCDAAFW8B
8AplbmRzdHJlYW0NZW5kb2JqDTM3NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw
ZSAvSW1hZ2UgL1dpZHRoIDIwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s
b3JTcGFjZSAxMTUgMCBSIC9MZW5ndGggNzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIkAPADD//P/8ej83+Xv4eDc6dnQ4tDK2MW+zb67x7ewwLCouKeer5+WqJWNnYqE
lIJ7jHtzg3NxfHV8dqG8kaG8kQIMAIWxKZQKZW5kc3RyZWFtDWVuZG9iag0zNzUgMCBvYmoN
PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMCAvSGVpZ2h0IDEg
L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE1IDAgUiAvTGVuZ3RoIDc1IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJADwAw//w//Dn+9/d987T58nL2snJ
18e9usW2r76xqbmppbKhoa2fl6eUjJ2MmJiPmo+RloygwJSz1afL4cHL4cECDAB+viu6CmVu
ZHN0cmVhbQ1lbmRvYmoNMzc2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J
bWFnZSAvV2lkdGggMTIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw
YWNlIDExNSAwIFIgL0xlbmd0aCA1MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiQAkANv/8//x7Pzm6frg3/jQ2e7N2e3J1OXH1ejJ1uzL4vPa6Pje6PjeAgwAVZkf/Qpl
bmRzdHJlYW0NZW5kb2JqDTM3NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv
SW1hZ2UgL1dpZHRoIDE3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT
cGFjZSAxMTUgMCBSIC9MZW5ndGggNjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSIkAMwDM//P3+OLt6Mvg5cDV57TF6K2966297q2+76q27qeu7Km17Ka346q62rDF1L3W
09fp3tfp3gIMAEERKVAKZW5kc3RyZWFtDWVuZG9iag0zNzggMCBvYmoNPDwgL1R5cGUgL1hP
YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSAxMTUgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIn68v/L9/8/3nx9AhBgACt4CJsKZW5kc3RyZWFtDWVuZG9i
ag0zNzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAx
OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE1IDAgUiAv
TGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJevb205k7r7ce
/rRm67+1W//jQuu2/V+69vuC9Xc2nz4LRAABBgCx4yr4CmVuZHN0cmVhbQ1lbmRvYmoNMzgw
IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzAgL0hl
aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExNSAwIFIgL0xlbmd0
aCA1MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXr1/tOZ268Pnvq+afe/
NVv+r91KJlq39f/KbX/mr383b/WVJTuPAhFAgAEA5JxHNwplbmRzdHJlYW0NZW5kb2JqDTM4
MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxIC9I
ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTUgMCBSIC9MZW5n
dGggMzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl68u7V1qMvV2/5v3Yr
1RDQtDmrrgIRQIABAKA9SYsKZW5kc3RyZWFtDWVuZG9iag0zODIgMCBvYmoNPDwgL1R5cGUg
L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzNyAvSGVpZ2h0IDEgL0JpdHNQZXJD
b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTEzIDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYsYLWFjZ2AACDAAHmwBzCmVuZHN0cmVhbQ1l
bmRvYmoNMzgzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggNDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExMiAw
IFIgL0xlbmd0aCAxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZCIK
MLOwAAQYAAcYAFkKZW5kc3RyZWFtDWVuZG9iag0zODQgMCBvYmoNPDwgL1R5cGUgL1hPYmpl
Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l
bnQgOCANL0NvbG9yU3BhY2UgODkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIliYGTCA5hZmJgAAgwABG0ARQplbmRzdHJlYW0NZW5kb2JqDTM4
NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUyIC9I
ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA5OSAwIFIgL0xlbmd0
aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+DkYsIH
uLh5ePn4+PgFBIWEAAIMABP1AR4KZW5kc3RyZWFtDWVuZG9iag0zODYgMCBvYmoNPDwgL1R5
cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzOCAvSGVpZ2h0IDEgL0JpdHNQ
ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgOTEgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmHFBdjYOTi5uHl4AAIMAAzwANMKZW5k
c3RyZWFtDWVuZG9iag0zODcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA0MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgOTIgMCBSIC9MZW5ndGggMzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIliYGRiZmFlY+fg5OLmQQe8fPwCrKysgkJMTAABBgAbagF/CmVuZHN0cmVhbQ1lbmRvYmoN
Mzg4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTUg
L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDk2IDAgUiAvTGVu
Z3RoIDUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmJiZmFlY2Nj
5+Dk4uZhZkIDvHz8AoJMQsIiQCVsomLigkxMEhIAAQYAIK8BpwplbmRzdHJlYW0NZW5kb2Jq
DTM4OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0
IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMjAgMCBSIC9M
ZW5ndGggNDIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQCAmYWVjYo
YOfgZOLiYmLi5OaBCPDy8YOUMAkIAAQYABPsARAKZW5kc3RyZWFtDWVuZG9iag0zOTAgMCBv
YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OCAvSGVpZ2h0
IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTI1IDAgUiAvTGVuZ3RoIDQ1
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkAgNmFlY2KGDn4OTiZoID
Hl4+NjZ+AUGwnJCwCERUVBQgwAAiXAF7CmVuZHN0cmVhbQ1lbmRvYmoNMzkxIDAgb2JqDTw8
IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjAgL0hlaWdodCAxIC9C
aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEzMSAwIFIgL0xlbmd0aCA0MCAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZIICZhZWNhhg5+Dkgolz8/DChPn4
BeDCTIKCAAEGACC+AUUKZW5kc3RyZWFtDWVuZG9iag0zOTIgMCBvYmoNPDwgL1R5cGUgL1hP
YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w
b25lbnQgOCANL0NvbG9yU3BhY2UgMzIgMCBSIC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSCAGYWVjYQYOfg5GJi4mLi5uFlgwA+fgEuiBpBQYAA
AwAV1wEfCmVuZHN0cmVhbQ1lbmRvYmoNMzkzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T
dWJ0eXBlIC9JbWFnZSAvV2lkdGggNjIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg
DS9Db2xvclNwYWNlIDEzNiAwIFIgL0xlbmd0aCAzOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIiWJgZIIDZhZWNghg5+BECHNxs8EADy8fQpyJnx8gwAAeQQEeCmVuZHN0
cmVhbQ1lbmRvYmoNMzk0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggNjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl
IDM0IDAgUiAvTGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ
YmBkQgBmFlY2NjZ2DiDBxsnFDRHk4WWDAz5+AUFmhHohIYAAAwAjwgFVCmVuZHN0cmVhbQ1l
bmRvYmoNMzk1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggNjQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDQzIDAg
UiAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQgLM
LKxsbOwcnGwgwMXNAxLj5eNngwIBQSFhEWT1oqIAAQYAKNoBhwplbmRzdHJlYW0NZW5kb2Jq
DTM5NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ5
IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MyAwIFIgL0xl
bmd0aCA0NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZIIBZhZWNnYO
Ti4uLm4eXj5+AUEgS0hYRFRMXAKuRlISIMAAIaUBswplbmRzdHJlYW0NZW5kb2JqDTM5NyAw
IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY1IC9IZWln
aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAzMCAwIFIgL0xlbmd0aCA0
NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIBzCysbOxMHJxc3CDA
w8vHxC8AZAgKCYuIsjEzoQMxMYAAAwAwMwGqCmVuZHN0cmVhbQ1lbmRvYmoNMzk4IDAgb2Jq
DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDkgL0hlaWdodCAx
IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDI4IDAgUiAvTGVuZ3RoIDM3IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBEAkyMjMwsrGzs7BycLCxc7Nw8
vHzMjGgAIMAADwgAoAplbmRzdHJlYW0NZW5kb2JqDTM5OSAwIG9iag08PCAvVHlwZSAvWE9i
amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSAzMSAwIFIgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIiWJgZMIKmFlY2djYOZiYOLm4eXj5ePmxKxMQAAgwABzuAQYK
ZW5kc3RyZWFtDWVuZG9iag00MDAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg
L0ltYWdlIC9XaWR0aCA0OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y
U3BhY2UgMzUgMCBSIC9MZW5ndGggMzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSIliYGRCA8wsrGzsTEwcnFzc6FJMTDw8AAEGAA2WAKEKZW5kc3RyZWFtDWVuZG9iag00
MDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAv
SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzMgMCBSIC9MZW5n
dGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRixg5YWNnYWXDI
IQAHB0CAAQAaUgDWCmVuZHN0cmVhbQ1lbmRvYmoNNDAyIDAgb2JqDTw8IC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDM2IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJYmBkwgGYWViZMUXZ2AACDAAKPABxCmVuZHN0cmVhbQ1lbmRv
YmoNNDAzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg
NjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEyOSAwIFIg
L0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGImAFhY
2dg5cElycgIEGAAaXgDcCmVuZHN0cmVhbQ1lbmRvYmoNNDA0IDAgb2JqDTw8IC9UeXBlIC9Y
T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29t
cG9uZW50IDggDS9Db2xvclNwYWNlIDEyMiAwIFIgL0xlbmd0aCAzNiAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJGBSysbOwcnMxc3Dy8fPwCaJLMgoIAAQYAFmcB
CAplbmRzdHJlYW0NZW5kb2JqDTQwNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw
ZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s
b3JTcGFjZSAxMjcgMCBSIC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIliYGRixgQsrGzsHJxc3DzMLLx8/AICAoJCwliUAYGICECAAQAs3QGGCmVuZHN0
cmVhbQ1lbmRvYmoNNDA2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl
IDEzNCAwIFIgL0xlbmd0aCAzOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
iWJgZGJGAiysbOwcnFzcPLx8/JycnAKCQsyoQFgYIMAAG0EBOwplbmRzdHJlYW0NZW5kb2Jq
DTQwNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2
IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMzMgMCBSIC9M
ZW5ndGggNTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiRgYsrGzs
HJxc3Dw8PLx8/CARAUEhIIdHWESURUxcQlIKVbm0NECAAQA+FAI9CmVuZHN0cmVhbQ1lbmRv
YmoNNDA4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg
NTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEzMCAwIFIg
L0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGIGAxZW
NnYOTi4Q4ObhBQow8fED2QKCQsIiolA1QCAmBhBgACHwAZEKZW5kc3RyZWFtDWVuZG9iag00
MDkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAv
SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTM1IDAgUiAvTGVu
Z3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmaBAlY2dg5O
Ljjg5oGK8/LxgwUEBIGEkDALEhARFQUIMAA79wIPCmVuZHN0cmVhbQ1lbmRvYmoNNDEwIDAg
b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdo
dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCA0
MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGIGAxZWNnYo4OCECHFx
80AEePn4ISLMAoKCAAEGABnaATwKZW5kc3RyZWFtDWVuZG9iag00MTEgMCBvYmoNPDwgL1R5
cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQ
ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTI0IDAgUiAvTGVuZ3RoIDQzIC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmaBAVY2dg5OGODihouz8PDy8cPEBQQR
4kLCIiIAAQYANWIB5wplbmRzdHJlYW0NZW5kb2JqDTQxMiAwIG9iag08PCAvVHlwZSAvWE9i
amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSAxMjYgMCBSIC9MZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZoEAVjZ2MODg5IKKsHDzQIR4+SB8fgFBQYAAAwAa
YAFICmVuZHN0cmVhbQ1lbmRvYmoNNDEzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0
eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D
b2xvclNwYWNlIDEyOCAwIFIgL0xlbmd0aCA0NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN
c3RyZWFtDQpIiWJgZGJmYYUCNnYOTi4o4OZhRQBePn4BmISgkDBMWERUTFwcIMAAPSgCRApl
bmRzdHJlYW0NZW5kb2JqDTQxNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv
SW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT
cGFjZSAxMzcgMCBSIC9MZW5ndGggNDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSIliYGRiZmEFAhY2dg4w4OTiZoUAHl4OKODjFwAJCAoJi4gABBgAH7cBmQplbmRzdHJl
YW0NZW5kb2JqDTQxNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug
L1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAx
MzIgMCBSIC9MZW5ndGggNTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli
YGRiZmFlAwF2Dk4ubiDg4QUSfPxsCCAgKCTMDQciomIQYXEJSSlpaYAAAwBJVgLECmVuZHN0
cmVhbQ1lbmRvYmoNNDE2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl
IDk0IDAgUiAvTGVuZ3RoIDUzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ
YmBkYmZhZWPn4OTi5ubm4eXj5hdggwJBIWERUTFuEBCXYGVjk5SSlpGVBQgwAC5YAmoKZW5k
c3RyZWFtDWVuZG9iag00MTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgNTggMCBSIC9MZW5ndGggNjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIliYGRiZmFlY+fg5OLm4QUCPn4BQSFhEVFBDlQgJi4hKSUtA1IiKycPFFBQVFJWUVVTAwgw
AGPOBAgKZW5kc3RyZWFtDWVuZG9iag00MTggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1
YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN
L0NvbG9yU3BhY2UgOTMgMCBSIC9MZW5ndGggNTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g
DXN0cmVhbQ0KSIliYGRiZmFlY+fg5OIGAR5ePn4BQSFhEQEMwC8qJi4hKQVUJC3DIcAhKyev
oKikrAwQYABs0AQ2CmVuZHN0cmVhbQ1lbmRvYmoNNDE5IDAgb2JqDTw8IC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDk1IDAgUiAvTGVuZ3RoIDQ0IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTk4ubhxQL4+AUEhYRFRMXEJSSlpGVkAAIM
ADMsArMKZW5kc3RyZWFtDWVuZG9iag00MjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1
YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN
L0NvbG9yU3BhY2UgOTggMCBSIC9MZW5ndGggNDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g
DXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAkAIS4hEVExcQFJSSlpGVk5eTlAQIMAHEg
BDoKZW5kc3RyZWFtDWVuZG9iag00MjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgOTcgMCBSIC9MZW5ndGggMzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIliYGRiZmFlY+fg5OLm4cUJ+PgFBIWERUTFxMUBAgwAMbQCcQplbmRzdHJlYW0N
ZW5kb2JqDTQyMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp
ZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTgg
MCBSIC9MZW5ndGggNDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRi
ZmFlY+fg5OLm4eUjDvDw8AsICgmLiIqJS0gABBgAYMwDcQplbmRzdHJlYW0NZW5kb2JqDTQy
MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9I
ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NiAwIFIgL0xlbmd0
aCAzNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4sYD
eHj5+AUEhYRFREUBAgwALBACJgplbmRzdHJlYW0NZW5kb2JqDTQyNCAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1Bl
ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NSAwIFIgL0xlbmd0aCA0NiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXIAgEhYRFRMXEJSSl
pGVk5eTlAQIMAG05BCAKZW5kc3RyZWFtDWVuZG9iag00MjUgMCBvYmoNPDwgL1R5cGUgL1hP
YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w
b25lbnQgOCANL0NvbG9yU3BhY2UgODcgMCBSIC9MZW5ndGggNDEgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4cUO+PgFBIWERUTFxCUkpaQAAgwA
MsYCmAplbmRzdHJlYW0NZW5kb2JqDTQyNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi
dHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v
Q29sb3JTcGFjZSA5MCAwIFIgL0xlbmd0aCA1MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN
c3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSxgNERMXEJSSlpGVk5eQVFJWUVVRVAQIM
AH0EBOYKZW5kc3RyZWFtDWVuZG9iag00MjcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1
YnR5cGUgL0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN
L0NvbG9yU3BhY2UgODggMCBSIC9MZW5ndGggNDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g
DXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxBEA0LCIqJi4hKSUtIysnLyCoqKAAEGAD3z
A1IKZW5kc3RyZWFtDWVuZG9iag00MjggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgMTAwIDAgUiAvTGVuZ3RoIDY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5BEA1LSMrJy8gqKSsoqqmrqGppa
2jq6evoGhoYAAQYAmfcGcgplbmRzdHJlYW0NZW5kb2JqDTQyOSAwIG9iag08PCAvVHlwZSAv
WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNv
bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTEgMCBSIC9MZW5ndGggNTggL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFQMDcQlJKWkZ
WTl5BUUlZRVVNXUNTS1tbYAAAwBLLARMCmVuZHN0cmVhbQ1lbmRvYmoNNDMwIDAgb2JqDTw8
IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9C
aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExMCAwIFIgL0xlbmd0aCA3NyAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEV
E5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbN3cAAIMAC7YghhCmVu
ZHN0cmVhbQ1lbmRvYmoNNDMxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J
bWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw
YWNlIDExNiAwIFIgL0xlbmd0aCA2MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcw
AAgwAFGKBMkKZW5kc3RyZWFtDWVuZG9iag00MzIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg
L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg
OCANL0NvbG9yU3BhY2UgMTE3IDAgUiAvTGVuZ3RoIDc3IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFV
U9fQ1NLW0dXTNzA0MjYxNTO3sLSytrG1s3dwAAgwALtiCGEKZW5kc3RyZWFtDWVuZG9iag00
MzMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MCAv
SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE0IDAgUiAvTGVu
Z3RoIDYxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi
5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXTNzAACDAAUYoEyQplbmRzdHJl
YW0NZW5kb2JqDTQzNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug
L1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAx
MDkgMCBSIC9MZW5ndGggNzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli
YGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0tbR1dM3MDQyNjE1
M7ewtLK2sbWzd3AACDAAu2IIYQplbmRzdHJlYW0NZW5kb2JqDTQzNSAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1Bl
ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMDMgMCBSIC9MZW5ndGggNjEgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSS
lpGVk1dQVFJWUVVT19DU0tbR1dM3MAAIMABRigTJCmVuZHN0cmVhbQ1lbmRvYmoNNDM2IDAg
b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjUgL0hlaWdo
dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwMiAwIFIgL0xlbmd0aCA3
NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMX
EBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbO3BwgwALMA
CCAKZW5kc3RyZWFtDWVuZG9iag00MzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA0OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgMTAxIDAgUiAvTGVuZ3RoIDYwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW
0dXT1wcIMABMwASYCmVuZHN0cmVhbQ1lbmRvYmoNNDM4IDAgb2JqDTw8IC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDEwNyAwIFIgL0xlbmd0aCA3NiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BU
UlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbO3BwgwALMACCAKZW5kc3RyZWFtDWVuZG9i
ag00MzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0
OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTA2IDAgUiAv
TGVuZ3RoIDYwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn
4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXT1wcIMABMwASYCmVuZHN0
cmVhbQ1lbmRvYmoNNDQwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggNjQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl
IDEwNSAwIFIgL0xlbmd0aCA3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
iWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2
MTUzt7C0sraxtbMDCDAAqt8H4AplbmRzdHJlYW0NZW5kb2JqDTQ0MSAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYzIC9IZWlnaHQgMSAvQml0c1Bl
ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2OSAwIFIgL0xlbmd0aCA3NCAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKW
kZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtQUIMACi/gehCmVuZHN0cmVhbQ1l
bmRvYmoNNDQyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggNDcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIxIDAg
UiAvTGVuZ3RoIDU4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZh
ZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dUFCDAAQ74EOQplbmRz
dHJlYW0NZW5kb2JqDTQ0MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h
Z2UgL1dpZHRoIDYyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj
ZSAyMCAwIFIgL0xlbmd0aCA3MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
iWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2
MTUzt7C0sraxAQgwAJtcB2MKZW5kc3RyZWFtDWVuZG9iag00NDQgMCBvYmoNPDwgL1R5cGUg
L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NiAvSGVpZ2h0IDEgL0JpdHNQZXJD
b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjIgMCBSIC9MZW5ndGggNTcgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGV
k1dQVFJWUVVT19DU0tbRAQgwAD+EBAsKZW5kc3RyZWFtDWVuZG9iag00NDUgMCBvYmoNPDwg
L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2MCAvSGVpZ2h0IDEgL0Jp
dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjUgMCBSIC9MZW5ndGggNzEgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROX
kJSSlpGVk1dQVFJWUVVT19DU0tbR1dM3MDQyNjE1M7ewtLICCDAAjNEG6gplbmRzdHJlYW0N
ZW5kb2JqDTQ0NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp
ZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyNCAw
IFIgL0xlbmd0aCA1NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJm
YWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTSAggwADeZA7IKZW5kc3Ry
ZWFtDWVuZG9iag00NDcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl
IC9XaWR0aCA1OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug
MjMgMCBSIC9MZW5ndGggNjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli
YGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0tbR1dM3MDQyNjE1
M7ewAAgwAH82BnUKZW5kc3RyZWFtDWVuZG9iag00NDggMCBvYmoNPDwgL1R5cGUgL1hPYmpl
Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l
bnQgOCANL0NvbG9yU3BhY2UgMTMgMCBSIC9MZW5ndGggNTIgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJW
UVVTVwcIMAAtAAM0CmVuZHN0cmVhbQ1lbmRvYmoNNDQ5IDAgb2JqDTw8IC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u
ZW50IDggDS9Db2xvclNwYWNlIDExIDAgUiAvTGVuZ3RoIDY3IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRS
VlFVU9fQ1NLW0dXTNzA0MjYxNTMDCDAAcoMGBAplbmRzdHJlYW0NZW5kb2JqDTQ1MCAwIG9i
ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUyIC9IZWlnaHQg
MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNiAwIFIgL0xlbmd0aCA2MyAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQS
FhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDICCDAAW7UFLgplbmRzdHJlYW0NZW5k
b2JqDTQ1MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo
IDM4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNSAwIFIg
L0xlbmd0aCA0OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj
5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRAQgwACPYAr8KZW5kc3RyZWFtDWVuZG9i
ag00NTIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0
OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTQgMCBSIC9M
ZW5ndGggNTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg
5OLm4ebl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dUFCDAARY4ERAplbmRzdHJl
YW0NZW5kb2JqDTQ1MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug
L1dpZHRoIDM1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAz
OSAwIFIgL0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg
ZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUBAgwABwGAlMKZW5kc3RyZWFtDWVu
ZG9iag00NTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0
aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNDAgMCBS
IC9MZW5ndGggNTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFl
Y+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0gIIMAA3mQOyCmVuZHN0cmVh
bQ1lbmRvYmoNNDU1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv
V2lkdGggMzIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDM3
IDAgUiAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk
YmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZMDCDAAFW8B8AplbmRzdHJlYW0NZW5kb2Jq
DTQ1NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM4
IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0MSAwIFIgL0xl
bmd0aCA0OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk
4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRAQgwACPYAr8KZW5kc3RyZWFtDWVuZG9iag00
NTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNyAv
SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE1IDAgUiAvTGVu
Z3RoIDk2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAFEArv/j9dnR1tHe
1e3s6ff28v3v6Pfj4Ozb1uTUzt3JwtHAvcy8tsWzrLymobGfmaeWj5+Lh5aEfo56d4J1cn5r
Y3VfWWpWTmNPSVxBQU5rf2Jrf2ICDADqlTR2CmVuZHN0cmVhbQ1lbmRvYmoNNDU4IDAgb2Jq
DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIgL0hlaWdodCAx
IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDQ1IDAgUiAvTGVuZ3RoIDQzIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIW
ERUTl5CUkpaRlZMDCDAAFW8B8AplbmRzdHJlYW0NZW5kb2JqDTQ1OSAwIG9iag08PCAvVHlw
ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIwIC9IZWlnaHQgMSAvQml0c1Bl
ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTUgMCBSIC9MZW5ndGggNzUgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAPADD//P/8ej83+Xv4eDc6dnQ4tDK2MW+zb67
x7ewwLCouKeer5+WqJWNnYqElIJ7jHtzg3NxfHV8dqG8kaG8kQIMAIWxKZQKZW5kc3RyZWFt
DWVuZG9iag00NjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X
aWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTUg
MCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68v/L
t//fv/28BxBgACuOCKEKZW5kc3RyZWFtDWVuZG9iag00NjEgMCBvYmoNPDwgL1R5cGUgL1hP
YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSAxMTUgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIn68v/Ll//f/v9/BRBgACuxCLkKZW5kc3RyZWFtDWVuZG9i
ag00NjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAz
IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTUgMCBSIC9M
ZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68v/L9//f3v16
DhBgACuDCKMKZW5kc3RyZWFtDWVuZG9iag00NjMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg
L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg
OCANL0NvbG9yU3BhY2UgODMgMCBSIC9MZW5ndGggNDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4gDXN0cmVhbQ0KSIliYGSCAWYWVjZ2Dk4uLi5uHl4+fgFBIEtIWERUTFwCrkZSEiDAACGl
AbMKZW5kc3RyZWFtDWVuZG9iag00NjQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA2NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgMzAgMCBSIC9MZW5ndGggNDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIliYGRCAcwsrGzsTBycXNwgwMPLx8QvAGQICgmLiLIxM6EDMTGAAAMAMDMBqgpl
bmRzdHJlYW0NZW5kb2JqDTQ2NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv
SW1hZ2UgL1dpZHRoIDQ5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT
cGFjZSAyOCAwIFIgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiWJgRAJMjIzMLKxs7OwcnCwsXOzcPLx8zIxoACDAAA8IAKAKZW5kc3RyZWFtDWVuZG9i
ag00NjYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2
NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzMgMCBSIC9M
ZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRixg5YWNnY
WXDIIQAHB0CAAQAaUgDWCmVuZHN0cmVhbQ1lbmRvYmoNNDY3IDAgb2JqDTw8IC9UeXBlIC9Y
T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29t
cG9uZW50IDggDS9Db2xvclNwYWNlIDM2IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkwgGYWViZMUXZ2AACDAAKPABxCmVuZHN0cmVhbQ1l
bmRvYmoNNDY4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEyOSAw
IFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGIm
AFhY2dg5cElycgIEGAAaXgDcCmVuZHN0cmVhbQ1lbmRvYmoNNDY5IDAgb2JqDTw8IC9UeXBl
IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVy
Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEyMiAwIFIgL0xlbmd0aCAzNiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJGBSysbOwcnMxc3Dy8fPwCaJLMgoIAAQYA
FmcBCAplbmRzdHJlYW0NZW5kb2JqDTQ3MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi
dHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v
Q29sb3JTcGFjZSAxMjcgMCBSIC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g
DXN0cmVhbQ0KSIliYGRixgQsrGzsHJxc3DzMLLx8/AICAoJCwliUAYGICECAAQAs3QGGCmVu
ZHN0cmVhbQ1lbmRvYmoNNDcxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J
bWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw
YWNlIDEzNCAwIFIgL0xlbmd0aCAzOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiWJgZGJGAiysbOwcnFzcPLx8/JycnAKCQsyoQFgYIMAAG0EBOwplbmRzdHJlYW0NZW5k
b2JqDTQ3MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo
IDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMzMgMCBS
IC9MZW5ndGggNTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiRgYs
rGzsHJxc3Dw8PLx8/CARAUEhIIdHWESURUxcQlIKVbm0NECAAQA+FAI9CmVuZHN0cmVhbQ1l
bmRvYmoNNDczIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEzMCAw
IFIgL0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGIG
AxZWNnYOTi4Q4ObhBQow8fED2QKCQsIiolA1QCAmBhBgACHwAZEKZW5kc3RyZWFtDWVuZG9i
ag00NzQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2
NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTM1IDAgUiAv
TGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmaBAlY2
dg5OLjjg5oGK8/LxgwUEBIGEkDALEhARFQUIMAA79wIPCmVuZHN0cmVhbQ1lbmRvYmoNNDc1
IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTAgL0hl
aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0
aCA0MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGIGAxZWNnYo4OCE
CHFx80AEePn4ISLMAoKCAAEGABnaATwKZW5kc3RyZWFtDWVuZG9iag00NzYgMCBvYmoNPDwg
L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0Jp
dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTI0IDAgUiAvTGVuZ3RoIDQzIC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmaBAVY2dg5OGODihouz8PDy8cPE
BQQR4kLCIiIAAQYANWIB5wplbmRzdHJlYW0NZW5kb2JqDTQ3NyAwIG9iag08PCAvVHlwZSAv
WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNv
bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMjYgMCBSIC9MZW5ndGggNDAgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZoEAVjZ2MODg5IKKsHDzQIR4+SB8fgFBQYAA
AwAaYAFICmVuZHN0cmVhbQ1lbmRvYmoNNDc4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T
dWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg
DS9Db2xvclNwYWNlIDEyOCAwIFIgL0xlbmd0aCA0NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIiWJgZGJmYYUCNnYOTi4o4OZhRQBePn4BmISgkDBMWERUTFwcIMAAPSgC
RAplbmRzdHJlYW0NZW5kb2JqDTQ3OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw
ZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s
b3JTcGFjZSAxMzcgMCBSIC9MZW5ndGggNDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSIliYGRiZmEFAhY2dg4w4OTiZoUAHl4OKODjFwAJCAoJi4gABBgAH7cBmQplbmRz
dHJlYW0NZW5kb2JqDTQ4MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h
Z2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj
ZSAxMzIgMCBSIC9MZW5ndGggNTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIliYGRiZmFlAwF2Dk4ubiDg4QUSfPxsCCAgKCTMDQciomIQYXEJSSlpaYAAAwBJVgLECmVu
ZHN0cmVhbQ1lbmRvYmoNNDgxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J
bWFnZSAvV2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw
YWNlIDk0IDAgUiAvTGVuZ3RoIDUzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJYmBkYmZhZWPn4OTi5ubm4eXj5hdggwJBIWERUTFuEBCXYGVjk5SSlpGVBQgwAC5YAmoK
ZW5kc3RyZWFtDWVuZG9iag00ODIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg
L0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y
U3BhY2UgOTUgMCBSIC9MZW5ndGggNDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSIliYGRiZmFlY+fg5OTi5uHFAvj4BQSFhEVExcQlJKWkZWQAAgwAMywCswplbmRzdHJl
YW0NZW5kb2JqDTQ4MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug
L1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA5
MyAwIFIgL0xlbmd0aCA1OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg
ZGJmYWVj5+Dk4gYBHl4+fgFBIWERAQzALyomLiEpBVQkLcMhwCErJ6+gqKSsDBBgAGzQBDYK
ZW5kc3RyZWFtDWVuZG9iag00ODQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg
L0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y
U3BhY2UgOTggMCBSIC9MZW5ndGggNDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAkAIS4hEVExcQFJSSlpGVk5eTlAQIMAHEgBDoKZW5k
c3RyZWFtDWVuZG9iag00ODUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgOTcgMCBSIC9MZW5ndGggMzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIliYGRiZmFlY+fg5OLm4cUJ+PgFBIWERUTFxMUBAgwAMbQCcQplbmRzdHJlYW0NZW5kb2Jq
DTQ4NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2
IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTggMCBSIC9M
ZW5ndGggNDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg
5OLm4eUjDvDw8AsICgmLiIqJS0gABBgAYMwDcQplbmRzdHJlYW0NZW5kb2JqDTQ4NyAwIG9i
ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQg
MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NiAwIFIgL0xlbmd0aCAzNiAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4sYDeHj5+AUE
hYRFREUBAgwALBACJgplbmRzdHJlYW0NZW5kb2JqDTQ4OCAwIG9iag08PCAvVHlwZSAvWE9i
amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSA4NSAwIFIgL0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXIAgEhYRFRMXEJSSlpGVk5eTl
AQIMAG05BCAKZW5kc3RyZWFtDWVuZG9iag00ODkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg
L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg
OCANL0NvbG9yU3BhY2UgODcgMCBSIC9MZW5ndGggNDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4cUO+PgFBIWERUTFxCUkpaQAAgwAMsYCmApl
bmRzdHJlYW0NZW5kb2JqDTQ5MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv
SW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT
cGFjZSA5MCAwIFIgL0xlbmd0aCA1MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSxgNERMXEJSSlpGVk5eQVFJWUVVRVAQIMAH0EBOYK
ZW5kc3RyZWFtDWVuZG9iag00OTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg
L0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y
U3BhY2UgODggMCBSIC9MZW5ndGggNDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSIliYGRiZmFlY+fg5OLm4eXjFxBEA0LCIqJi4hKSUtIysnLyCoqKAAEGAD3zA1IKZW5k
c3RyZWFtDWVuZG9iag00OTIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgMTAwIDAgUiAvTGVuZ3RoIDY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5BEA1LSMrJy8gqKSsoqqmrqGppa2jq6evoG
hoYAAQYAmfcGcgplbmRzdHJlYW0NZW5kb2JqDTQ5MyAwIG9iag08PCAvVHlwZSAvWE9iamVj
dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu
dCA4IA0vQ29sb3JTcGFjZSAxMTEgMCBSIC9MZW5ndGggNTggL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFQMDcQlJKWkZWTl5BUUl
ZRVVNXUNTS1tbYAAAwBLLARMCmVuZHN0cmVhbQ1lbmRvYmoNNDk0IDAgb2JqDTw8IC9UeXBl
IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVy
Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExMCAwIFIgL0xlbmd0aCA3NyAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKW
kZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbN3cAAIMAC7YghhCmVuZHN0cmVh
bQ1lbmRvYmoNNDk1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv
V2lkdGggNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEx
NiAwIFIgL0xlbmd0aCA2MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg
ZGJmYWVj5+Dk4ubh5eMXEBQSFhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwAAgwAFGK
BMkKZW5kc3RyZWFtDWVuZG9iag00OTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv
bG9yU3BhY2UgMTE3IDAgUiAvTGVuZ3RoIDc3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW
0dXTNzA0MjYxNTO3sLSytrG1s3dwAAgwALtiCGEKZW5kc3RyZWFtDWVuZG9iag00OTcgMCBv
YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MCAvSGVpZ2h0
IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE0IDAgUiAvTGVuZ3RoIDYx
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmZhZWPn4OTi5uHl4xcQ
FBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXTNzAACDAAUYoEyQplbmRzdHJlYW0NZW5k
b2JqDTQ5OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo
IDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMDkgMCBS
IC9MZW5ndGggNzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFl
Y+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQVFJWUVVT19DU0tbR1dM3MDQyNjE1M7ewtLK2
sbWzd3AACDAAu2IIYQplbmRzdHJlYW0NZW5kb2JqDTQ5OSAwIG9iag08PCAvVHlwZSAvWE9i
amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv
bmVudCA4IA0vQ29sb3JTcGFjZSAxMDMgMCBSIC9MZW5ndGggNjEgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXkJSSlpGVk1dQ
VFJWUVVT19DU0tbR1dM3MAAIMABRigTJCmVuZHN0cmVhbQ1lbmRvYmoNNTAwIDAgb2JqDTw8
IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjUgL0hlaWdodCAxIC9C
aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwNyAwIFIgL0xlbmd0aCA3NiAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYWVj5+Dk4ubh5eMXEBQSFhEV
E5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbO3BwgwALMACCAKZW5k
c3RyZWFtDWVuZG9iag01MDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCA0OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh
Y2UgMTA2IDAgUiAvTGVuZ3RoIDYwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJYmBkYmZhZWPn4OTi5uHl4xcQFBIWERUTl5CUkpaRlZNXUFRSVlFVU9fQ1NLW0dXT1wcI
MABMwASYCmVuZHN0cmVhbQ1lbmRvYmoNNTAyIDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRl
IA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTEgMCBv
YmoNPDwgDS9TIC9EIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9OdW1zIFsgMCAxIDAgUiBd
IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyA4IDAgUiBd
IA0vQ291bnQgMSANPj4gDWVuZG9iag00IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIw
MDQwNDA2MTAyMDA1KzAyJzAwJykNL01vZERhdGUgKEQ6MjAwNDA0MDYxMDIwMDUrMDInMDAn
KQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDUuMC41IFwoV2luZG93c1wpKQ0vQXV0
aG9yIChicmlhbikNL0NyZWF0b3IgKFBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMikNL1RpdGxl
IChNaWNyb3NvZnQgUG93ZXJQb2ludCAtIDZ0bzR0YXAucHB0KQ0+PiANZW5kb2JqDTUgMCBv
YmoNPDwgL1R5cGUgL01ldGFkYXRhIC9TdWJ0eXBlIC9YTUwgL0xlbmd0aCAxMDgyID4+IA1z
dHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlk
JyBieXRlcz0nMTA4MSc/PjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcv
MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5j
b20vaVgvMS4wLyc+PHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4bWxucz0naHR0cDovL25z
LmFkb2JlLmNvbS9wZGYvMS4zLycgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3Bk
Zi8xLjMvJyBwZGY6Q3JlYXRpb25EYXRlPScyMDA0LTA0LTA2VDA4OjIwOjA1WicgcGRmOk1v
ZERhdGU9JzIwMDQtMDQtMDZUMDg6MjA6MDVaJyBwZGY6UHJvZHVjZXI9J0Fjcm9iYXQgRGlz
dGlsbGVyIDUuMC41IChXaW5kb3dzKScgcGRmOkF1dGhvcj0nYnJpYW4nIHBkZjpDcmVhdG9y
PSdQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjInIHBkZjpUaXRsZT0nTWljcm9zb2Z0IFBvd2Vy
UG9pbnQgLSA2dG80dGFwLnBwdCcvPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5z
PSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4bWxuczp4YXA9J2h0dHA6Ly9ucy5h
ZG9iZS5jb20veGFwLzEuMC8nIHhhcDpDcmVhdGVEYXRlPScyMDA0LTA0LTA2VDA4OjIwOjA1
WicgeGFwOk1vZGlmeURhdGU9JzIwMDQtMDQtMDZUMDg6MjA6MDVaJyB4YXA6QXV0aG9yPSdi
cmlhbicgeGFwOk1ldGFkYXRhRGF0ZT0nMjAwNC0wNC0wNlQwODoyMDowNVonPjx4YXA6VGl0
bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5NaWNyb3NvZnQgUG93
ZXJQb2ludCAtIDZ0bzR0YXAucHB0PC9yZGY6bGk+PC9yZGY6QWx0PjwveGFwOlRpdGxlPjwv
cmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRw
Oi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9y
Zy9kYy9lbGVtZW50cy8xLjEvJyBkYzpjcmVhdG9yPSdicmlhbicgZGM6dGl0bGU9J01pY3Jv
c29mdCBQb3dlclBvaW50IC0gNnRvNHRhcC5wcHQnLz4KPC9yZGY6UkRGPjw/eHBhY2tldCBl
bmQ9J3InPz4KZW5kc3RyZWFtDWVuZG9iag14cmVmDTAgNiANMDAwMDAwMDAwMCA2NTUzNSBm
DQowMDAwMTM2NTA3IDAwMDAwIG4NCjAwMDAxMzY1MzcgMDAwMDAgbg0KMDAwMDEzNjU3OSAw
MDAwMCBuDQowMDAwMTM2NjQzIDAwMDAwIG4NCjAwMDAxMzY4ODUgMDAwMDAgbg0KdHJhaWxl
cg08PA0vU2l6ZSA2DS9JRFs8OGJmN2Y2MjgyM2FkNGQyYmYwZTg0MWJkMDg2ZGE0Yzc+PDMx
Y2MyOGZiYWQwM2FjMDc1N2I4ODFjODM3NDA0ZTQ3Pl0NPj4Nc3RhcnR4cmVmDTE3Mw0lJUVP
Rg0=
--------------98A5254CAD83EEECEA51E2F6--




From owner-v6ops@ops.ietf.org  Tue Apr  6 04:52:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21573
	for <v6ops-archive@lists.ietf.org>; Tue, 6 Apr 2004 04:52:21 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAmHn-000C5W-CC
	for v6ops-data@psg.com; Tue, 06 Apr 2004 08:50:23 +0000
Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAmHm-000C4p-55
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 08:50:22 +0000
Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1BAmHl-00042T-00
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 09:50:21 +0100
Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1BAmHk-00042A-00
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 09:50:20 +0100
Received: from zurich.ibm.com (sig-9-145-227-182.de.ibm.com [9.145.227.182])
	by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i368oMF122912
	for <v6ops@ops.ietf.org>; Tue, 6 Apr 2004 09:50:22 +0100
Message-ID: <40726F61.150C1257@zurich.ibm.com>
Date: Tue, 06 Apr 2004 10:50:41 +0200
From: Brian E Carpenter <brc@zurich.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: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D ACTION:draft-durand-v6ops-assisted-tunneling-requirements-00.txt
References: <200404011313.IAA10793@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> 4.2. Service Discovery
> 
>    In order to offer "plug & play", the non-authenticated mode needs to
>    discover the address of the server that will provide the tunnel
>    connectivity. This discovery must be automatic within an ISP network.

I wonder about this. Users are accustomed to entering a few magic numbers into
diallers to get a connection. For ADSL, I have to enter "p8,35" -- I have
no idea why (please don't tell me) but it really isn't a problem in my
life. If this requirement causes a lot of complexity, I would drop it.

> 7.3 ISATAP
> 
>    Similar considerations as Teredo, section 7.2, applies to Isatap.
>    However, as Isatap can not work accross NAT, it is of much less
>    interest in the framework of this document.

Perhaps you should say the same thing about 6to4.

   Brian



From owner-v6ops@ops.ietf.org  Tue Apr  6 09:18:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15030
	for <v6ops-archive@lists.ietf.org>; Tue, 6 Apr 2004 09:18:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAqPy-0001oq-U5
	for v6ops-data@psg.com; Tue, 06 Apr 2004 13:15:06 +0000
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAqPn-0001mX-35
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 13:14:55 +0000
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i36DEhn2023585;
	Tue, 6 Apr 2004 06:14:44 -0700 (PDT)
Received: from volzw2k ([161.44.65.208])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AHJ76417;
	Tue, 6 Apr 2004 09:14:42 -0400 (EDT)
From: "Bernie Volz" <volz@cisco.com>
To: <pekkas@netcore.fi>, <v6ops@ops.ietf.org>,
        "'Ralph Droms'" <rdroms@cisco.com>
Subject: RE: DHCP auth in unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt]
Date: Tue, 6 Apr 2004 09:14:41 -0400
Organization: Cisco
Message-ID: <001801c41bd9$1eea6ef0$d0412ca1@amer.cisco.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, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On Fri, 2 Apr 2004, Pekka Savola wrote:
>I'd maybe add here:
>
>      In a typical scenario, the link between the user and the ISP is 
>      point-to-point, set up using some (semi-)trusted mechanism, and 
>      DHCP authentication is not deemed necessary.  In some other 
>      cases, the link is shared between the users, but the customers
>      are isolated from each other using special techniques such as 
>      proxy ARP; in these scenarios, DHCP authentication may not be 
>      required either.  However, there are a few rather rare cases 
>      where the customers really share a network, and in such a 
>      network DHCP authentication is required; key management, 
>      however, may prove a challenge.

In these "few rather rare cases" aren't there bigger problems than just
DHCPv6? Many other protocols are subject to attacks if this link isn't
secure, so securing DHCPv6 doesn't really buy you much.

Key distribution / management is a challenge. That's one reason why the
DHCPv6 authentication mechanism is extensible - if and when better
mechanisms can be developed, they can be added. For example, perhaps
when SEND is adopted we can look at using some of its techniques to
either secure DHCPv6 multicast traffic OR add a new authentication
protocol for DHCPv6. But, this may not be that critical if there are few
rare cases where it would add much value (and those cases would likely
only marginally benefit by a secure DHCPv6 protocol)?

>
>>     Security issues associated with DHCP and prefix delegation are
>>     addressed in the "Security Considerations" section of RFC 3315
>>     and RFC 3633, respectively.
>
>I don't think the security issues have been sufficiently addressed in 
>those documents.
 
Can you be a bit more specific about what is missing from these
documents? The DHC WG would certainly like this input for future
revisions of these standards track documents. Sorry if you've posted
these previously, but I just recently started subscribing to this
mailing list. Thanks!

- Bernie Volz




From owner-v6ops@ops.ietf.org  Tue Apr  6 16:41:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26187
	for <v6ops-archive@lists.ietf.org>; Tue, 6 Apr 2004 16:41:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAxKu-0005Fu-Ot
	for v6ops-data@psg.com; Tue, 06 Apr 2004 20:38:20 +0000
Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAwxC-000OM2-BJ
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 20:13:50 +0000
Received: from jurassic.eng.sun.com ([129.146.87.130])
	by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i36KD9io004215;
	Tue, 6 Apr 2004 13:13:09 -0700 (PDT)
Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49])
	by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i36KD9Ej266230;
	Tue, 6 Apr 2004 13:13:09 -0700 (PDT)
Message-ID: <40730F55.7050006@sun.com>
Date: Tue, 06 Apr 2004 13:13:09 -0700
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117
X-Accept-Language: en, zh-hk, zh-tw, zh-cn
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
CC: Pekka Savola <pekkas@netcore.fi>, tcpm@ietf.org, v6ops@ops.ietf.org,
        sebastien.roy@sun.com
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when   connecting
References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> <4.3.2.7.2.20040405201120.00b18e70@mail.daleclick.com>
In-Reply-To: <4.3.2.7.2.20040405201120.00b18e70@mail.daleclick.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fernando Gont wrote:

>> FYI, SCTP has this same problem.  So sctp_connectx() was added in the
>> API draft to allow an app to pass in an array of addresses.
> 
> 
> Is there any reason for which an array of IP addresses is passed, 
> instead of, say, a domain name?

If the argument is a domain name, it will limit the usage of the
call.  For example, a caller may just want to use a subset of peer
addresses to try to connect to it for whatever reason.  We
should have an API which allows that.  Your suggestion on using
a domain name is more suitable for a higher level API.

> IMHO, it's a better approach than just having connect() fail when ICMP 
> errors are received.
> 
> However, unless there's a reason for it (as I asked above), I think it's 
> still a low-level API.
> For example, if I want to get the document at 
> http://www.example.com/index.html , why should I care about whether the 
> webeserver is IPv4-only, IPv6-only or dual/stack?
> Does an application programmer really need to know the IP addresses the 
> domain "www.example.com" map to?
> Actually, should an application programmer be supposed to be 
> knowledgeable on network addressing?

Yes, sctp_connectx() or connectx() is supposed to be a "low" level
API, as the other socket calls.  The API you mentioned above is
more like a library built on top of the socket call layer.

The issue in this discussion thread is that we may need help from an
even lower level than the socket call layer.  Or we can have transport
layer socket option on when a connect() attempt should fail (e.g.
getting an ICMPv6 error) so that the app can respond to it quickly.

Anyway, this is more like an implementation issue than a topic on
TCP maintenances and extensions.


-- 

						K. Poon.
						kacheong.poon@sun.com





From owner-v6ops@ops.ietf.org  Tue Apr  6 16:43:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26309
	for <v6ops-archive@lists.ietf.org>; Tue, 6 Apr 2004 16:43:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BAxOq-0006TE-Pn
	for v6ops-data@psg.com; Tue, 06 Apr 2004 20:42:24 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAxOd-0006RZ-I0
	for v6ops@ops.ietf.org; Tue, 06 Apr 2004 20:42:11 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i36KgAt1023637
	for <v6ops@ops.ietf.org>; Tue, 6 Apr 2004 14:42:11 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HVR006U4O69SP@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Tue, 06 Apr 2004 14:42:10 -0600 (MDT)
Received: from [192.168.1.101] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HVR0035OO68AO@mail.sun.net> for v6ops@ops.ietf.org; Tue,
 06 Apr 2004 14:42:09 -0600 (MDT)
Date: Tue, 06 Apr 2004 13:42:07 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: I-D
 ACTION:draft-durand-v6ops-assisted-tunneling-requirements-00.txt
In-reply-to: <40726F61.150C1257@zurich.ibm.com>
To: Brian E Carpenter <brc@zurich.ibm.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Message-id: <DEA84414-880A-11D8-911A-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <200404011313.IAA10793@ietf.org> <40726F61.150C1257@zurich.ibm.com>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

On Apr 6, 2004, at 1:50 AM, Brian E Carpenter wrote:

>> 4.2. Service Discovery
>>
>>    In order to offer "plug & play", the non-authenticated mode needs 
>> to
>>    discover the address of the server that will provide the tunnel
>>    connectivity. This discovery must be automatic within an ISP 
>> network.
>
> I wonder about this. Users are accustomed to entering a few magic 
> numbers into
> diallers to get a connection. For ADSL, I have to enter "p8,35" -- I 
> have
> no idea why (please don't tell me) but it really isn't a problem in my
> life. If this requirement causes a lot of complexity, I would drop it.

We had a number of discussions on the usefulness of the non 
authenticated mode.
Somehow, the rationale is that it enables scenarios where the user 
doesn't even
know that IPv6 is being used, and everything is triggered by the 
applications.
This won't work if the user had to enter some 'magic numbers' to get a 
connection.
However, for the authenticated mode, this is a different story.

>
>> 7.3 ISATAP
>>
>>    Similar considerations as Teredo, section 7.2, applies to Isatap.
>>    However, as Isatap can not work accross NAT, it is of much less
>>    interest in the framework of this document.
>
> Perhaps you should say the same thing about 6to4.

Good point.

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr  8 17:10:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23632
	for <v6ops-archive@lists.ietf.org>; Thu, 8 Apr 2004 17:10:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BBgiX-000At2-1v
	for v6ops-data@psg.com; Thu, 08 Apr 2004 21:05:45 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BBgiU-000ArV-BC
	for v6ops@ops.ietf.org; Thu, 08 Apr 2004 21:05:42 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i38L5er06430;
	Fri, 9 Apr 2004 00:05:40 +0300
Date: Fri, 9 Apr 2004 00:05:40 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
cc: sebastien.roy@sun.com
Subject: Re: WG Last Call: On-link Assumption and IPv6 On by default
In-Reply-To: <Pine.LNX.4.44.0403240905080.23528-100000@netcore.fi>
Message-ID: <Pine.LNX.4.44.0404082357320.4658-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 24 Mar 2004, Pekka Savola wrote:
> This is a WG Last Call for comments on sending two documents to the 
> IESG:
> 
> 1) draft-ietf-v6ops-onlinkassumption-01.txt, 
>    "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful",
>    target category BCP.
> 
> 2) draft-ietf-v6ops-v6onbydefault-01.txt
>    "Issues with Dual Stack IPv6 on by Default",
>    target category Informational.

My own personal comments are below.

I think both documents are useful and we should progress with them
soon.  It would be nice if we would be able to get a revised versions
out so that we could be done with them ;-).  Endless revisions tend to
sap the energy of the authors and the WG..

onlink-assumption
=================

Tony already raised good points which call for clarification; fixing 
those should be rather straightforward.  I try to not repeat them 
here. Other than that, this seems pretty good, though it can be tuned 
slightly to accommodate for the fact that RFC2461bis (though there 
hasn't been IPv6 WG consensus check yet) has removed the assumption..

substantial
-----------

   The unreachability determination for a destination as it pertains to
   this rule is an implementation detail.  One implementable method is
   to do a simple forwarding table lookup on the destination, and to
   deem the destination as reachable if the lookup succeeds.  The
   Neighbor Discovery on-link assumption makes this method somewhat
   irrelevant, however, as an implementation of the assumption could
   simply be to insert an IPv6 default on-link route into the system's
   forwarding table when the default router list is empty.  The
   side-effect is that the rule would always determine that all IPv6
   destinations are reachable.

==> Tony already discussed a bit of this, and I think this should
probably be clarified.  That is, even if you didn't insert the 
default route in the forwarding table, you'd still have to conclude
that the default router list is empty and you have to send the
packet on the link, right?  So, the particular implementation detail
doesn't seem to matter here, unless I'm missing something.

So, due to the onlink assumption, I think all the implementations
should treat *all the addresses* as unreachable... unless the
implementation specifically includes the case of "onlink assumption"
as part of its unreachable destination -determination (i.e., every
time if you have to resort to the on-link assumption the destination
should be considered unreachable and would lose the first rule).
We could document this particular implementation detail, but not
count on it.

editorial
---------

Abstract

   This document proposes a change to the IPv6 Neighbor Discovery
   conceptual host sending algorithm.

==> to make this more current, should this be "describes" or
"describes a proposition for" (a bit milder) instead of
"proposes"? 

1. Introduction

==> might it make sense to add an informational reference to NDbis,
and add as a last paragraph, maybe like:

  A revision of Neighbor Discovery [NDBIS] has removed the on-link
  assumption from the specification, but this memo gives historical
  reference and background to why this is has been a good decision.

...

   Another security related side-effect of the on-link assumption has to
   do with VPN's.

==> spell out VPN.




v6onbydefault
=============

substantial
-----------

==> I think it might be useful to add a "Conclusions" just before Security
Considerations, trying to summarize the recommendations from different
paragraphs (because there were ones which I'm not sure are being
recommended, like adding additional address selection rules), at least:

 - Making TCP react to ICMP errors in SYN-SENT and SYN-RECEIVED states
   when trying to connect to unreachable destinations.
 - Removing the on-link assumption eliminates ND timeouts when trying to
   send IPv6 packets on a link which has no IPv6 connectivity.

2.3.1.1 TCP Connection Termination
[...]
  Since soft errors conditions are those that would entice an
   application to continue iterating to another address, TCP shouldn't
   make the distinction between ICMPv6 soft errors and hard errors when
   in SYN-SENT or SYN-RECEIVED state.  It should abort a connection in
   those states when receiving any ICMPv6 Destination Unreachable
   message.  When in any other state, TCP would behave as described in
   [HOSTREQS].
[...]

==> I think it would be appropriate to spell out the obvious reason for
reacting to these only in SYN-SENT or SYN-RECEIVED states.  For example, add
at the end of the section:

   Note that reacting to soft errors in all the states would have
   significant security implications as it would be possible for anyone to
   reset established sessions even without IP spoofing.  However, as SYN-SENT
   and SYN-RECEIVED states are very short-lived, the window of exposure is
   very short and the threat is negligible.



....

5. Security Considerations
                                                                          
   This document raises security concerns in Section 3.3.

==> I think we should try to summarize these somehow in Sec Cons section.
I can help with that if needed.


semi-editorial
--------------

  Fixing the destination address selection mechanism by adding such a
   rule is only a mitigating factor if applications use standard name
   resolution API's that implement this mechanism, and these
   applications try addresses in the order returned.  This may not be an
   acceptable assumption in some cases, as there are applications that
   use hard coded addresses and address search orders (DNS resolver is
   one example), and/or literal addresses passed in from the user. [...]

==> I think this, still, needs more explicit text.  That is, this paragraph
is describing e.g., DNS resolvers which implement their own version of the
name resolution, and are not fixed by modifying the standard name
resolution.  Unless I misunderstand this completely, maybe reword the
beginning to something like:

  Fixing the destination address selection mechanism by adding such a
   rule is only a mitigating factor if applications use their own versions
   of name resolution APIs which do not implement the same functionality
   as the standard name resolution APIs. 

...

  On a network that has no IPv6 routing and no IPv6 neighbors, making
   the assumption that every IPv6 destination is on-link will be a
   costly and incorrect assumption.  If an application has a list of
   addresses associated with a destination and the first 15 are IPv6
   addresses, then the application won't be able to successfully send a
   packet to the destination until the attempts to resolve each IPv6
   address have failed.  This could take 45 seconds
   (MAX_MULTICAST_SOLICIT * RETRANS_TIMER * 15).  This could be
   compounded by any transport timeouts associated with each connection
   attempt.

==> expand this a bit by adding at the end like: , bringing the timeouts to
even dozens of minutes.

2.3.3 SCTP Implications
                                                                          
   According to [SCTPIMP], SCTP ignores all ICMPv6 destination
   unreachable messages.  The existing SCTP specifications do not
   suggest any action on the part of the implementation on reception of
   such messages.  Investigation needs to be done to determine the
   implications.


==> we discussed this with Randall Stewart, and the proposed text for 
this is (just to re-iterate and to give WG chance to object ;):

2.3.3 SCTP Implications

   According to [SCTPIMP], SCTP ignores all ICMPv6 destination
   unreachable messages that do not indicate that the SCTP
   protocol itself is unreachable. The existing SCTP specifications do 
not
   suggest any action on the part of the implementation on reception 
of
   a "soft error".

   Unlike TCP, SCTP itself is multihomed and allows
   a user to specify a list of addresses to connect to. Upon reception
   of a Destination Unreachable Message during connection setup, SCTP
   should attempt to retransmit the Initiation message to one of
   its alternate addresses and put the address that encounters the "soft
   error" into the unreachable state. This will prevent use of the address after
   the association is set-up until SCTP's heartbeat mechanism finds
   the address to be reachable.

   In some cases the application
   may not have provided a list of addresses, and then it may
   be benefical for SCTP, at a minimum, to mark the address as
   unreachable so that the application can acquire a notification
   through its application interface. In such a case the application
   could then either take action upon the address notification by
   aborting the connection attempt or allow SCTP's normal timer
   mechanism to continue retransmitting the INIT message to the
   peer's address.
                                                                          
  There is work in progress to specify adding the support for handling 
  soft errors to the SCTP specification. 

...

  A similar problem could exist for VPN software.  A VPN could protect
   all IPv4 packets but transmit all others onto the local subnet
   unprotected.  At least one widely used VPN behaves this way.  This is
   problematic on a dual stack host that has IPv6 enabled on its local
   network.  It establishes its VPN link and attempts to communicate
   with destinations that resolve to both IPv4 and IPv6 addresses.
[...]
The reason that packets meant to be
   protected would be sent in the clear on the local network is either
   because of the on-link assumption discussed in Section 2.2, or of
   malicious hijacking of traffic by a rogue "fake" router advertising a
   prefix.

==> I think this is is not spelling out the different cases well enough,
that is:

 1) there is a legitimate IPv6 router on the link, and the node is using it
for v6 access, and VPN does not protect that
 1.b) the host has activated a transition mechanism (e.g., 6to4 or Teredo),
VPN does not block it, and gets v6 access using that.  One could guess that
at least Teredo could punch through such VPN firewalls.
 2) there is no legitimate v6 router on the link, but the on-link assumption
throws the packets on the link, not protecting them (communication fails)
 3) there is rogue router capturing the packets (similar to 1)




editorial
---------

Abstract
                                                                          
   This document discusses problems that can occur when dual stack nodes
   that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4
   and IPv6 environments.  The problems include application connection
   delays, poor connectivity, and network security.  Its purpose is to
   raise awareness of these problems so that they can be fixed or worked
   around. The purpose of this document is not to try to specify whether
   IPv6 should be enabled by default or not, but to raise awareness of
   the potential issues involved.

==> there appears to be significant duplication of text after "Its purpose
..." -- maybe reword like:

Abstract
                                                                          
  The purpose of this memo is to
   raise awareness of these problems so that they can be fixed or worked
   around, not to specify whether IPv6 should be enabled by default or not.

....

   2.3.1   TCP Implications . . . . . . . . . . . . . . . . . . . . .  6
   2.3.1.1 TCP Connection Termination . . . . . . . . . . . . . . . .  6
   2.3.1.2 Asynchronous Application Notification  . . . . . . . . . .  7

==> one might consider setting tocdepth to 3

  It begins in Section 2 by examining problems within IPv6
 
==> s/It/This memo/

   doesn't match the global IPv6 destination, and the site-local IPv4
   source doesn't match the global IPv4 destination. The tie-breaking
 
==> add double quotes around "site-local" here?

   On a network that has no IPv6 routing and no IPv6 neighbors, making
   the assumption that every IPv6 destination is on-link will be a
   costly and incorrect assumption.

==> s/a costly and incorrect assumption/costly and incorrect/ ?
(avoid repeating "assumption")

 The IPv6 implementation should
   be able to immediately notify applications or the transport layer
   that it has no route to such IPv6 destinations, and applications
   won't waste time waiting for address resolution to fail.

==> s/and app/so that app/

2.3 Transport Protocol Robustness
                                                                          
   Making the same set of assumptions as Section 2.2, regardless of how
   long the network layer takes to determine that the IPv6 destination
   is unreachable, the delay associated with a connection attempt to an
   unreachable destination can be compounded by the transport layer.

==> suggest starting a new paragraph after this.

   failing the connection attempt, passing ICMPv6 errors up to the
   application, etc...

==> s/..././

2.3.1.1 TCP Connection Termination
                                                                          
   One solution is for TCP to abort connections in SYN-SENT or
 
==> s/is for TCP/for TCP is/

  Since soft errors conditions are those that would entice an
   application to continue iterating to another address, TCP shouldn't

==> maybe pick a different word than "entice" ?

   A similar problem could exist for VPN software.  A VPN could protect
 
==> spell out VPN?

  Some more complex mechanism could be implemented to apply the correct
   policy to such packets.  This could be easy to do if tunnel endpoints
 
==> s/mechanism/mechanisms/ (or s/Some/A/)





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






From owner-v6ops@ops.ietf.org  Thu Apr  8 18:27:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02349
	for <v6ops-archive@lists.ietf.org>; Thu, 8 Apr 2004 18:27:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BBhxT-000HLS-1y
	for v6ops-data@psg.com; Thu, 08 Apr 2004 22:25:15 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BBhxP-000HJi-Ev
	for v6ops@ops.ietf.org; Thu, 08 Apr 2004 22:25:11 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i38MONN07411;
	Fri, 9 Apr 2004 01:24:24 +0300
Date: Fri, 9 Apr 2004 01:24:23 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Fernando Gont <fernando@gont.com.ar>
cc: tcpm@ietf.org, <v6ops@ops.ietf.org>, <sebastien.roy@sun.com>
Subject: Re: [tcpm] TCP, multiple addresses and soft errors when     connecting
In-Reply-To: <4.3.2.7.2.20040405201058.02a45d80@mail.daleclick.com>
Message-ID: <Pine.LNX.4.44.0404090030400.6477-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, 5 Apr 2004, Fernando Gont wrote:
> At 09:25 05/04/2004 +0300, Pekka Savola wrote:
> > > >  2) state the desire for getting a better higher-level API which would
> > > >handle all of this and much more (instead of/in addition to 1), but
> > > >mention why this is not an only practical solution.
> > > What do you mean "this is not an only practical solution"?
> >What I should have said if "but mention why this is would not be a
> >practical solution, if there were no other solutions".
> 
> Actually, I think it is the only real solution to the problem.
> Having the API report ICMP errors to the application is moving the problem 
> from the API to the application, but *not* solving it.
>
> If you leave connect() as is, then you may have the delay problem you 
> describe (i.e., you may suffer undesirable delays to use a service).
> If you make it report ICMP errors to the application, you still have a 
> problem I mentioned in the other e-mails. You might even say that you'll 
> have application programmers (probably *not* knowledgeable on TCP/IP 
> internals) handling issues of the underlying protocols.

I have to disagree here.  Writing getaddrinfo() loops which include
loops around socket() and even connect() are commonplace so this is
nothing new.  Actually this was discussed in
draft-ietf-v6ops-application-transition-02.txt which we just shipped
off to the IESG.  Section 6.3.2 gives a specific example and section
6.3 describes alternative means; the user does not -- necessarily --
need to know anything and the coder only needs to know to build the
right logic. (Which is required anyway for proper v6/v4 applications.)

Again, high-level API which makes it smoother to use either v4 or v6 
would not hurt either, and could be achieved in one shot.  But again, 
this is not here and now.

> So a real solution is to hide all this stuff from the application 
> programmer. Let him just concentrate on actually using a service, and 
> handle all the protocol-related issues inside the API.

For long-term, yes, that would be preferable (even though I think 
still there should be low-level equivalents, but not necessarily 
integrated with connect()).

But the problem is that the IETF has avoided specifying APIs whereever 
it has been able to, and even if we made these here (or elsewhere), 
there would have to be significant vendor buy-in (so that they could 
be used to create portable code), and implementation.  Even if there 
would be significant interest, this would take 3 years (minimum).

So, for all the good having such APIs would do, I fail to see how it 
could provide sufficiently short-term fix to this particular problem, 
and which is why we're documenting the connect() semantics change some 
have already done.

> >That is, new APIs would be great, but we cannot stop fixing problems
> >current APIs until we have something more concrete out there.
> >Otherwise we'd end up with no practically (in short term) deployable
> >solution.
> 
> If you consider it useful, I could try to continue thinking on the 
> "abstract" API. I'm just thinking about writting some stuff down, so that 
> there's a place from which which can move things forward. It may take me 
> some time (say, months), but...

I certainly think this is interesting work (actually, I've seen some
abstractization libraries for Unix already a couple of years ago,
doing something like you say -- but I can't find it now; maybe it was
something along the lines of http://thf.ath.cx/snl), but as I stated
above, there are significant barriers to be torn down first..

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





From owner-v6ops@ops.ietf.org  Thu Apr  8 19:04:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05423
	for <v6ops-archive@lists.ietf.org>; Thu, 8 Apr 2004 19:04:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BBiY5-0008z4-Bt
	for v6ops-data@psg.com; Thu, 08 Apr 2004 23:03:05 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BBiY2-0008xo-UL
	for v6ops@ops.ietf.org; Thu, 08 Apr 2004 23:03:02 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i38N32WF005768
	for <v6ops@ops.ietf.org>; Thu, 8 Apr 2004 17:03:02 -0600 (MDT)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HVV00FS2K111N@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 08 Apr 2004 17:03:02 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HVV00FLZK1046@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 08 Apr 2004 17:03:01 -0600 (MDT)
Date: Thu, 08 Apr 2004 16:03:00 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: WG Last Call: On-link Assumption and IPv6 On by default
In-reply-to: <Pine.LNX.4.44.0404082357320.4658-100000@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org, Sebastien.Roy@Sun.COM
Message-id: <E1EEE0A6-89B0-11D8-8D6A-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0404082357320.4658-100000@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 8, 2004, at 2:05 PM, Pekka Savola wrote:
>
> v6onbydefault
> =============
>
> semi-editorial
> --------------
>
>   Fixing the destination address selection mechanism by adding such a
>    rule is only a mitigating factor if applications use standard name
>    resolution API's that implement this mechanism, and these
>    applications try addresses in the order returned.  This may not be 
> an
>    acceptable assumption in some cases, as there are applications that
>    use hard coded addresses and address search orders (DNS resolver is
>    one example), and/or literal addresses passed in from the user. 
> [...]
>
> ==> I think this, still, needs more explicit text.  That is, this 
> paragraph
> is describing e.g., DNS resolvers which implement their own version of 
> the
> name resolution, and are not fixed by modifying the standard name
> resolution.  Unless I misunderstand this completely, maybe reword the
> beginning to something like:
>
>   Fixing the destination address selection mechanism by adding such a
>    rule is only a mitigating factor if applications use their own 
> versions
>    of name resolution APIs which do not implement the same 
> functionality
>    as the standard name resolution APIs.

The quoted text probably needs clarification. The example about the DNS 
resolver
is in fact very simple, in /etc/resolv.conf (or equivalent), one 
usually uses literal addresses.
With literal assresses, address selection rules that are plugged into 
the resolver library
are bypassed... so if in your /etc/resolv.conf you have an ordered list:
3ffe::1
129.129.129.1
and the v6 network in not reachable, that will still cause unacceptable 
delays.

This example can be extended to any apps that accept literal addresses 
in its configuration.

	- Alain.




From owner-v6ops@ops.ietf.org  Tue Apr 13 16:40:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06203
	for <v6ops-archive@lists.ietf.org>; Tue, 13 Apr 2004 16:40:44 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDUc2-000D7H-KL
	for v6ops-data@psg.com; Tue, 13 Apr 2004 20:34:30 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDUbr-000D4J-I5
	for v6ops@ops.ietf.org; Tue, 13 Apr 2004 20:34:19 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3DKYFH19462;
	Tue, 13 Apr 2004 13:34:15 -0700
X-mProtect: <200404132034> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdowuV7d; Tue, 13 Apr 2004 13:34:14 PDT
Message-ID: <407C4EC9.2000507@iprg.nokia.com>
Date: Tue, 13 Apr 2004 13:34:17 -0700
From: Fred 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 <brc@zurich.ibm.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter
   natives in 3GPP [Re: comments on draft-ietf-v6  ops-3gpp-analysis-09  
 .txt] ]
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com> <406C223B.6AB75BC5@zurich.ibm.com> <406CAD48.1070301@iprg.nokia.com> <40726D87.AE521541@zurich.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Brian,

Brian E Carpenter wrote:

>Fred,
>
>Thanks. I've PDF'ed the picture in case anyone here is PPT-challenged.
>

PDF is fine for me; thanks. If it's OK with you, I'd rather not
try to tackle all of the points from your message below in one
fell swoop, but rather see if we can establish things through
an iterative dialogue.

The first aspect I would like to call to attention is the "Admin.
Domain B" portion of the PDF figure. Note that we see what
appear to be nested sub-domains within a parent domain. This
might present something of a challenge to the traditional notion
of what constitutes a "site", in that  sites need not be viewed as
disjoint. Rather, sites can be seen as recursively nested one within
another. Moreover, it seems to me that such recursive nesting of
sites can extend outwards or inwards from a given point as far
as one would like (within practical limitations, that is).

In comparison to the natural order of things, such a view
makes perfect sense:

  - our universe is a "site" for which all known entities are
    a member (it's probably best to leave the discussion of
    parallel universes aside for now...).
 - the universe comprises a number of  galaxies; each of which
   is an autonomous "site" unto itself, yet a sibling of others.
 - each galaxy comprises a number of stars/solar systems that
   are, again, autonomous "sites" yet siblings to others.
 - each star/solar system (presumably) comprises a number
   of planets/planetiods that are, again...

and so on, until the desired degree of granularity is reached.

Now, if we could rig a ubiquitous naming system to match up
with this natural order, we could assign a ".universe" TLD to
the center of mass of the universe and recursively assign
sub-domains going outward. For example (neglecting for
now finer granularities) I could be reached via this naming
system at:

 fredtemplin.california.usa.earth.sun.milkyway.universe

More relative to the subject topic of this thread, we can consider
each node "xyz.foo.bar.com" in the Internet as a site unto itself,
and consider its default router as the "center of mass" for its parent
site "foo.bar.com". But then, this default router is yet again
(the head of) a site unto itself with its *own* default router as
the center of mass for *its* parent site "bar.com". If we allow
each such default router to delegate the addressing scheme for its
constituents, then we have a way of tying addresses with sites
that matches the natural order of things.

  As the main point of this note, if we further equate the term
  "site" with the term "domainname", we have a way of tying
  addresses to domainnames that matches the natural order of
  things in such a way that we have a ready-made, natural
  routing engine in the form of the global DNS.

As I said, I'd like to take this discussion in iterative fashion,
so I'll stop here for now and await comments. What I've said
so far might appear as obvious and/or off-topic to a portion
of this list readership, but I'm hoping that the relation to the
6to4/ISATAP/etc discussion will become more evident as
we drill down into details from this 30k+ foot vantage point.

Thanks - Fred
ftemplin@iprg.nokia.com

>Fred Templin wrote:
>  
>
>>Brian E Carpenter wrote:
>>
>>    
>>
>>>Can somebody draw me a picture? [Emphasis on the word "useful."]
>>>
>>>
>>>      
>>>
>>Brian,
>>
>>Attached, please find a rough-cut and incomplete picture. It depicts
>>two administrative domains (A and B), each with a node that is
>>engaged in a peer-to-peer session (a.com and b.com). Domain A
>>uses a native IPv6 prefix space and has delegated a portion of the
>>space to a (b)router upstream from the node "a.com". Domain B
>>uses a 6to4 prefix space and has delegated portions of the space
>>to a hierarchically nested pair of (b)routers upstream from node
>>"b.com".
>>
>>If the DNS entries for 'a.com' and 'b.com' are populated with AAAA
>>resource records as shown in the picture, one could view the presence
>>of the ISATAP-format link local addresses 
>>    
>>
>
>Well, I wouldn't expect those AAAA records to be visible outside the
>originating sites. They would typically be suppressed by a 2-faced DNS
>setup.
>
>I don't think the link local address you have for b.com is correct,
>anyway. Inside site B, link locals are formed using Ethernet addresses
>or whatever. The hosts inside a 6to4 site have no knowledge of 6to4.
>
>  
>
>>as an unambiguous
>>indication that the nodes "support the protocol", 
>>    
>>
>
>I regard it as highly unlikely that site B would contain logic to
>identify fe80::0200:5efe:0506:0708 as a foreign ISATAP-like address.
>Site B is running 6to4; why would it have any ISATAP-related code active?
>
>  
>
>>and could use
>>the ISATAP link-local address as the IPv6 next-hop toward
>>the final destination.
>>
>>The picture shows a stream of packets emanating from a.com towards
>>b.com (and, similarly, for packets emanating from b.com towards
>>a.com). These outbound packets would be encapsulated using ISATAP
>>and it would appear from IPv6's perspective that they are being
>>"bridged" up to the edge of the remote peer's domain (although there
>>would still need to be some flavor of NDproxy in operation). Once the
>>inbound packets hit the edge of the remote peer's domain, the packets
>>would be decapsulated and steered towards the final destination
>>within the domain via the delegated IPv6 prefix information.
>>
>>The question comes when we consider the inbound packets
>>arriving at the edge of administrative domain B. Does the edge
>>node use 6to4 or ISATAP to decapsulate the packets. (And, does
>>it even matter?)
>>    
>>
>
>Well, as noted, I don't see any reason that site B would have an ISATAP
>interface active. It won't know that 3ffe:1::1 is anything unusual.
>Similarly, site A won't have any 6to4 code active. It won't know that
>2002:0506:0708::1 is anything unusual. They will both send as if these are
>native addresses, and receive in their normal way (native at site A and
>6to4 decapsulation at site B).
>
>At least that's what I think.
>
>   Brian
>





From owner-v6ops@ops.ietf.org  Tue Apr 13 17:59:15 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12313
	for <v6ops-archive@lists.ietf.org>; Tue, 13 Apr 2004 17:59:15 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDVta-0008uL-FB
	for v6ops-data@psg.com; Tue, 13 Apr 2004 21:56:42 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDVtZ-0008u8-OY
	for v6ops@ops.ietf.org; Tue, 13 Apr 2004 21:56:41 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3DLueHS029192
	for <v6ops@ops.ietf.org>; Tue, 13 Apr 2004 15:56:41 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW400H60QAFWD@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Tue, 13 Apr 2004 15:56:40 -0600 (MDT)
Received: from [192.168.1.100] ([129.150.16.221])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW400K15QAE3N@mail.sun.net> for v6ops@ops.ietf.org; Tue,
 13 Apr 2004 15:56:39 -0600 (MDT)
Date: Tue, 13 Apr 2004 14:56:39 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
To: IPv6 Operations <v6ops@ops.ietf.org>, Pekka Savola <pekkas@netcore.fi>,
        Jonne.Soininen@nokia.com
Message-id: <7166B619-8D95-11D8-845C-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_UFCdAUVotpjWgXFl0MRxCg)"
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--Boundary_(ID_UFCdAUVotpjWgXFl0MRxCg)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7BIT

I would like to request the wg and is chairs to consider
draft-durand-v6ops-assisted-tunneling-requirements-00.txt
as a wg item. I have received a number of comments either privately
and on the ml, I would like to issue a new revision with a 
draft-ietf-v6ops title.

	- Alain.

--Boundary_(ID_UFCdAUVotpjWgXFl0MRxCg)
Content-type: text/enriched; charset=US-ASCII
Content-Transfer-Encoding: 7BIT

I would like to request the wg and is chairs to consider

<bold>draft-durand-v6ops-assisted-tunneling-requirements-00.txt</bold>

as a wg item. I have received a number of comments either privately

and on the ml, I would like to issue a new revision with a
draft-ietf-v6ops title.


	- Alain.


--Boundary_(ID_UFCdAUVotpjWgXFl0MRxCg)--



From owner-v6ops@ops.ietf.org  Wed Apr 14 00:03:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00484
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 00:03:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDbXW-000MFO-0d
	for v6ops-data@psg.com; Wed, 14 Apr 2004 03:58:18 +0000
Received: from [128.9.160.161] (helo=boreas.isi.edu)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDXFE-0003dH-Ri
	for v6ops@ops.ietf.org; Tue, 13 Apr 2004 23:23:08 +0000
Received: from ISI.EDU (adma.isi.edu [128.9.160.239])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DNMoN08324;
	Tue, 13 Apr 2004 16:22:50 -0700 (PDT)
Message-Id: <200404132322.i3DNMoN08324@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 3750 on Unmanaged Networks IPv6 Transition Scenarios
Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 13 Apr 2004 16:22:50 -0700
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: rfc-ed@isi.edu
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART,
	NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3750

        Title:      Unmanaged Networks IPv6 Transition Scenarios
        Author(s):  C. Huitema, R. Austein, S. Satapati,
                    R. van der Pol
        Status:     Informational
        Date:       April 2004
        Mailbox:    huitema@microsoft.com, sra@isc.org,
                    satapati@cisco.com, Ronald.vanderPol@nlnetlabs.nl
        Pages:      20
        Characters: 48153
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-v6ops-unman-scenarios-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3750.txt


This document defines the scenarios in which IPv6 transition
mechanisms are to be used in unmanaged networks.  In order to evaluate
the suitability of these mechanisms, we need to define the scenarios
in which these mechanisms have to be used.  One specific scope is the
"unmanaged network", which typically corresponds to a home or small
office network.  The scenarios are specific to a single subnet, and
are defined in terms of IP connectivity supported by the gateway and
the Internet Service Provider (ISP).  We first examine the generic 
requirements of four classes of applications: local, client, peer to
peer and server.  Then, for each scenario, we infer transition
requirements by analyzing the needs for smooth migration of
applications from IPv4 to IPv6.

This document is a product of the IPv6 Operations Working Group of the
IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <040413162124.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3750

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3750.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <040413162124.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--




From owner-v6ops@ops.ietf.org  Wed Apr 14 04:07:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07109
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 04:07:38 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDfNa-0007fL-Jz
	for v6ops-data@psg.com; Wed, 14 Apr 2004 08:04:18 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDfNW-0007eT-Cv
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 08:04:14 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3E84DAh009613
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 10:04:13 +0200
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 14 Apr 2004 10:04:13 +0200
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id 25RJV4FG; Wed, 14 Apr 2004 10:04:17 +0200
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY0CC5K>; Wed, 14 Apr 2004 10:04:13 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E3AE@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 32a898cd 272a6e05 982fdb5e 00000139
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Fred Templin'" <ftemplin@iprg.nokia.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: FYI Isatap implementations info
Date: Wed, 14 Apr 2004 10:03:24 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 14 Apr 2004 08:04:13.0202 (UTC) FILETIME=[12F6CF20:01C421F7]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Fred,

In relation to the process of updating the Isatap draft
to comply with existing implementations (provided
that's still the idea -(?)) you 
may find the following information useful.

We have made and are continuing using 
implementations of Isatap
on host as well as on router stacks.
The implementations have been deployed in various
scenarios, though primarily using GPRS and UMTS
IPv4-only access networks.

The implementations are used in configurations which
are largely in compliance with (e.g.) draft-v12 with
the following derivations and/or clarifications:

General:
If not otherwise specified, [mechv02] requirements 
wrt ND, ICMP etc. over tunnels are fulfilled.

No multicast emulation.
DAD not performed on Isatap interfaces.
Link-layer Address Options not set and always 
ignored in ND messages received 
on Isatap interfaces.

MTU scheme based on configurable static MTU.

Host implementation particularities:

Direct tunneling to/from on-link addresses is allowed
(on-link equal to prefixes received in RAs).
The following security checks are applied
on incoming packets:

Either the v6 src must be on-link 
and match the v4 src - or the v4 src is from a router in PRL.
In addition RA's are always checked to ensure that
v6 src matches v4 src and that the v4 src must be in PRL.

Router Implementation particularities:

Only Router-to-host communication is supported, that is, 
PRL list not maintained on Router interfaces. 
The following security checks are applied
on incoming packets:

The inner IPv6 source address has a prefix configured (i.e. advertised)
on the ISATAP interface and an ISATAP-format interface identifier that 
embeds the IPv4 source address of the outer header.

v6inv4 Configured tunnels anchored on an Ipv4
 address also used by the Isatap interface
will have precedence over the Isatap interface, i.e.,
incoming packets will be processed by the configured tunnel interface 
implementation and not the Isatap interface implementation.
(Further, Isatap interfaces take precedence over 6to4 interfaces.)

For scalability reasons NUD is not performed on Isatap router interfaces.
Further on these interfaces, address resolution 
is based on static address computation only.

Security threat model:

The above security checks have been modeled
according to environments where the site perimeter
is guarded and where either:
* intra-site IPv4 address spoofing isn't possible (e.g. 3G telecom)
* intra-site nodes are trustworthy 

BR, Karen

-----------------------------------------------------------
Karen Egede Nielsen, System Manager, Ericsson Telebit A/S
Phone:  + 45 89385100, Fax:  + 45 89385101
Phone Direct: + 45 89385313, Mobile:+ 45 25134336
karen.e.nielsen@ericsson.com
-----------------------------------------------------------




From owner-v6ops@ops.ietf.org  Wed Apr 14 14:03:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11522
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 14:03:35 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDoeZ-000Bs4-H0
	for v6ops-data@psg.com; Wed, 14 Apr 2004 17:58:27 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDoeW-000BrZ-Bn
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 17:58:24 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3EHwKf25241;
	Wed, 14 Apr 2004 10:58:20 -0700
X-mProtect: <200404141758> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdvSvCQe; Wed, 14 Apr 2004 10:58:19 PDT
Message-ID: <407D7BC3.3080104@iprg.nokia.com>
Date: Wed, 14 Apr 2004 10:58:27 -0700
From: Fred 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: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>, ftemplin@iprg.nokia.com
Subject: Re: FYI Isatap implementations info
References: <C26BB8276599A44B85D52F9CE41035E10229E3AE@esealnt944.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Karen,

Karen E. Nielsen (AH/TED) wrote:

>Hi Fred,
>
>In relation to the process of updating the Isatap draft
>to comply with existing implementations (provided
>that's still the idea -(?))
>

W/o meaning to speak for the co-authors,  it seems safe enough
to say that the requirement for documenting the widely-deployed
implementations has been clearly communicated by the working
group and understood as first-priority.

>you may find the following information useful.
>

Yes, it was useful; thanks. See below for a few follow-up
comments/questions:

>We have made and are continuing using 
>implementations of Isatap
>on host as well as on router stacks.
>The implementations have been deployed in various
>scenarios, though primarily using GPRS and UMTS
>IPv4-only access networks.
>
>The implementations are used in configurations which
>are largely in compliance with (e.g.) draft-v12 with
>the following derivations and/or clarifications:
>
>General:
>If not otherwise specified, [mechv02] requirements 
>wrt ND, ICMP etc. over tunnels are fulfilled.
>
>No multicast emulation.
>DAD not performed on Isatap interfaces.
>Link-layer Address Options not set and always 
>ignored in ND messages received 
>on Isatap interfaces.
>
>MTU scheme based on configurable static MTU.
>
>Host implementation particularities:
>
>Direct tunneling to/from on-link addresses is allowed
>(on-link equal to prefixes received in RAs).
>

To my understanding, "on-link" should also include link-local - correct?

>The following security checks are applied
>on incoming packets:
>
>Either the v6 src must be on-link 
>and match the v4 src - or the v4 src is from a router in PRL.
>In addition RA's are always checked to ensure that
>v6 src matches v4 src and that the v4 src must be in PRL.
>
>Router Implementation particularities:
>
>Only Router-to-host communication is supported, that is, 
>PRL list not maintained on Router interfaces. 
>The following security checks are applied
>on incoming packets:
>
>The inner IPv6 source address has a prefix configured (i.e. advertised)
>

Again, to my understanding link-locals should also be included,
whereas "(i.e. advertised)" would seem to exclude them.

>on the ISATAP interface and an ISATAP-format interface identifier that 
>embeds the IPv4 source address of the outer header.
>

Conspicuous by its absence here is the secondary check for
"v4 src is from a router in the PRL", but I note that you have
already stated that the PRL is not maintained on Router interfaces
in your implementation.

>v6inv4 Configured tunnels anchored on an Ipv4
> address also used by the Isatap interface
>will have precedence over the Isatap interface, i.e.,
>incoming packets will be processed by the configured tunnel interface 
>implementation and not the Isatap interface implementation.
>

Agreed.

>(Further, Isatap interfaces take precedence over 6to4 interfaces.)
>

By "take precedence" here, I assume you mean that the received packets
 should be decapsulated/filtered as per the specification of precedence
(6to4 or ISATAP) - correct?  This is a (somewhat) unresolved aspect
of the "Re: ISATAP, v6inv4 and 6to4 ..." discussion thread. In further
thinking on this, I believe the correct answer is not quite as simple as
you are stating it here - but almost:

If a 6to4 interface and ISATAP interface are configured over the same
IPv4 address, it would have to be a global IPv4 address assigned to an
interface connected to the global Internet due to 6to4 requirements. In
that case, I believe the correct behavior should be for the 6to4 interface
to take precedence for packets received with an on-link 6to4 prefix in
the IPv6 destination, and for the ISATAP interface to take precedence
for all others. Comments?

>For scalability reasons NUD is not performed on Isatap router interfaces.
>Further on these interfaces, address resolution 
>is based on static address computation only.
>
>Security threat model:
>
>The above security checks have been modeled
>according to environments where the site perimeter
>is guarded and where either:
>* intra-site IPv4 address spoofing isn't possible (e.g. 3G telecom)
>* intra-site nodes are trustworthy
>

I'm tempted to add a third bullet to your list:

  * intra-site communications are restricted to router<->host only

but perhaps this is implicitly covered by one of the other two?

Thanks - Fred
ftemplin@iprg.nokia.com

>BR, Karen
>
>-----------------------------------------------------------
>Karen Egede Nielsen, System Manager, Ericsson Telebit A/S
>Phone:  + 45 89385100, Fax:  + 45 89385101
>Phone Direct: + 45 89385313, Mobile:+ 45 25134336
>karen.e.nielsen@ericsson.com
>-----------------------------------------------------------
>  
>





From owner-v6ops@ops.ietf.org  Wed Apr 14 15:41:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18937
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 15:41:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDqCn-000ArF-13
	for v6ops-data@psg.com; Wed, 14 Apr 2004 19:37:53 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDqCj-000Aqb-B8
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 19:37:49 +0000
Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3EJbmWR011242
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 21:37:48 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 14 Apr 2004 21:37:48 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <25R3DY3H>; Wed, 14 Apr 2004 21:37:48 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'Alain Durand '" <Alain.Durand@Sun.COM>,
        "'IPv6 Operations '"
	 <v6ops@ops.ietf.org>
Subject: comments on draft-durand-v6ops-assisted-tunneling-requirements-00
	.txt
Date: Wed, 14 Apr 2004 21:37:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Mailer: Apple Mail (2.613)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 14 Apr 2004 19:37:48.0330 (UTC) FILETIME=[F78368A0:01C42257]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi

I have some comments on the draft. Section 2 says:

  - The customer configuration may be diverse, and not necessarily
       predictable by the ISP. The following cases must be supported:
         - a single node,
         - a leaf network,
         - using a globally routable IPv4 address,
         - behind a NAT,

However it also says (later in section 2):

   Althought the main focus of this document is the ISP scenario,
   assisted tunneling is applicable in all the other scenarios:
   unmanaged, enterprise and 3GPP.
   ...
   In 3GPP networks, assisted tunneling can be used in the context of
   dual stack UE connecting to IPv6 nodes through a 3GPP network that
   only supports IPv4 PDP contexts [3GPP, 3.1].

There seems to be a contradiction when considering 3GPP networks,
since the customer does not have a NAT in the customer equipment
(i.e. mobile terminal). Therefore the tunneling can be terminated
within the mobile operator's network and never goes through a NAT.
That's a good thing since we wouldn't have to pass even more traffic
(v6 tunnelled traffic) through NATs in this scenario. For the same
reason the following consideration on ISATAP does not apply to 3GPP
networks (also described in the draft reference [3GPP]):

   7.3 ISATAP

   Similar considerations as Teredo, section 7.2, applies to Isatap.
   However, as Isatap can not work accross NAT, it is of much less
   interest in the framework of this document.

I think that to make this draft applicable to 3GPP networks some
substantial changes would be needed such as the removal of the NAT
assumption.

/Karim



From owner-v6ops@ops.ietf.org  Wed Apr 14 16:57:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25565
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 16:57:29 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDrNv-0001t2-Jz
	for v6ops-data@psg.com; Wed, 14 Apr 2004 20:53:27 +0000
Received: from [66.163.168.185] (helo=smtp806.mail.sc5.yahoo.com)
	by psg.com with smtp (Exim 4.30; FreeBSD)
	id 1BDrNu-0001sj-7X
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 20:53:26 +0000
Received: from unknown (HELO VALUED847D7605) (carl?e?williams@sbcglobal.net@209.137.156.6 with login)
  by smtp806.mail.sc5.yahoo.com with SMTP; 14 Apr 2004 20:53:25 -0000
Reply-To: <carlw@kddilabs.com>
From: "Carl Williams" <carlw@kddilabs.com>
To: <v6ops@ops.ietf.org>
Cc: <karim.el-malki@ericsson.com>
Subject: RE:  comments on draft-durand-v6ops-assisted-tunneling-requirements
Date: Wed, 14 Apr 2004 13:57:13 -0700
Organization: KDDI Labs USA
Message-ID: <000001c42263$11561f60$5b5cfea9@VALUED847D7605>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C42228.64F74760"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,HTML_70_80,
	HTML_MESSAGE,SUBJ_HAS_UNIQ_ID autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C42228.64F74760
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
>> There seems to be a contradiction when considering 3GPP networks,
>> since the customer does not have a NAT in the customer equipment
>>(i.e. mobile terminal). Therefore the tunneling can be terminated
>> within the mobile operator's network and never goes through a NAT.
>> That's a good thing since we wouldn't have to pass even more traffic
>> (v6 tunnelled traffic) through NATs in this scenario.
 
The same holds true for 3GPP2 networks as well.  
 
 
Original Message:
-----------------
From: Karim El-Malki (HF/EAB) karim.el-malki@ericsson.com
Date: Wed, 14 Apr 2004 21:37:27 +0200
To: Alain.Durand@Sun.COM, v6ops@ops.ietf.org
Subject: comments on
draft-durand-v6ops-assisted-tunneling-requirements-00.txt
 
 
Hi
 
I have some comments on the draft. Section 2 says:
 
  - The customer configuration may be diverse, and not necessarily
       predictable by the ISP. The following cases must be supported:
         - a single node,
         - a leaf network,
         - using a globally routable IPv4 address,
         - behind a NAT,
 
However it also says (later in section 2):
 
   Althought the main focus of this document is the ISP scenario,
   assisted tunneling is applicable in all the other scenarios:
   unmanaged, enterprise and 3GPP.
   ...
   In 3GPP networks, assisted tunneling can be used in the context of
   dual stack UE connecting to IPv6 nodes through a 3GPP network that
   only supports IPv4 PDP contexts [3GPP, 3.1].
 
There seems to be a contradiction when considering 3GPP networks,
since the customer does not have a NAT in the customer equipment
(i.e. mobile terminal). Therefore the tunneling can be terminated
within the mobile operator's network and never goes through a NAT.
That's a good thing since we wouldn't have to pass even more traffic
(v6 tunnelled traffic) through NATs in this scenario. For the same
reason the following consideration on ISATAP does not apply to 3GPP
networks (also described in the draft reference [3GPP]):
 
   7.3 ISATAP
 
   Similar considerations as Teredo, section 7.2, applies to Isatap.
   However, as Isatap can not work accross NAT, it is of much less
   interest in the framework of this document.
 
I think that to make this draft applicable to 3GPP networks some
substantial changes would be needed such as the removal of the NAT
assumption.
 
/Karim

------=_NextPart_000_0001_01C42228.64F74760
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C42228.62DEEEB0">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:ApplyBreakingRules/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;&gt; There seems to be a contradiction when =
considering 3GPP
networks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;&gt; <span class=3DGramE>since</span> the =
customer does
not have a NAT in the customer equipment<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;<span class=3DGramE>&gt;(</span>i.e. mobile =
terminal). Therefore
the tunneling can be terminated<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;&gt; <span class=3DGramE>within</span> the mobile
operator's network and never goes through a =
NAT.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;&gt; That's a good thing since we wouldn't have =
to pass
even more traffic<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&gt;&gt; (v6 <span class=3DSpellE>tunnelled</span> =
traffic) through
<span class=3DSpellE>NATs</span> in this =
scenario.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The same holds true for 3GPP2 networks as well.<span
style=3D'mso-spacerun:yes'>&nbsp; </span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span =
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Original Message:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-----------------<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>From: <span class=3DSpellE>Karim</span> El-<span =
class=3DSpellE>Malki</span>
(HF/EAB) karim.el-malki@ericsson.com<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Date: </span></font><st1:date Month=3D"4" Day=3D"14" =
Year=3D"2004"><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Wed, 14 Apr
 2004</span></font></st1:date><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'> </span></font><st1:time Hour=3D"21" =
Minute=3D"37"><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>21:37:27</span></font></st1:=
time><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> =
+0200<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>To: Alain.Durand@Sun.COM, =
</span></font><st1:PersonName><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>v6ops@ops.ietf.org</span></f=
ont></st1:PersonName><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Subject: comments on =
draft-durand-v6ops-assisted-tunneling-requirements-00.txt<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have some comments on the draft. Section 2 =
says:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp; </span>- The =
customer
configuration may be diverse, and not =
necessarily<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><span
class=3DGramE>predictable</span> by the ISP. The following cases must be
supported:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
</span>- <span class=3DGramE>a</span> single =
node,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
</span>- <span class=3DGramE>a</span> leaf =
network,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
</span>- using a globally routable IPv4 =
address,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
</span>- <span class=3DGramE>behind</span> a =
NAT,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>However it also says (later in section =
2):<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span><span
class=3DSpellE>Althought</span> the main focus of this document is the =
ISP
scenario,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span><span
class=3DGramE>assisted</span> tunneling is applicable in all the other =
scenarios:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span><span
class=3DGramE>unmanaged</span>, enterprise and =
3GPP.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span>...<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span>In 3GPP
networks, assisted tunneling can be used in the context =
of<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span><span
class=3DGramE>dual</span> stack UE connecting to IPv6 nodes through a =
3GPP
network that<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span><span
class=3DGramE>only</span> supports IPv4 PDP contexts [3GPP, =
3.1].<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>There seems to be a contradiction when considering =
3GPP
networks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>since</span></font></span><f=
ont
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> the
customer does not have a NAT in the customer =
equipment<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>(<span class=3DGramE>i.e</span>. mobile terminal). =
Therefore
the tunneling can be terminated<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>within</span></font></span><=
font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> the mobile
operator's network and never goes through a =
NAT.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>That's a good thing since we wouldn't have to pass =
even more
traffic<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>(<span class=3DGramE>v6</span> <span =
class=3DSpellE>tunnelled</span>
traffic) through <span class=3DSpellE>NATs</span> in this scenario. For =
the same<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>reason</span></font></span><=
font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> the
following consideration on ISATAP does not apply to =
3GPP<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>networks</span></font></span=
><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> (also
described in the draft reference [3GPP]):<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span>7.3
ISATAP<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span><span
class=3DGramE>Similar considerations as <span =
class=3DSpellE>Teredo</span>, section
7.2, applies</span> to <span =
class=3DSpellE>Isatap</span>.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span>However,
as <span class=3DSpellE>Isatap</span> can not work <span =
class=3DSpellE>accross</span>
NAT, it is of much less<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; =
</span><span
class=3DGramE>interest</span> in the framework of this =
document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I think that to make this draft applicable to 3GPP =
networks
some<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>substantial</span></font></s=
pan><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> changes
would be needed such as the removal of the =
NAT<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>assumption</span></font></sp=
an><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>.<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>/<span =
class=3DSpellE>Karim</span><o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C42228.64F74760--




From owner-v6ops@ops.ietf.org  Wed Apr 14 17:32:50 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28841
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 17:32:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDryH-000BpT-6m
	for v6ops-data@psg.com; Wed, 14 Apr 2004 21:31:01 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDryE-000BoT-VC
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 21:30:59 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000009093.msg
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 23:37:19 +0200
Message-ID: <010101c42268$a4f09570$640a0a0a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <Pine.LNX.4.44.0403281757200.22993-200000@netcore.fi> <040601c4150a$e9c080e0$273263ce@consulintel.es> <DA3F7B18-81A4-11D8-A9F8-00039358A080@sun.com>
Subject: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
Date: Wed, 14 Apr 2004 23:37:09 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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.1165
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 14 Apr 2004 23:37:19 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 14 Apr 2004 23:37:23 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Alain,

I provide some new comments in-line.

I noticed that in 7.2 you kept "simple mode", probably should be changed to "non-authenticated" to avoid confusions.

Regards,
Jordi

----- Original Message -----=20
From: "Alain Durand" <Alain.Durand@Sun.COM>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <carlw@mcsr-labs.org>; "Florent Parent" <florent.parent@hexago.com>; <shu@kddilabs.com>; <pekkas@netcore.fi>; <alain.baudot@francetelecom.com>; "Suresh Satapati" <satapati@cisco.com>
Sent: Monday, March 29, 2004 7:16 PM
Subject: Re: assisted tunneling requirement draft (fwd)


> Thank you Jordi for those valuable comments.
> See response inline.
>=20
> - Alain.
>=20
> On Mar 28, 2004, at 1:23 PM, JORDI PALET MARTINEZ wrote:
>=20
> > Hi Pekka, Alain, all,
> >
> > One minor but important issue is using transition instead of migration.
> >
> > Following Pekka suggestions about our auto-discovery document to cover=20
> > ISATAP, may make sense also here to reword " Although this negotiation=20
> > phase can be automated, this remains fundamentally different from=20
> > transition mechanisms like 6to4, teredo or isatap which do not involve=20
> > any negotiation phase" ?
>=20
> It remains to be proven that there is any benefit in trying to merge=20
> all tunneling proposal.
> I, for one, remain very skeptical about this idea.
> Let's apply the right tool for the right problem.

Agree, it might become too much complicate, but Pekka insisted ;-)

>=20
>=20
> > 4. The Simple Mode is a non-authenticated service, may be we can call=20
> > it "Anonymous" Mode (or non-authenticated), to make it more clearer ?
>=20
> Good point.
>=20
> > 4.2 I would say "This discovery must be automatic at least within an=20
> > ISP network", instead of "This discovery must be automatic within an=20
> > ISP network.".
>=20
> I disagree fundamentally. This would broaden the scope of the problem=20
> unnecessarily.
> Also, I'm not sure it would be good: That would transform the IPv4 ISP
> into a transit provider for the v6 ISP without him knowing it...

Well is a fact, it happens today. Anyway, I believe that adding the "at least" is not a "requirement" but opens new options. ISPs can always filter traffic (and some do).

>=20
> The focus here is about tunnels brokered by the customer ISP. I think=20
> this is a much simpler problem,
> much more useful, with a simple business case behind it.
> By focusing on this problem, I think we have a better chance to be=20
> successful.
> This is a fundamental assumption in the draft.

Then I believe it must be further clarified that the goal is only IN the ISP. For example in 2, replace:
      - ISP is offering IPv6 connectivity to its customers initially
      using controlled tunneling infrastructure [ISP, 5.1 Steps in
      Transitioning Customer Connection Networks]
with
      - ISP is offering IPv6 connectivity to ONLY to its customers initially
      using controlled tunneling infrastructure [ISP, 5.1 Steps in
      Transitioning Customer Connection Networks]

BUT, my opinion is that doing so, we are creating two streams -> two drafts, as another one could be almost the same document, but to ensure that non-ISP-own customers could be covered. Instead, the non-authenticated mode already provides a way to do that, right ?

>=20
> see also 6.7
>=20
>=20
> > 5.1 In my opinion DNS delegation is a must in this case (I mean as=20
> > supported by the protocol).
>=20
> Delegate what exactly? The reverse for the /48 or other prefix length?
> To whom? an address specified by the user? to what address exactly?
> (if the user does not know yet its prefix, there is a chicken and egg=20
> problem,
> unless we pass only the lower 80 bits... which I think is adding extra=20
> complexity
> for little benefits.
>=20
> >
> > 5.2 Agree on 2831 as a must.
> >
> > 6.2 I don't agree with "must be able to abort immediately and display=20
> > the customers a message explaining that no service is available".=20
> > Instead, if there is another ISP offering the service, the customer=20
> > should be informed about that, and have the possibility to use it,=20
> > even if non-optimal.
>=20
> Again, the focus is about tunnels brokered by the customer ISP.
> The concern is customer wants v6, ISP does not offer native yet but=20
> tunnel,
> the user configures the tunnel and 6 month later, the ISP now offers=20
> native,
> but the customer does not know and keep using the tunnel.
> Maybe I should clarify this.
>=20
>=20
>=20
>=20
> >
> > 6.5 In "A client MAY choose not to send those messages (for example on=20
> > ISDN type links), but should then expect that the tunnel may be ...",=20
> > I would use "... (specially for any kind of links were the users is=20
> > billed by traffic) ...". This is considering GPRS and 3G networks more=20
> > than ISDN/PSTN links. One option could be to allow configuring the=20
> > periodicity of the keep alive messages.
>=20
> For ISDN, the concern is not the traffic generated (very small), but=20
> the fact that the line will have
> to be kept up active and the user will be billed by the minute.
>=20
> > 6.7 Is lawful interception here to be also supported ?
>=20
> As the focus is tunnels brokered by the customer ISP, this aspect
> is, I think, already covered.
>=20
>=20
> > 7.1 I will say "TSP or other existing TB implementations".
>=20
> Good point.
>=20
> > May be a 7.3 to mention ISATAP, same as for TSP and Teredo ?
>=20
> Ok, tell me, why Isatap? I don't understand how it applies here?
>=20
>=20
> > I think we need to ensure that users with dynamic IPv4 address can use=20
> > the service in both modes, but this can be added in a future version.
>=20
> no, we have to do it now! It is covered in the simple mode by 4.3, we=20
> just forgot to mention in in section 5.
> Thanks for catching this.
>=20
>=20
>=20
> > Not sure if best name is "assisted tunneling" or "automatic tunneling=20
> > set-up" ?
>=20
> It is not really automatic... there is a protocol to help an=20
> implementation configuring
> the tunnels. by I'm not hung up on names. I'll go with whatever the wg=20
> would like.
>=20
>


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Wed Apr 14 17:48:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29806
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 17:48:35 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDsDl-000GqU-36
	for v6ops-data@psg.com; Wed, 14 Apr 2004 21:47:01 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDsDj-000GpO-Ju
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 21:46:59 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000009102.msg
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 23:53:20 +0200
Message-ID: <013901c4226a$deec91a0$640a0a0a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <7166B619-8D95-11D8-845C-00039376A6AA@sun.com>
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
Date: Wed, 14 Apr 2004 23:52:56 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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.1165
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 14 Apr 2004 23:53:20 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 14 Apr 2004 23:53:24 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi,

I believe this is a very important work and agree to consider it as a WG item.

Regards,
Jordi

----- Original Message -----=20
From: "Alain Durand" <Alain.Durand@Sun.COM>
To: "IPv6 Operations" <v6ops@ops.ietf.org>; "Pekka Savola" <pekkas@netcore.fi>; <Jonne.Soininen@nokia.com>
Sent: Tuesday, April 13, 2004 11:56 PM
Subject: draft-durand-v6ops-assisted-tunneling-requirements-00.txt


> I would like to request the wg and is chairs to consider
> draft-durand-v6ops-assisted-tunneling-requirements-00.txt
> as a wg item. I have received a number of comments either privately
> and on the ml, I would like to issue a new revision with a=20
> draft-ietf-v6ops title.
>=20
> - Alain.
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Wed Apr 14 18:10:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01423
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 18:10:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDsY7-000Nd1-40
	for v6ops-data@psg.com; Wed, 14 Apr 2004 22:08:03 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDsY2-000NbF-Pd
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 22:07:58 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3EM7wHS014748
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 16:07:58 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW6002AYLH9QG@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Wed, 14 Apr 2004 16:07:58 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW6002T6LGEVI@mail.sun.net> for v6ops@ops.ietf.org; Wed,
 14 Apr 2004 16:07:27 -0600 (MDT)
Date: Wed, 14 Apr 2004 15:07:28 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirements-00
	.txt
In-reply-to: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
To: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
Cc: "'IPv6 Operations '" <v6ops@ops.ietf.org>
Message-id: <1E24099E-8E60-11D8-9419-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Karim,

Thank you for your comment.
See response inline.

	- Alain.

On Apr 14, 2004, at 12:37 PM, Karim El-Malki (HF/EAB) wrote:

> Hi
>
> I have some comments on the draft. Section 2 says:
>
>   - The customer configuration may be diverse, and not necessarily
>        predictable by the ISP. The following cases must be supported:
>          - a single node,
>          - a leaf network,
>          - using a globally routable IPv4 address,
>          - behind a NAT,
>
> However it also says (later in section 2):
>
>    Althought the main focus of this document is the ISP scenario,
>    assisted tunneling is applicable in all the other scenarios:
>    unmanaged, enterprise and 3GPP.
>    ...
>    In 3GPP networks, assisted tunneling can be used in the context of
>    dual stack UE connecting to IPv6 nodes through a 3GPP network that
>    only supports IPv4 PDP contexts [3GPP, 3.1].
>
> There seems to be a contradiction when considering 3GPP networks,
> since the customer does not have a NAT in the customer equipment
> (i.e. mobile terminal). Therefore the tunneling can be terminated
> within the mobile operator's network and never goes through a NAT.
> That's a good thing since we wouldn't have to pass even more traffic
> (v6 tunnelled traffic) through NATs in this scenario. For the same
> reason the following consideration on ISATAP does not apply to 3GPP
> networks (also described in the draft reference [3GPP]):

I think there is a confusion in the lit of cases that must be supported.
This is an ORed list, not an ANDed list, that is we need to design a
protocol that can support all those cases but each of them can happen
separately. Maybe if we reword the text as:
The following cases must be supported:
- the customer has a single node or a complete leaf network
- those nodes are either using globally routable IPv4 addresses
   or are behind one or more NAT.

Note that this does not mean that nodes with globally routable IPv4
addresses will always do IPv6/udp/IPv4 encapsulation (or something like 
that),
it means that the tunnel set-up protocol will determine if a NAT box is 
in the way
and if it is the case, an extra layer of encapsulation is necessary, 
and it will
configure the tunnel accordingly.

So, in the 3GPP case where the customer will have one device with one 
global IPv4 address,
there will be no NAT and there would be no extra encapsulation.

I think it is better to design a single protocol that can accommodate 
many
scenarios than designing a protocol for each scenario.

>
>    7.3 ISATAP
>
>    Similar considerations as Teredo, section 7.2, applies to Isatap.
>    However, as Isatap can not work accross NAT, it is of much less
>    interest in the framework of this document.
>
> I think that to make this draft applicable to 3GPP networks some
> substantial changes would be needed such as the removal of the NAT
> assumption.

Again, there is no assumption that a NAT will always be there. There is 
an assumption that
a NAT may be there, that it will be detected and the encapsulation will 
be different.

I hope this clarifies the points you raised.


	- Alain.




From owner-v6ops@ops.ietf.org  Wed Apr 14 18:13:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01729
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 18:13:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDsbl-000PJV-5n
	for v6ops-data@psg.com; Wed, 14 Apr 2004 22:11:49 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDsbj-000PHf-2z
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 22:11:47 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3EMBbM32375;
	Thu, 15 Apr 2004 01:11:37 +0300
Date: Thu, 15 Apr 2004 01:11:37 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
cc: "'Alain Durand '" <Alain.Durand@Sun.COM>,
        "'IPv6 Operations '" <v6ops@ops.ietf.org>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirements-00
 .txt
In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
Message-ID: <Pine.LNX.4.44.0404150107001.32234-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 14 Apr 2004, Karim El-Malki (HF/EAB) wrote:
>    Althought the main focus of this document is the ISP scenario,
>    assisted tunneling is applicable in all the other scenarios:
>    unmanaged, enterprise and 3GPP.
>    ...
>    In 3GPP networks, assisted tunneling can be used in the context of
>    dual stack UE connecting to IPv6 nodes through a 3GPP network that
>    only supports IPv4 PDP contexts [3GPP, 3.1].
> 
> There seems to be a contradiction when considering 3GPP networks,
> since the customer does not have a NAT in the customer equipment
> (i.e. mobile terminal). Therefore the tunneling can be terminated
> within the mobile operator's network and never goes through a NAT.
> That's a good thing since we wouldn't have to pass even more traffic
> (v6 tunnelled traffic) through NATs in this scenario. For the same
> reason the following consideration on ISATAP does not apply to 3GPP
> networks (also described in the draft reference [3GPP]):
> 
>    7.3 ISATAP
> 
>    Similar considerations as Teredo, section 7.2, applies to Isatap.
>    However, as Isatap can not work accross NAT, it is of much less
>    interest in the framework of this document.
> 
> I think that to make this draft applicable to 3GPP networks some
> substantial changes would be needed such as the removal of the NAT
> assumption.

I do not see the contradiction.

The document just basically says, "we want to support all the 
scenarios, whether it goes through a NAT or not".

In the case of 3GPP, it doesn't go through NAT, but the requirements 
are equally applicable.

On the other hand, as I read it, section 7.3 basically says "ISATAP 
could be supported, but as it is not applicable through a NAT, it 
would only be usable in the scenarios where there is no NAT, so it 
might not be worth the effort plug ISATAP support in the tunnel 
server clients/servers."

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





From owner-v6ops@ops.ietf.org  Wed Apr 14 18:39:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03526
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 18:39:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDt14-000938-4M
	for v6ops-data@psg.com; Wed, 14 Apr 2004 22:37:58 +0000
Received: from [209.71.226.3] (helo=panoramix.hexago.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDt11-00092W-LL
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 22:37:55 +0000
Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22])
	(authenticated bits=0)
	by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i3EMbqvI016129;
	Wed, 14 Apr 2004 18:37:52 -0400 (EDT)
Date: Wed, 14 Apr 2004 18:37:46 -0400
From: Marc Blanchet <Marc.Blanchet@hexago.com>
To: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
cc: "'IPv6 Operations '" <v6ops@ops.ietf.org>
Subject: Re: comments on
 draft-durand-v6ops-assisted-tunneling-requirements-00 .txt
Message-ID: <123690000.1081982266@classic.viagenie.qc.ca>
In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsso
 n.se>
X-Mailer: Mulberry/3.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Karim,
 "dumb questions":
- NAT were not planned to happen. IPv4 was not designed with NAT. NAT
happened. Nobody can control the deployment of NATs.
- now, when you say: 
 + "the customer does not have a NAT in the customer equipment", how can we
enforce/ensure that this will never happen?  

It appears to me that NATs are everywhere, even in places that tried to
avoid them.(The world's richest organisation in terms of IPv4 addresses
have so many NATs you can't think of...). And you can't restrict the
deployment of NAT: the operator of a network (3G, wireless, wired, etc...)
may deploy a NAT as its own way. How would 3G be able to enforce the
non-existence of NATs?

Does the assumption of no-NAT really stand?

excuse-me if these are dumb questions.

Marc.

-- Wednesday, April 14, 2004 21:37:27 +0200 "Karim El-Malki (HF/EAB)"
<karim.el-malki@ericsson.com> wrote/a ecrit:

> Hi
> 
> I have some comments on the draft. Section 2 says:
> 
>   - The customer configuration may be diverse, and not necessarily
>        predictable by the ISP. The following cases must be supported:
>          - a single node,
>          - a leaf network,
>          - using a globally routable IPv4 address,
>          - behind a NAT,
> 
> However it also says (later in section 2):
> 
>    Althought the main focus of this document is the ISP scenario,
>    assisted tunneling is applicable in all the other scenarios:
>    unmanaged, enterprise and 3GPP.
>    ...
>    In 3GPP networks, assisted tunneling can be used in the context of
>    dual stack UE connecting to IPv6 nodes through a 3GPP network that
>    only supports IPv4 PDP contexts [3GPP, 3.1].
> 
> There seems to be a contradiction when considering 3GPP networks,
> since the customer does not have a NAT in the customer equipment
> (i.e. mobile terminal). Therefore the tunneling can be terminated
> within the mobile operator's network and never goes through a NAT.
> That's a good thing since we wouldn't have to pass even more traffic
> (v6 tunnelled traffic) through NATs in this scenario. For the same
> reason the following consideration on ISATAP does not apply to 3GPP
> networks (also described in the draft reference [3GPP]):
> 
>    7.3 ISATAP
> 
>    Similar considerations as Teredo, section 7.2, applies to Isatap.
>    However, as Isatap can not work accross NAT, it is of much less
>    interest in the framework of this document.
> 
> I think that to make this draft applicable to 3GPP networks some
> substantial changes would be needed such as the removal of the NAT
> assumption.
> 
> /Karim
> 



------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------



From owner-v6ops@ops.ietf.org  Wed Apr 14 18:45:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03810
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 18:45:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDt77-000AbQ-4w
	for v6ops-data@psg.com; Wed, 14 Apr 2004 22:44:13 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDt76-000Ab1-0k
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 22:44:12 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3EMhuu14775;
	Wed, 14 Apr 2004 15:43:56 -0700
X-mProtect: <200404142243> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdnxPuJZ; Wed, 14 Apr 2004 15:43:53 PDT
Message-ID: <407DBEB2.2040601@iprg.nokia.com>
Date: Wed, 14 Apr 2004 15:44:02 -0700
From: Fred 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: Pekka Savola <pekkas@netcore.fi>
CC: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "'Alain Durand
 '" <Alain.Durand@Sun.COM>,
        "'IPv6 Operations '" <v6ops@ops.ietf.org>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirements-00
 .txt
References: <Pine.LNX.4.44.0404150107001.32234-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I guess I'll have to take exception to the text of section 7.3 in the
current document version. The sentence:

  "However, as ISATAP cannot work accross NAT, it is of much
   less interest in the framework of this document."

seems more a statement of opinion rather than a statement of fact
born out through analysis.

My suggestion is to simply remove this sentence, since doing so
would remove any opinions/presumptions w/o altering the overall
technical content of the section.

Fred
ftemplin@iprg.nokia.com

Pekka Savola wrote:

>On Wed, 14 Apr 2004, Karim El-Malki (HF/EAB) wrote:
>  
>
>>   Althought the main focus of this document is the ISP scenario,
>>   assisted tunneling is applicable in all the other scenarios:
>>   unmanaged, enterprise and 3GPP.
>>   ...
>>   In 3GPP networks, assisted tunneling can be used in the context of
>>   dual stack UE connecting to IPv6 nodes through a 3GPP network that
>>   only supports IPv4 PDP contexts [3GPP, 3.1].
>>
>>There seems to be a contradiction when considering 3GPP networks,
>>since the customer does not have a NAT in the customer equipment
>>(i.e. mobile terminal). Therefore the tunneling can be terminated
>>within the mobile operator's network and never goes through a NAT.
>>That's a good thing since we wouldn't have to pass even more traffic
>>(v6 tunnelled traffic) through NATs in this scenario. For the same
>>reason the following consideration on ISATAP does not apply to 3GPP
>>networks (also described in the draft reference [3GPP]):
>>
>>   7.3 ISATAP
>>
>>   Similar considerations as Teredo, section 7.2, applies to Isatap.
>>   However, as Isatap can not work accross NAT, it is of much less
>>   interest in the framework of this document.
>>
>>I think that to make this draft applicable to 3GPP networks some
>>substantial changes would be needed such as the removal of the NAT
>>assumption.
>>    
>>
>
>I do not see the contradiction.
>
>The document just basically says, "we want to support all the 
>scenarios, whether it goes through a NAT or not".
>
>In the case of 3GPP, it doesn't go through NAT, but the requirements 
>are equally applicable.
>
>On the other hand, as I read it, section 7.3 basically says "ISATAP 
>could be supported, but as it is not applicable through a NAT, it 
>would only be usable in the scenarios where there is no NAT, so it 
>might not be worth the effort plug ISATAP support in the tunnel 
>server clients/servers."
>
>  
>





From owner-v6ops@ops.ietf.org  Wed Apr 14 19:05:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04629
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 19:05:07 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDtPH-000FM2-7H
	for v6ops-data@psg.com; Wed, 14 Apr 2004 23:02:59 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDtPG-000FLY-0h
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 23:02:58 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3EN2vWo014756
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 17:02:57 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW6003EYO0X4X@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Wed, 14 Apr 2004 17:02:57 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW600M0ZO0VUQ@mail.sun.net> for v6ops@ops.ietf.org; Wed,
 14 Apr 2004 17:02:56 -0600 (MDT)
Date: Wed, 14 Apr 2004 16:02:57 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirements-00
 .txt
In-reply-to: <407DBEB2.2040601@iprg.nokia.com>
To: Fred Templin <ftemplin@iprg.nokia.com>
Cc: Pekka Savola <pekkas@netcore.fi>,
        "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "'IPv6 Operations '" <v6ops@ops.ietf.org>
Message-id: <DEAF6658-8E67-11D8-9419-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0404150107001.32234-100000@netcore.fi>
 <407DBEB2.2040601@iprg.nokia.com>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 14, 2004, at 3:44 PM, Fred Templin wrote:

> I guess I'll have to take exception to the text of section 7.3 in the
> current document version. The sentence:
>
>  "However, as ISATAP cannot work accross NAT, it is of much
>   less interest in the framework of this document."
>
> seems more a statement of opinion rather than a statement of fact
> born out through analysis.

I remenber the NGtrans days when NAT traversial was specifically
a non goal for Isatap. Did things changed?

	- Alain.




From owner-v6ops@ops.ietf.org  Wed Apr 14 19:13:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04902
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 19:13:23 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDtWz-000HiY-1Y
	for v6ops-data@psg.com; Wed, 14 Apr 2004 23:10:57 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDtWy-000HiA-42
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 23:10:56 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3ENAtHS013985
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 17:10:55 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW6003EROE74X@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Wed, 14 Apr 2004 17:10:55 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW600M55OE6UQ@mail.sun.net> for v6ops@ops.ietf.org; Wed,
 14 Apr 2004 17:10:55 -0600 (MDT)
Date: Wed, 14 Apr 2004 16:10:56 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
In-reply-to: <010101c42268$a4f09570$640a0a0a@consulintel.es>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Cc: v6ops@ops.ietf.org
Message-id: <FC321258-8E68-11D8-9419-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0403281757200.22993-200000@netcore.fi>
 <040601c4150a$e9c080e0$273263ce@consulintel.es>
 <DA3F7B18-81A4-11D8-A9F8-00039358A080@sun.com>
 <010101c42268$a4f09570$640a0a0a@consulintel.es>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 14, 2004, at 2:37 PM, JORDI PALET MARTINEZ wrote:

> Hi Alain,
>
> I provide some new comments in-line.
>
> I noticed that in 7.2 you kept "simple mode", probably should be 
> changed to "non-authenticated" to avoid confusions.


Initially,  section 4 was 'simple mode' and was renamed 'non 
authenticated mode' by reference
to the fact that no specific authentication was required.
This is a left over from that time, thank you for pointing it.

Since then, others made the comment that is this mode is restricted to 
the IPv4 ISP customers,
there is already some kind of authentication in place at the IPv4 
layer, thus calling this
'non authenticated' is a bit of a misnomer...

Any suggestion for a alternate name would be welcome.

Actually, this raises another point. Are both modes (authenticated and 
non-authenticated) necessary?
Will ISPs be willing to deploy such tunnels in the mode described in 
section 4. especially
in light of the security considerations discussed in section 4.4?

Any feedback on this topic from operational ISP people would be greatly 
appreciated.

	- Alain.




From owner-v6ops@ops.ietf.org  Wed Apr 14 19:20:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05160
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 19:20:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDteO-000JSu-QN
	for v6ops-data@psg.com; Wed, 14 Apr 2004 23:18:36 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDteN-000JQE-S1
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 23:18:35 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3ENINv11654;
	Wed, 14 Apr 2004 16:18:23 -0700
X-mProtect: <200404142318> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpddpbjzf; Wed, 14 Apr 2004 16:18:21 PDT
Message-ID: <407DC6C6.9020102@iprg.nokia.com>
Date: Wed, 14 Apr 2004 16:18:30 -0700
From: Fred 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>,
        "Karim El-Malki (HF/EAB)"
 <karim.el-malki@ericsson.com>,
        "'IPv6 Operations '" <v6ops@ops.ietf.org>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirements-00
 .txt
References: <Pine.LNX.4.44.0404150107001.32234-100000@netcore.fi> <407DBEB2.2040601@iprg.nokia.com> <DEAF6658-8E67-11D8-9419-00039376A6AA@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Alain Durand wrote:

> I remenber the NGtrans days when NAT traversial was specifically
> a non goal for Isatap. Did things changed?


What I recall is being badgered by someone in a position of
authority to assume that position, so your question could
perhaps better be redirected.

Fred
ftemplin@iprg.nokia.com





From owner-v6ops@ops.ietf.org  Wed Apr 14 19:50:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06193
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 19:50:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDu7v-0002VD-V2
	for v6ops-data@psg.com; Wed, 14 Apr 2004 23:49:07 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDu7t-0002UV-FM
	for v6ops@ops.ietf.org; Wed, 14 Apr 2004 23:49:05 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000009200.msg
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 01:55:28 +0200
Message-ID: <029f01c4227b$ef855130$640a0a0a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <Pine.LNX.4.44.0403281757200.22993-200000@netcore.fi> <040601c4150a$e9c080e0$273263ce@consulintel.es> <DA3F7B18-81A4-11D8-A9F8-00039358A080@sun.com> <010101c42268$a4f09570$640a0a0a@consulintel.es> <FC321258-8E68-11D8-9419-00039376A6AA@sun.com>
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
Date: Thu, 15 Apr 2004 01:55:14 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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.1165
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Thu, 15 Apr 2004 01:55:28 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Thu, 15 Apr 2004 01:55:30 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Alain,

See my comments in-line.

Regards,
Jordi

----- Original Message -----=20
From: "Alain Durand" <Alain.Durand@Sun.COM>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Thursday, April 15, 2004 1:10 AM
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt


>=20
> On Apr 14, 2004, at 2:37 PM, JORDI PALET MARTINEZ wrote:
>=20
> > Hi Alain,
> >
> > I provide some new comments in-line.
> >
> > I noticed that in 7.2 you kept "simple mode", probably should be=20
> > changed to "non-authenticated" to avoid confusions.
>=20
>=20
> Initially,  section 4 was 'simple mode' and was renamed 'non=20
> authenticated mode' by reference
I know ;-)

> to the fact that no specific authentication was required.
> This is a left over from that time, thank you for pointing it.

>=20
> Since then, others made the comment that is this mode is restricted to=20
> the IPv4 ISP customers,
> there is already some kind of authentication in place at the IPv4=20
> layer, thus calling this
> 'non authenticated' is a bit of a misnomer...

I'm not sure to catch this, but let me try ...
Well, in my opinion it depends on the usage done by each ISP deploying it. Some could be willing to keep the service open (even to non-own customers, as today happens with lot's of TBs). Following this rationale, this could support a kind of "anonymous" users (those that access the system with "anonymous/anonymous" user/password ?) or even supporting a mode that doesn't require for sending ANY user/password, right ? I still believe non-authenticated is fine in that case.

>=20
> Any suggestion for a alternate name would be welcome.

But if we are sure that we want to force a kind of "anonymous" authentication (request all the time a user/password but it could be anonymous/anonymous), then an alternative name could be "anonymous mode".

But may be entering in this kind of discussion is going too much further for a requirements document and should be part of the protocol itself ?

>=20
> Actually, this raises another point. Are both modes (authenticated and=20
> non-authenticated) necessary?
> Will ISPs be willing to deploy such tunnels in the mode described in=20
> section 4. especially
> in light of the security considerations discussed in section 4.4?

I think so. Actually is happening, and I feel is still important to allow it in the future to facilitate the deployment.

>=20
> Any feedback on this topic from operational ISP people would be greatly=20
> appreciated.
>=20
> - Alain.
>=20
>=20
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Wed Apr 14 20:34:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08078
	for <v6ops-archive@lists.ietf.org>; Wed, 14 Apr 2004 20:34:58 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BDunD-000DPb-KI
	for v6ops-data@psg.com; Thu, 15 Apr 2004 00:31:47 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BDunC-000DPD-Me
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 00:31:46 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3F0VkWo022592
	for <v6ops@ops.ietf.org>; Wed, 14 Apr 2004 18:31:46 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW600652S4XVM@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Wed, 14 Apr 2004 18:31:46 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW6002JSS4WVP@mail.sun.net> for v6ops@ops.ietf.org; Wed,
 14 Apr 2004 18:31:45 -0600 (MDT)
Date: Wed, 14 Apr 2004 17:31:47 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirements-00
 .txt
In-reply-to: <407DC6C6.9020102@iprg.nokia.com>
To: Fred Templin <ftemplin@iprg.nokia.com>
Cc: "'IPv6 Operations '" <v6ops@ops.ietf.org>
Message-id: <47BF2318-8E74-11D8-9419-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0404150107001.32234-100000@netcore.fi>
 <407DBEB2.2040601@iprg.nokia.com>
 <DEAF6658-8E67-11D8-9419-00039376A6AA@sun.com>
 <407DC6C6.9020102@iprg.nokia.com>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Fred,

I read isatap-20 draft, section 8.1.1 NAT Traversal.

Could you explain me how this is suppose to work in the following 
situation:

Node A 192.168.1.2 |--  NAT (IPa) -------- (IPb) NAT --| Node C 
192.168.1.2
Node B 192.168.1.3 |                                                    
      | Node D 192.168.1.3

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 06:34:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15881
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 06:34:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BE49g-000CBT-RL
	for v6ops-data@psg.com; Thu, 15 Apr 2004 10:31:36 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BE49c-000CAr-Rz
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 10:31:33 +0000
Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3FAVVPA019028
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 12:31:31 +0200 (MEST)
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 15 Apr 2004 12:31:31 +0200
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id 25KSWQJX; Thu, 15 Apr 2004 12:31:37 +0200
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY0CNHY>; Thu, 15 Apr 2004 12:31:31 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E3B3@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: ee445845 2c4885b5 1455e070 00000138
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Fred Templin'" <ftemplin@iprg.nokia.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: RE: FYI Isatap implementations info
Date: Thu, 15 Apr 2004 12:30:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 15 Apr 2004 10:31:31.0413 (UTC) FILETIME=[D15C8850:01C422D4]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Hi,

Please find my Comments in line.

BR, Karen

[snip]
> >
> >Host implementation particularities:
> >
> >Direct tunneling to/from on-link addresses is allowed
> >(on-link equal to prefixes received in RAs).
> >
> 
> To my understanding, "on-link" should also include link-local 
> - correct?

Correct.

> 
> >The following security checks are applied
> >on incoming packets:
> >
> >Either the v6 src must be on-link 
> >and match the v4 src - or the v4 src is from a router in PRL.
> >In addition RA's are always checked to ensure that
> >v6 src matches v4 src and that the v4 src must be in PRL.
> >
> >Router Implementation particularities:
> >
> >Only Router-to-host communication is supported, that is, 
> >PRL list not maintained on Router interfaces. 
> >The following security checks are applied
> >on incoming packets:
> >
> >The inner IPv6 source address has a prefix configured (i.e. 
> advertised)
> >
> 
> Again, to my understanding link-locals should also be included,
> whereas "(i.e. advertised)" would seem to exclude them.
> 
> 

Yes, you're right. The link-local prefix is also accepted.

>on the ISATAP interface and an ISATAP-format interface 
> identifier that 
> >embeds the IPv4 source address of the outer header.
> >
> 
> Conspicuous by its absence here is the secondary check for
> "v4 src is from a router in the PRL", but I note that you have
> already stated that the PRL is not maintained on Router interfaces
> in your implementation.
> 

Yes, packets not fulfilling the above check are silently discarded.
(That is, packets forwarded using Isatap encapsulation
from a router are not accepted.)

> >v6inv4 Configured tunnels anchored on an Ipv4
> > address also used by the Isatap interface
> >will have precedence over the Isatap interface, i.e.,
> >incoming packets will be processed by the configured tunnel 
> interface 
> >implementation and not the Isatap interface implementation.
> >
> 
> Agreed.
> 
> >(Further, Isatap interfaces take precedence over 6to4 interfaces.)
> >
> 
> By "take precedence" here, I assume you mean that the received packets
>  should be decapsulated/filtered as per the specification of 
> precedence
> (6to4 or ISATAP) - correct?  This is a (somewhat) unresolved aspect
> of the "Re: ISATAP, v6inv4 and 6to4 ..." discussion thread. 

Yes, I am aware of that.
This was strictly to give the particularities 
of the current implementation in use. Not necessary to say
how it should end up being.

 In further
> thinking on this, I believe the correct answer is not quite 
> as simple as
> you are stating it here - but almost:
> 
> If a 6to4 interface and ISATAP interface are configured over the same
> IPv4 address, it would have to be a global IPv4 address assigned to an
> interface connected to the global Internet due to 6to4 
> requirements. In
> that case, I believe the correct behavior should be for the 
> 6to4 interface
> to take precedence for packets received with an on-link 6to4 prefix in
> the IPv6 destination, and for the ISATAP interface to take precedence
> for all others. Comments?
> 

When I say takes precedence over I (still) mean the following:
First Priority:	If the prefix of the source address in the inner 
     IPv6 header of the encapsulated packet matches a prefix of the 
     ISATAP interface, the packet is processed by this tunnel interface.
Second Priority:	If the prefix of either the source or destination address 
      in the inner IPv6 header is a 6to4 prefix, the packet 
      is processed by the 6to4 tunnel interface.

**Here again it should be emphasized that these rules are not intended to
apply to the Isatap router-to-router tunnelling situation.**

I am not 100 % sure what you mean by an on-link 6to4 prefix.

I can imagine that you refer to one of the following 2 situations:
(I)
 _ _ _ _                         - - - - - - - - - - - - - - 
|       |     ___               |  Global Internet/exterior  |         
|  6to4 |-v6-/ R \              | _ _ _ _ _                  |
|  Site |    \___/-globalV4ADDR-|   Intra  |                 |
|_ _ _ _|                       |   -site  |                 | 
                                 - - - - - - - - - - - - - - 
 
(II)                     - - - - - - - - - - 
     ___               |  Global Internet/   |         
    / R \              | _ _ _ _ _   exterior|
    \___/-globalV4ADDR-|   Intra   |         |                   
                       |   -site   |         | 
                       |   of 6to4 |         |   
                       |  prefix   |         | 
                        - - - - - - - - - -

In both situations a packet with the mentioned inner source address
should be from within the intra-site and should be processed by the Isatap
interface and not the 6to4 interface turned towards the exterior.

In (I), then in our 6to4 implementation, the packet with the mentioned source address,
will be discarded by the 6to4 tunnel interfaces as we rely on trusted relay routers.
It wil not be accepted as a packet from a 6to4 border router since the v6 and the v4 sources
don't add up.

In (II)
The packet is a packet coming from and destined for the Intra-site and should
be processed by the intra-site router interface (i.e. the Isatap
interface).  Again
the 6to4 interface would discard the packet,
further It should be redirected but thats another matter.

> >
> >Security threat model:
> >
> >The above security checks have been modeled
> >according to environments where the site perimeter
> >is guarded and where either:
> >* intra-site IPv4 address spoofing isn't possible (e.g. 3G telecom)
> >* intra-site nodes are trustworthy
> >
> 
> I'm tempted to add a third bullet to your list:
> 
>   * intra-site communications are restricted to router<->host only
> 
> but perhaps this is implicitly covered by one of the other two?
> 

Intra-site router-to-router is considered out of the question and
is not supported in our implementation.

Whether or not Intra-site host-to-host should be banned in all
situations (and in particular in the situations mentioned
above) is not 100 % clear to me yet (and yes the current
configurations that we deploy, allow for it, but at the same
time we can also easily ban it).

Please let me address this issue in a seperate email.

BR, Karen




From owner-v6ops@ops.ietf.org  Thu Apr 15 12:44:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03843
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 12:44:40 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BE9vC-000D7g-AF
	for v6ops-data@psg.com; Thu, 15 Apr 2004 16:41:02 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BE9ux-000D4w-7h
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 16:40:47 +0000
Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3FGekWR008648
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 18:40:46 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 15 Apr 2004 18:40:45 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <25R3NV5C>; Thu, 15 Apr 2004 18:40:45 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B87@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'Pekka Savola '" <pekkas@netcore.fi>
Cc: "''Alain Durand ' '" <Alain.Durand@Sun.COM>,
        "''IPv6 Operations ' '"
	 <v6ops@ops.ietf.org>
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement
	s-00 .txt
Date: Thu, 15 Apr 2004 18:40:22 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 15 Apr 2004 16:40:45.0966 (UTC) FILETIME=[66810AE0:01C42308]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>> On Wed, 14 Apr 2004, Karim El-Malki (HF/EAB) wrote:
>>    Althought the main focus of this document is the ISP scenario,
>>    assisted tunneling is applicable in all the other scenarios:
>>    unmanaged, enterprise and 3GPP.
>>    ...
>>    In 3GPP networks, assisted tunneling can be used in the context of
>>    dual stack UE connecting to IPv6 nodes through a 3GPP network that
>>    only supports IPv4 PDP contexts [3GPP, 3.1].
>> 
>> There seems to be a contradiction when considering 3GPP networks,
>> since the customer does not have a NAT in the customer equipment
>> (i.e. mobile terminal). Therefore the tunneling can be terminated
>> within the mobile operator's network and never goes through a NAT.
>> That's a good thing since we wouldn't have to pass even more traffic
>> (v6 tunnelled traffic) through NATs in this scenario. For the same
>> reason the following consideration on ISATAP does not apply to 3GPP
>> networks (also described in the draft reference [3GPP]):
>> 
>>    7.3 ISATAP
>> 
>>    Similar considerations as Teredo, section 7.2, applies to Isatap.
>>    However, as Isatap can not work accross NAT, it is of much less
>>    interest in the framework of this document.
>> 
>> I think that to make this draft applicable to 3GPP networks some
>> substantial changes would be needed such as the removal of the NAT
>> assumption.
>
>I do not see the contradiction.
>
>The document just basically says, "we want to support all the 
>scenarios, whether it goes through a NAT or not".

A solution requiring NAT traversal will end up being very different
from one not requiring it, so it is an important point IMO.
Ths draft says that the solution must support NAT traversal, and this
feature is not applicable to 3gpp. So this requirement would
end up in a solution that is designed for something that is not
useful (and potentially a disadvantage) for 3gpp networks. I see
that as a problem.

>In the case of 3GPP, it doesn't go through NAT, but the requirements 
>are equally applicable.

I disagree. The requirement that the solution must work through NATs
is not applicable to 3GPP. The fact that the NAT traversal solution
may also happen to work in 3GPP doesn't mean it is the right thing to
be deployed there.

>On the other hand, as I read it, section 7.3 basically says "ISATAP 
>could be supported, but as it is not applicable through a NAT, it 
>would only be usable in the scenarios where there is no NAT, so it 
>might not be worth the effort plug ISATAP support in the tunnel 
>server clients/servers."

Well it says that "it is of much less interest in the framework of
this document.". This is essentially saying "not needed".
Since the document describes tunnelling requirements also applicable
to 3GPP I don't think this wording applies to ISATAP.

/Karim



From owner-v6ops@ops.ietf.org  Thu Apr 15 13:00:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04716
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 13:00:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEABQ-000IiP-MI
	for v6ops-data@psg.com; Thu, 15 Apr 2004 16:57:48 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEABE-000IU4-RS
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 16:57:36 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3FGvaWo000153
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 10:57:36 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW8009441RZ01@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 10:57:36 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW8002GI1RYVP@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 10:57:35 -0600 (MDT)
Date: Thu, 15 Apr 2004 09:57:33 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement	s-00
 .txt
In-reply-to: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B87@ESEALNT442.al.sw.ericsson.se>
To: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
Cc: "'Pekka Savola '" <pekkas@netcore.fi>,
        "''IPv6 Operations ' '" <v6ops@ops.ietf.org>
Message-id: <FD47C26D-8EFD-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B87@ESEALNT442.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

IP support routing. 3GPP does not support routing in the handset.
Does this makes IP not suitable for 3GPP?
No. You simply do not use this feature.
Same analogy applies here. We are not trying to design something
that works only in the 3GPP case, but can works elsewhere as well.

Btw, Marc's Blanchet point is very good: how can you be sure that
there never will be any NAT?

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 13:08:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05308
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 13:08:12 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEAJq-000LlC-N9
	for v6ops-data@psg.com; Thu, 15 Apr 2004 17:06:30 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEAIM-000LNv-1u
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 17:04:58 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3FH4vAh023230
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 19:04:57 +0200
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 15 Apr 2004 19:04:56 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <25R3N5N8>; Thu, 15 Apr 2004 19:04:56 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B88@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'Marc Blanchet '" <Marc.Blanchet@hexago.com>
Cc: "''IPv6 Operations ' '" <v6ops@ops.ietf.org>
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement
	s-00 .txt
Date: Thu, 15 Apr 2004 19:04:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
X-Mailer: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 15 Apr 2004 17:04:56.0809 (UTC) FILETIME=[C7461D90:01C4230B]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Marc

>Karim,
> "dumb questions":
>- NAT were not planned to happen. IPv4 was not designed with NAT. NAT
>happened. Nobody can control the deployment of NATs.
>- now, when you say: 
> + "the customer does not have a NAT in the customer equipment", how can
>we
>enforce/ensure that this will never happen?

Well, now there is a deployable alternative with IPv6.
It's impossible to be 100% sure of things, but saying that it
is OK to put a NAT in a mobile phone at the time when mobile
manufacturers are going to dual-stack terminals doesn't make
sense to me.
  
>
>It appears to me that NATs are everywhere, even in places that tried to
>avoid them.(The world's richest organisation in terms of IPv4 addresses
>have so many NATs you can't think of...). And you can't restrict the
>deployment of NAT: the operator of a network (3G, wireless, wired,
>etc...)
>may deploy a NAT as its own way. How would 3G be able to enforce the
>non-existence of NATs?

There are no NATs in mobile phones today since there is no use
for them and I sure hope never to see them. I think most people
would agree. So there is nothing today that hints at this
development and I think we should not be proposing solutions
that are compatible with this.

Mobile manufacturers will be shipping dual-stack mobile terminals
and that is what we should be (and are) favouring. If a PAN is
needed behind the terminal then it's an excellent case for using
IPv6. Supporting NAT traversal mechanisms in this scenario seems
very dangerous to me and it doesn't help since we really want to
reduce the use of NATs if possible, not increase the traffic
through them.

>Does the assumption of no-NAT really stand?

I think it does.

/Karim



From owner-v6ops@ops.ietf.org  Thu Apr 15 13:26:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06555
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 13:26:12 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEAay-000ORS-9D
	for v6ops-data@psg.com; Thu, 15 Apr 2004 17:24:12 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEAaX-000OLN-UD
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 17:23:45 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3FHNjWo015904
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 11:23:45 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW800BPY2ZKPI@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 11:23:45 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW800B2O2ZJGI@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 11:23:44 -0600 (MDT)
Date: Thu, 15 Apr 2004 10:23:42 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement	s-00
 .txt
In-reply-to: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B88@ESEALNT442.al.sw.ericsson.se>
To: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
Cc: "'Marc Blanchet '" <Marc.Blanchet@hexago.com>,
        "''IPv6 Operations ' '" <v6ops@ops.ietf.org>
Message-id: <A4B56773-8F01-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B86@ESEALNT442.al.sw.ericsson.se>
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B88@ESEALNT442.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 15, 2004, at 10:04 AM, Karim El-Malki (HF/EAB) wrote:
>
> There are no NATs in mobile phones today since there is no use
> for them and I sure hope never to see them. I think most people
> would agree.

Let me disagree.
The scenario is a remote location or road warrior where the only 
possible/realistic
connectivity is through 3GPP/3GPP2. That may be an intermittent case 
when 802.11
is not available.
I'd like to get a 3GPP network attachment on a computer 
(PCMCIA/PCI/USB/Bluetooth...)
or 802.11 access point and run a NAT there. It would act as a router 
for the rest of my network.
Now, any device within my network that desire to get IPv6 connectivity
will have to go through that NAT.

	 Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 13:33:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07694
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 13:33:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEAhx-00005E-Pd
	for v6ops-data@psg.com; Thu, 15 Apr 2004 17:31:25 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEAh8-000PjV-5F
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 17:30:34 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3FHUXAh025623
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 19:30:33 +0200
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 15 Apr 2004 19:30:32 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <25R3N01X>; Thu, 15 Apr 2004 19:30:32 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8C@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'Alain Durand '" <Alain.Durand@Sun.COM>
Cc: "''Pekka Savola ' '" <pekkas@netcore.fi>,
        "'''IPv6 Operations ' ' '"
	 <v6ops@ops.ietf.org>
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement
		s-00 .txt
Date: Thu, 15 Apr 2004 19:30:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Mailer: Apple Mail (2.613)
References: Apple Mail (2.613)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 15 Apr 2004 17:30:32.0766 (UTC) FILETIME=[5AC68DE0:01C4230F]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>IP support routing. 3GPP does not support routing in the handset.
>Does this makes IP not suitable for 3GPP?
>No. You simply do not use this feature.
>Same analogy applies here. We are not trying to design something
>that works only in the 3GPP case, but can works elsewhere as well.

Your analogy doesn't fit at all IMO. You are comparing implementing
an IPv6 mobile router with an IPv4 NAT in a mobile phone. IMO an
IPv6 mobile router in a terminal is a good thing for the future of
IPv6 in 3gpp nets while a NAT is absolutely not.

/Karim



From owner-v6ops@ops.ietf.org  Thu Apr 15 13:42:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08198
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 13:42:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEAqa-0002C3-5Z
	for v6ops-data@psg.com; Thu, 15 Apr 2004 17:40:20 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEAqM-00024g-4m
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 17:40:06 +0000
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3FHe5Ah026492
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 19:40:05 +0200
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 15 Apr 2004 19:40:04 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <25R33B1T>; Thu, 15 Apr 2004 19:40:04 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'Alain Durand '" <Alain.Durand@Sun.COM>
Cc: "''Marc Blanchet ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement
		s-00 .txt
Date: Thu, 15 Apr 2004 19:39:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Mailer: Apple Mail (2.613)
References: Apple Mail (2.613)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 15 Apr 2004 17:40:04.0742 (UTC) FILETIME=[AFB32A60:01C42310]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>>
>> There are no NATs in mobile phones today since there is no use
>> for them and I sure hope never to see them. I think most people
>> would agree.
>
>Let me disagree.
>The scenario is a remote location or road warrior where the only 
>possible/realistic
>connectivity is through 3GPP/3GPP2. That may be an intermittent case 
>when 802.11
>is not available.
>I'd like to get a 3GPP network attachment on a computer 
>(PCMCIA/PCI/USB/Bluetooth...)
>or 802.11 access point and run a NAT there. It would act as a router 
>for the rest of my network.
>Now, any device within my network that desire to get IPv6 connectivity
>will have to go through that NAT.

You wouldn't need or want a NAT for that.
We are recommending that there should be IPv6 support (native
if possible otherwise tunnelled) by the 3GPP/2 operator. That's
the essence of the 3GPP analysis draft. So you can make your
terminal/laptop into an IPv6 mobile router (tunnelling or native
to the 3gpp/2 operator) and not get into the NAT headache. Since
there is a better solution than NAT I think we should use it.

/Karim



From owner-v6ops@ops.ietf.org  Thu Apr 15 13:46:14 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08446
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 13:46:13 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEAu1-0003IW-N2
	for v6ops-data@psg.com; Thu, 15 Apr 2004 17:43:53 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEAtx-0003Ho-Fh
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 17:43:49 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3FHhnWo027274
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 11:43:49 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW8009343X001@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 11:43:49 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW8002TV3WZVP@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 11:43:48 -0600 (MDT)
Date: Thu, 15 Apr 2004 10:43:46 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00
 .txt
In-reply-to: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se>
To: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
Cc: "''Marc Blanchet ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: Apple Mail
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 15, 2004, at 10:39 AM, Karim El-Malki (HF/EAB) wrote:

>>>
>>> There are no NATs in mobile phones today since there is no use
>>> for them and I sure hope never to see them. I think most people
>>> would agree.
>>
>> Let me disagree.
>> The scenario is a remote location or road warrior where the only
>> possible/realistic
>> connectivity is through 3GPP/3GPP2. That may be an intermittent case
>> when 802.11
>> is not available.
>> I'd like to get a 3GPP network attachment on a computer
>> (PCMCIA/PCI/USB/Bluetooth...)
>> or 802.11 access point and run a NAT there. It would act as a router
>> for the rest of my network.
>> Now, any device within my network that desire to get IPv6 connectivity
>> will have to go through that NAT.
>
> You wouldn't need or want a NAT for that.

Yes I want it for my IPv4 connections.

> We are recommending that there should be IPv6 support (native
> if possible otherwise tunnelled) by the 3GPP/2 operator. That's
> the essence of the 3GPP analysis draft. So you can make your
> terminal/laptop into an IPv6 mobile router (tunnelling or native
> to the 3gpp/2 operator) and not get into the NAT headache. Since
> there is a better solution than NAT I think we should use it.

Of course, but I though we were talking about the case where the 3GPP
ISP was not (yet) offering IPv6 service.

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 13:57:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09005
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 13:57:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEB5a-0006GN-Hg
	for v6ops-data@psg.com; Thu, 15 Apr 2004 17:55:50 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEB5U-0006Ez-Qk
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 17:55:44 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3FHtbG04437;
	Thu, 15 Apr 2004 10:55:37 -0700
X-mProtect: <200404151755> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdVrocvK; Thu, 15 Apr 2004 10:55:34 PDT
Message-ID: <407ECCA4.1000308@iprg.nokia.com>
Date: Thu, 15 Apr 2004 10:55:48 -0700
From: Fred 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: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "''Marc Blanchet
 ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '"
 <v6ops@ops.ietf.org>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement
 s-00 .txt
References: Apple Mail <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se> <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Alain Durand wrote:

>
> On Apr 15, 2004, at 10:39 AM, Karim El-Malki (HF/EAB) wrote:
>
>> You wouldn't need or want a NAT for that.
>
>
> Yes I want it for my IPv4 connections.


I'm OK with this, as long as you clearly distinguish
"IPv4 connections" from IPv6-in-IPv4 tunneling.

Fred
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Thu Apr 15 14:01:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09350
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 14:01:27 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEB9a-0007Zg-O7
	for v6ops-data@psg.com; Thu, 15 Apr 2004 17:59:58 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEB9P-0007YW-96
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 17:59:47 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3FHxkHS022709
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 11:59:46 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW800BBC4NMPI@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 11:59:46 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW800BCE4NLGV@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 11:59:46 -0600 (MDT)
Date: Thu, 15 Apr 2004 10:59:43 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00
 .txt
In-reply-to: <407ECCA4.1000308@iprg.nokia.com>
To: Fred Templin <ftemplin@iprg.nokia.com>
Cc: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "''Marc Blanchet ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <ACC5BFD8-8F06-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: Apple Mail
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se>
 <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com>
 <407ECCA4.1000308@iprg.nokia.com>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 15, 2004, at 10:55 AM, Fred Templin wrote:

> Alain Durand wrote:
>
>>
>> On Apr 15, 2004, at 10:39 AM, Karim El-Malki (HF/EAB) wrote:
>>
>>> You wouldn't need or want a NAT for that.
>>
>>
>> Yes I want it for my IPv4 connections.
>
>
> I'm OK with this, as long as you clearly distinguish
> "IPv4 connections" from IPv6-in-IPv4 tunneling.

??? Please elaborate.

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 14:18:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10675
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 14:18:58 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEBQJ-000CAw-S4
	for v6ops-data@psg.com; Thu, 15 Apr 2004 18:17:15 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEBPr-000C5I-4w
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 18:16:47 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3FIGjWR021519
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 20:16:45 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 15 Apr 2004 20:16:45 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <25R332NP>; Thu, 15 Apr 2004 20:16:45 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8F@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'Alain Durand '" <Alain.Durand@Sun.COM>
Cc: "'''Marc Blanchet ' ' '" <Marc.Blanchet@hexago.com>,
        "''''IPv6 Operations ' ' ' '" <v6ops@ops.ietf.org>
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement
	 s-00 .txt
Date: Thu, 15 Apr 2004 20:16:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Mailer: Apple Mail (2.613)
References: Apple Mail (2.613)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 15 Apr 2004 18:16:45.0536 (UTC) FILETIME=[CF79AE00:01C42315]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>>>
>>> There are no NATs in mobile phones today since there is no use
>>> for them and I sure hope never to see them. I think most people
>>> would agree.
>>
>> Let me disagree.
>> The scenario is a remote location or road warrior where the only
>> possible/realistic
>> connectivity is through 3GPP/3GPP2. That may be an intermittent case
>> when 802.11
>> is not available.
>> I'd like to get a 3GPP network attachment on a computer
>> (PCMCIA/PCI/USB/Bluetooth...)
>> or 802.11 access point and run a NAT there. It would act as a router
>> for the rest of my network.
>> Now, any device within my network that desire to get IPv6
connectivity
>> will have to go through that NAT.
>
> You wouldn't need or want a NAT for that.

Yes I want it for my IPv4 connections.

Karim: Fine but this is not your typical mobile phone today and
I don't think we should be making IPv6 designs based on possible
future NAT proliferation in mobile phones. Basically I don't see
why we need a special mechanism that supports NAT traversal when
it's not applicable now or in the foreseeable future and more
importantly when we don't want to see this happening. Looking at
it from an apps viewpoint, if I anyway need to use a NAT traversal
protocol I might as well use IPv4-only for my p2p, push etc. app.s
So I don't see a case for IPv6 access through NATs in the
3gpp/2 world. However there obviously is a case for it in
fixed ISPs where NATs are present in customer networks, so the
mechanism is useful.

> We are recommending that there should be IPv6 support (native
> if possible otherwise tunnelled) by the 3GPP/2 operator. That's
> the essence of the 3GPP analysis draft. So you can make your
> terminal/laptop into an IPv6 mobile router (tunnelling or native
> to the 3gpp/2 operator) and not get into the NAT headache. Since
> there is a better solution than NAT I think we should use it.

Of course, but I though we were talking about the case where the 3GPP
ISP was not (yet) offering IPv6 service.

Karim: That case is excluded by the 3GPP analysis draft. We assume
and recommend some form of support from the 3gpp operator.

/Karim



From owner-v6ops@ops.ietf.org  Thu Apr 15 14:19:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10723
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 14:19:13 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEBQ0-000C6R-W5
	for v6ops-data@psg.com; Thu, 15 Apr 2004 18:16:56 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEBPh-000C3A-Rk
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 18:16:38 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3FIGUS29824;
	Thu, 15 Apr 2004 11:16:30 -0700
X-mProtect: <200404151816> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdldYmYJ; Thu, 15 Apr 2004 11:16:22 PDT
Message-ID: <407ED183.5060204@iprg.nokia.com>
Date: Thu, 15 Apr 2004 11:16:35 -0700
From: Fred 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: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "''Marc Blanchet
 ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '"
 <v6ops@ops.ietf.org>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement
 s-00 .txt
References: Apple Mail <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se> <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com> <407ECCA4.1000308@iprg.nokia.com> <ACC5BFD8-8F06-11D8-BB4F-00039376A6AA@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



Alain Durand wrote:

>
> On Apr 15, 2004, at 10:55 AM, Fred Templin wrote:
>
>> Alain Durand wrote:
>>
>>>
>>> On Apr 15, 2004, at 10:39 AM, Karim El-Malki (HF/EAB) wrote:
>>>
>>>> You wouldn't need or want a NAT for that.
>>>
>>>
>>>
>>> Yes I want it for my IPv4 connections.
>>
>>
>>
>> I'm OK with this, as long as you clearly distinguish
>> "IPv4 connections" from IPv6-in-IPv4 tunneling.
>
>
> ??? Please elaborate. 


Only that, from the perspective of IPv6-in-IPv4 tunneling, it
would be nice if any "NATs" behaved more like an ND Proxy.

This would not be the same thing as an "IPv6 NAT", which
I hope we will never see.

Fred
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Thu Apr 15 14:43:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12316
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 14:43:02 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEBnQ-000HiU-OK
	for v6ops-data@psg.com; Thu, 15 Apr 2004 18:41:08 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEBnK-000Hgm-JK
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 18:41:02 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3FIf2HS016705
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 12:41:02 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW800B8R6KDPI@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 12:41:02 -0600 (MDT)
Received: from [192.168.1.100] ([129.150.16.63])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW800MQN6KBUQ@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 12:41:01 -0600 (MDT)
Date: Thu, 15 Apr 2004 11:40:58 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00
 .txt
In-reply-to: <407ED183.5060204@iprg.nokia.com>
To: Fred Templin <ftemplin@iprg.nokia.com>
Cc: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "''Marc Blanchet ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <6FA21CC5-8F0C-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: Apple Mail
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se>
 <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com>
 <407ECCA4.1000308@iprg.nokia.com>
 <ACC5BFD8-8F06-11D8-BB4F-00039376A6AA@sun.com>
 <407ED183.5060204@iprg.nokia.com>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 15, 2004, at 11:16 AM, Fred Templin wrote:

> This would not be the same thing as an "IPv6 NAT", which
> I hope we will never see.

Note that I'm not advocating for IPv6 NAT here. I'm saying that
IPv4 NAT is almost everywhere and during the transition to
IPv6, in the phase where the ISPs do not yet support full
native IPv6 in the access network, we must take into account
that IPv4 NAT may be in the way.

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 14:58:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13005
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 14:58:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEC2A-000KTy-DI
	for v6ops-data@psg.com; Thu, 15 Apr 2004 18:56:22 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEC1h-000KSC-Vp
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 18:55:54 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3FItrHS024799
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 12:55:53 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW800B9B795PI@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 12:55:53 -0600 (MDT)
Received: from [192.168.1.100] ([129.150.16.63])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW800M0T793UQ@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 12:55:53 -0600 (MDT)
Date: Thu, 15 Apr 2004 11:55:50 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00
 .txt
In-reply-to: 
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8F@ESEALNT442.al.sw.ericsson.se>
To: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
Cc: "''''IPv6 Operations ' ' ' '" <v6ops@ops.ietf.org>,
        "'''Marc Blanchet ' ' '" <Marc.Blanchet@hexago.com>
Message-id: <832B263B-8F0E-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: Apple Mail
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8F@ESEALNT442.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 15, 2004, at 11:16 AM, Karim El-Malki (HF/EAB) wrote:

> Karim: Fine but this is not your typical mobile phone today and
> I don't think we should be making IPv6 designs based on possible
> future NAT proliferation in mobile phones.

I would not bet 0.10$ on that. IPv4 NAT is everywhere. You will be 
assimilated....
(quote from a famous old IETF T-Shirt)

Note: I am not a proponent of NAT. Just a pragmatic person.

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 14:58:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13027
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 14:58:55 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEC1v-000KTS-Lg
	for v6ops-data@psg.com; Thu, 15 Apr 2004 18:56:07 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEC1j-000KSJ-Jy
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 18:55:55 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3FItqx13244;
	Thu, 15 Apr 2004 11:55:52 -0700
X-mProtect: <200404151855> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdxk6079; Thu, 15 Apr 2004 11:55:48 PDT
Message-ID: <407EDAC2.7060409@iprg.nokia.com>
Date: Thu, 15 Apr 2004 11:56:02 -0700
From: Fred 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: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: 6to4; ISATAP interfaces configured over same IPv4 address (was: Re:
 FYI Isatap implementations info)
References: <C26BB8276599A44B85D52F9CE41035E10229E3B3@esealnt944.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Karen,

I'll focus on just the 6to4/isatap stuff for now if you don't mind:

Karen E. Nielsen (AH/TED) wrote:

>Fred Templin wrote:
>  
>
>>If a 6to4 interface and ISATAP interface are configured over the same
>>IPv4 address, it would have to be a global IPv4 address assigned to an
>>interface connected to the global Internet due to 6to4 
>>requirements. In
>>that case, I believe the correct behavior should be for the 
>>6to4 interface
>>to take precedence for packets received with an on-link 6to4 prefix in
>>the IPv6 destination, and for the ISATAP interface to take precedence
>>for all others. Comments?
>>    
>>
>
>When I say takes precedence over I (still) mean the following:
>First Priority:	If the prefix of the source address in the inner 
>     IPv6 header of the encapsulated packet matches a prefix of the 
>     ISATAP interface, the packet is processed by this tunnel interface.
>

This would seem like the correct natural choice, since it seems consistent
with the notion of "intra-site". Again, I assume by this you are intending
to include link-locals? (Perhaps that's *all* you are intending to include?)

>Second Priority: If the prefix of either the source or destination address 
>      in the inner IPv6 header is a 6to4 prefix, the packet 
>      is processed by the 6to4 tunnel interface.
>

Let's take a closer look at the cases; please tell me if I mis-represent 
anything:

  1) If both the source and destination are 6to4, then the packet is 
originating
     and terminating within the 6to4 domain. So, use of the 6to4 
interface would
     seem natural and appropriate. (Note that the destination might not 
belong to
     *this* 6to4 router in which case L3 might forward (redirect?) the 
packet to
     the correct 6to4 router - but, this is irrelevant for L2.5 
decapsulation.)

  2) If the destination is 6to4, but the source is not 6to4, then the 
packet is
     originating from behind a 6to4 relay router and terminating within the
     6to4 domain. Again, the 6to4 interface seems the natural choice.

  3) If the source is 6to4, but the destination is not 6to4, then the packet
     is originating from within the 6to4 domain and will eventually
     terminate within the native IPv6 Internet. To do this, it will have
     to transition from the 6to4 domain to the native IPv6 Internet via
     a relay router which may/may not occur on *this* 6to4 router.

     Is the 6to4 interface the correct interface to decapsulate for this 
case?
     It seems somewhat less obvious to me, but still a better choice than
     the ISATAP interface when the source prefix is not on-link.

>**Here again it should be emphasized that these rules are not intended to
>apply to the Isatap router-to-router tunnelling situation.**
>

I am fine with leaving this aspect out from the current discussion.

>I am not 100 % sure what you mean by an on-link 6to4 prefix.
>

I think I may have been stuck with a mis-conception that 6to4 interfaces
should only decapsulate packets with an IPv6 destination prefix of
2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the
node's IPv4 interfaces.

>I can imagine that you refer to one of the following 2 situations:
>(I)
> _ _ _ _                         - - - - - - - - - - - - - - 
>|       |     ___               |  Global Internet/exterior  |         
>|  6to4 |-v6-/ R \              | _ _ _ _ _                  |
>|  Site |    \___/-globalV4ADDR-|   Intra  |                 |
>|_ _ _ _|                       |   -site  |                 | 
>                                 - - - - - - - - - - - - - - 
> 
>(II)                     - - - - - - - - - - 
>     ___               |  Global Internet/   |         
>    / R \              | _ _ _ _ _   exterior|
>    \___/-globalV4ADDR-|   Intra   |         |                   
>                       |   -site   |         | 
>                       |   of 6to4 |         |   
>                       |  prefix   |         | 
>                        - - - - - - - - - -
>
>In both situations a packet with the mentioned inner source address
>should be from within the intra-site and should be processed by the Isatap
>interface and not the 6to4 interface turned towards the exterior.
>
>In (I), then in our 6to4 implementation, the packet with the mentioned source address,
>will be discarded by the 6to4 tunnel interfaces as we rely on trusted relay routers.
>It wil not be accepted as a packet from a 6to4 border router since the v6 and the v4 sources
>don't add up.
> 
>In (II)
>The packet is a packet coming from and destined for the Intra-site and should
>be processed by the intra-site router interface (i.e. the Isatap
>interface).  Again
>the 6to4 interface would discard the packet,
>further It should be redirected but thats another matter.
>

I'm not prepared to comment on this in detail since I'm not entirely sure
what you are referring to by "the mentioned inner source address", and
your examples might have been motivated by the misconception I mentioned
above. Perhaps this discussion is obviated by the examination of the cases
I provided earlier?

Fred
ftemplin@iprg.nokia.com






From owner-v6ops@ops.ietf.org  Thu Apr 15 15:01:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13251
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 15:01:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEC5j-000LBE-IG
	for v6ops-data@psg.com; Thu, 15 Apr 2004 19:00:03 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEC5b-000L8b-H4
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 18:59:55 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3FIxtWo011088
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 12:59:55 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW80093S7FU01@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 12:59:55 -0600 (MDT)
Received: from [192.168.1.100] ([129.150.16.63])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW800DTD7FTNP@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 12:59:54 -0600 (MDT)
Date: Thu, 15 Apr 2004 11:59:51 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00
 .txt
In-reply-to: <407ED183.5060204@iprg.nokia.com>
To: Fred Templin <ftemplin@iprg.nokia.com>
Cc: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "''Marc Blanchet ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <133E8A46-8F0F-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: Apple Mail
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se>
 <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com>
 <407ECCA4.1000308@iprg.nokia.com>
 <ACC5BFD8-8F06-11D8-BB4F-00039376A6AA@sun.com>
 <407ED183.5060204@iprg.nokia.com>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 15, 2004, at 11:16 AM, Fred Templin wrote:
> Only that, from the perspective of IPv6-in-IPv4 tunneling, it
> would be nice if any "NATs" behaved more like an ND Proxy.

Essentially, you are saying it would be better to use the IPv4 NAT box 
as
your v6 access router.
I agree.
Except that it may not always be possible.

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 16:04:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23355
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 16:04:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BED2w-000BDc-6s
	for v6ops-data@psg.com; Thu, 15 Apr 2004 20:01:14 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BED2m-000BAq-A8
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 20:01:04 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3FK13HS001197
	for <v6ops@ops.ietf.org>; Thu, 15 Apr 2004 14:01:03 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HW800I6OA9RTI@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 15 Apr 2004 14:01:03 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HW800MWJA9PUQ@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 15 Apr 2004 14:01:03 -0600 (MDT)
Date: Thu, 15 Apr 2004 13:01:01 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00
 .txt
In-reply-to: <407EDCB7.5040802@iprg.nokia.com>
To: Fred Templin <ftemplin@iprg.nokia.com>
Cc: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "''Marc Blanchet ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <9E7A409C-8F17-11D8-BB4F-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: Apple Mail
 <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se>
 <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com>
 <407ECCA4.1000308@iprg.nokia.com>
 <ACC5BFD8-8F06-11D8-BB4F-00039376A6AA@sun.com>
 <407ED183.5060204@iprg.nokia.com> <407EDCB7.5040802@iprg.nokia.com>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 15, 2004, at 12:04 PM, Fred Templin wrote:

>  All I'm saying is that explicit NAT traversal
> mechanisms should be used only as a last-resort, and unencumbered
> IPv6-in-IPv4 tunneling (or, better yet, native IPv6) should be used
> instead whenever possible.

Once again we are in agreement. This is absolutely compatible
with section 6.3:

6.3 NAT Considerations

    The assisted tunnel established by the protocol to be designed must
    work with the existing infrastructure, in particular it must be
    compatible with the various customer premise equipments available
    today.  This means that, in particular, the tunnels must be able to
    traverse one or many NAT boxes of different kinds. There is no
    requirement for any particular NAT traversal technology. However, as
    NAT traversal usually requires an extra layer of encapsulation, the
    tunnel set-up protocol must be able to detect automatically the
    presence of one or more NAT boxes in the path.

I will add text that spells out that when no NAT is present,
simple IPv6/IPv4 encapsulation MUST be used. It seemed obvious to
me, but apparently it will be better to clarify.

	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 15 16:29:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25026
	for <v6ops-archive@lists.ietf.org>; Thu, 15 Apr 2004 16:29:35 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEDSr-000Ixq-7p
	for v6ops-data@psg.com; Thu, 15 Apr 2004 20:28:01 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEDSp-000IxI-N1
	for v6ops@ops.ietf.org; Thu, 15 Apr 2004 20:27:59 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3FJ4EP00623;
	Thu, 15 Apr 2004 12:04:14 -0700
X-mProtect: <200404151904> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdsgz2wg; Thu, 15 Apr 2004 12:04:10 PDT
Message-ID: <407EDCB7.5040802@iprg.nokia.com>
Date: Thu, 15 Apr 2004 12:04:23 -0700
From: Fred 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: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>,
        "''Marc Blanchet
 ' '" <Marc.Blanchet@hexago.com>,
        "'''IPv6 Operations ' ' '"
 <v6ops@ops.ietf.org>
Subject: Re: comments on draft-durand-v6ops-assisted-tunneling-requirement
 s-00 .txt
References: Apple Mail <37FB7AA6F5F9814FB634A7BF4C35A6F5639B8D@ESEALNT442.al.sw.ericsson.se> <71F24240-8F04-11D8-BB4F-00039376A6AA@sun.com> <407ECCA4.1000308@iprg.nokia.com> <ACC5BFD8-8F06-11D8-BB4F-00039376A6AA@sun.com> <407ED183.5060204@iprg.nokia.com> 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Alain Durand wrote:

>
> On Apr 15, 2004, at 11:16 AM, Fred Templin wrote:
>
>> This would not be the same thing as an "IPv6 NAT", which
>> I hope we will never see.
>
>
> Note that I'm not advocating for IPv6 NAT here.


I wasn't intending to imply that, but I'm glad to hear you say it.

> I'm saying that
> IPv4 NAT is almost everywhere and during the transition to
> IPv6, in the phase where the ISPs do not yet support full
> native IPv6 in the access network, we must take into account
> that IPv4 NAT may be in the way.


Speaking generally w/o looking at specific scenarios (e.g., 3GPP/2),
I would have to agree. All I'm saying is that explicit NAT traversal
mechanisms should be used only as a last-resort, and unencumbered
IPv6-in-IPv4 tunneling (or, better yet, native IPv6) should be used
instead whenever possible.

Fred
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Fri Apr 16 00:33:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26351
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 00:33:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEKxL-000ODd-Hv
	for v6ops-data@psg.com; Fri, 16 Apr 2004 04:27:59 +0000
Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEKxK-000OD6-7s
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 04:27:58 +0000
Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 00:27:52 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Content-Class: urn:content-classes:message
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00 .txt
Date: Fri, 16 Apr 2004 00:27:51 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <F4410B91C6CC314F9582B1A8E91DC9281BE8FB@ftmail2000>
Content-Transfer-Encoding: quoted-printable
Thread-Topic: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00 .txt
Thread-Index: AcQjEnyDDHmUcy6qToOPFVuYRQ8EUgAVznlw
From: "Soliman Hesham" <H.Soliman@flarion.com>
To: "Alain Durand" <Alain.Durand@Sun.COM>,
        "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
CC: "'Marc Blanchet ' " <Marc.Blanchet@hexago.com>,
        "''IPv6 Operations ' ' " <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 16 Apr 2004 04:27:52.0039 (UTC) FILETIME=[2E6A0770:01C4236B]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable



 > > You wouldn't need or want a NAT for that.
 >=20
 > Yes I want it for my IPv4 connections.

=3D> No you don't. There is another alternative:
use multiple PDP contexts. It's not a nice thing
but it's sure better and more realistic (in terms=20
of what mobile vendors are likely to support)
than a NAT. Note that there will likely be a NAT
in the core net anyway, so the NAT in the UE is useless.

Hesham

 >=20
 > > We are recommending that there should be IPv6 support (native
 > > if possible otherwise tunnelled) by the 3GPP/2 operator. That's
 > > the essence of the 3GPP analysis draft. So you can make your
 > > terminal/laptop into an IPv6 mobile router (tunnelling or native
 > > to the 3gpp/2 operator) and not get into the NAT headache. Since
 > > there is a better solution than NAT I think we should use it.
 >=20
 > Of course, but I though we were talking about the case where the 3GPP
 > ISP was not (yet) offering IPv6 service.
 >=20
 > 	- Alain.
 >=20
 >=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is=20
strictly prohibited.  If you are not the intended recipient please =
contact
the sender and delete all copies.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D




From owner-v6ops@ops.ietf.org  Fri Apr 16 02:41:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15973
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 02:41:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEMzo-0001Cj-Qy
	for v6ops-data@psg.com; Fri, 16 Apr 2004 06:38:40 +0000
Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEMzn-0001CD-2k
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 06:38:39 +0000
Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1BEMzm-0006dx-00; Fri, 16 Apr 2004 07:38:38 +0100
Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com)
	by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12)
	id 1BEMzm-0006ds-00; Fri, 16 Apr 2004 07:38:38 +0100
Received: from zurich.ibm.com (sig-9-145-171-93.de.ibm.com [9.145.171.93])
	by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i3G6cbF134392;
	Fri, 16 Apr 2004 07:38:38 +0100
Message-ID: <407EC384.A8809418@zurich.ibm.com>
Date: Thu, 15 Apr 2004 19:16:52 +0200
From: Brian E Carpenter <brc@zurich.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 Templin <ftemplin@iprg.nokia.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs 
 alternatives in 3GPP [Re: comments on draft-ietf-v6  
 ops-3gpp-analysis-09  .txt] ]
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com> <406C223B.6AB75BC5@zurich.ibm.com> <406CAD48.1070301@iprg.nokia.com> <40726D87.AE521541@zurich.ibm.com> <407C4EC9.2000507@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,
	DATE_IN_PAST_12_24 autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fred,

>   As the main point of this note, if we further equate the term
>   "site" with the term "domainname", we have a way of tying
>   addresses to domainnames that matches the natural order of
>   things in such a way that we have a ready-made, natural
>   routing engine in the form of the global DNS.

Well, Gurusprasad among others have proposed ideas along these
lines in the past. However, that isn't how the Internet works today;
the naming structure and the addressing structure and the routing
structure are not congruent. IPv6 has some degree of congruence
between the addressing and routing structures, but any congruence
with the naming structure is (mathematically) coincidental.

   Brian

Fred Templin wrote:
> 
> Hello Brian,
> 
> Brian E Carpenter wrote:
> 
> >Fred,
> >
> >Thanks. I've PDF'ed the picture in case anyone here is PPT-challenged.
> >
> 
> PDF is fine for me; thanks. If it's OK with you, I'd rather not
> try to tackle all of the points from your message below in one
> fell swoop, but rather see if we can establish things through
> an iterative dialogue.
> 
> The first aspect I would like to call to attention is the "Admin.
> Domain B" portion of the PDF figure. Note that we see what
> appear to be nested sub-domains within a parent domain. This
> might present something of a challenge to the traditional notion
> of what constitutes a "site", in that  sites need not be viewed as
> disjoint. Rather, sites can be seen as recursively nested one within
> another. Moreover, it seems to me that such recursive nesting of
> sites can extend outwards or inwards from a given point as far
> as one would like (within practical limitations, that is).
> 
> In comparison to the natural order of things, such a view
> makes perfect sense:
> 
>   - our universe is a "site" for which all known entities are
>     a member (it's probably best to leave the discussion of
>     parallel universes aside for now...).
>  - the universe comprises a number of  galaxies; each of which
>    is an autonomous "site" unto itself, yet a sibling of others.
>  - each galaxy comprises a number of stars/solar systems that
>    are, again, autonomous "sites" yet siblings to others.
>  - each star/solar system (presumably) comprises a number
>    of planets/planetiods that are, again...
> 
> and so on, until the desired degree of granularity is reached.
> 
> Now, if we could rig a ubiquitous naming system to match up
> with this natural order, we could assign a ".universe" TLD to
> the center of mass of the universe and recursively assign
> sub-domains going outward. For example (neglecting for
> now finer granularities) I could be reached via this naming
> system at:
> 
>  fredtemplin.california.usa.earth.sun.milkyway.universe
> 
> More relative to the subject topic of this thread, we can consider
> each node "xyz.foo.bar.com" in the Internet as a site unto itself,
> and consider its default router as the "center of mass" for its parent
> site "foo.bar.com". But then, this default router is yet again
> (the head of) a site unto itself with its *own* default router as
> the center of mass for *its* parent site "bar.com". If we allow
> each such default router to delegate the addressing scheme for its
> constituents, then we have a way of tying addresses with sites
> that matches the natural order of things.
> 
>   As the main point of this note, if we further equate the term
>   "site" with the term "domainname", we have a way of tying
>   addresses to domainnames that matches the natural order of
>   things in such a way that we have a ready-made, natural
>   routing engine in the form of the global DNS.
> 
> As I said, I'd like to take this discussion in iterative fashion,
> so I'll stop here for now and await comments. What I've said
> so far might appear as obvious and/or off-topic to a portion
> of this list readership, but I'm hoping that the relation to the
> 6to4/ISATAP/etc discussion will become more evident as
> we drill down into details from this 30k+ foot vantage point.
> 
> Thanks - Fred
> ftemplin@iprg.nokia.com
> 
> >Fred Templin wrote:
> >
> >
> >>Brian E Carpenter wrote:
> >>
> >>
> >>
> >>>Can somebody draw me a picture? [Emphasis on the word "useful."]
> >>>
> >>>
> >>>
> >>>
> >>Brian,
> >>
> >>Attached, please find a rough-cut and incomplete picture. It depicts
> >>two administrative domains (A and B), each with a node that is
> >>engaged in a peer-to-peer session (a.com and b.com). Domain A
> >>uses a native IPv6 prefix space and has delegated a portion of the
> >>space to a (b)router upstream from the node "a.com". Domain B
> >>uses a 6to4 prefix space and has delegated portions of the space
> >>to a hierarchically nested pair of (b)routers upstream from node
> >>"b.com".
> >>
> >>If the DNS entries for 'a.com' and 'b.com' are populated with AAAA
> >>resource records as shown in the picture, one could view the presence
> >>of the ISATAP-format link local addresses
> >>
> >>
> >
> >Well, I wouldn't expect those AAAA records to be visible outside the
> >originating sites. They would typically be suppressed by a 2-faced DNS
> >setup.
> >
> >I don't think the link local address you have for b.com is correct,
> >anyway. Inside site B, link locals are formed using Ethernet addresses
> >or whatever. The hosts inside a 6to4 site have no knowledge of 6to4.
> >
> >
> >
> >>as an unambiguous
> >>indication that the nodes "support the protocol",
> >>
> >>
> >
> >I regard it as highly unlikely that site B would contain logic to
> >identify fe80::0200:5efe:0506:0708 as a foreign ISATAP-like address.
> >Site B is running 6to4; why would it have any ISATAP-related code active?
> >
> >
> >
> >>and could use
> >>the ISATAP link-local address as the IPv6 next-hop toward
> >>the final destination.
> >>
> >>The picture shows a stream of packets emanating from a.com towards
> >>b.com (and, similarly, for packets emanating from b.com towards
> >>a.com). These outbound packets would be encapsulated using ISATAP
> >>and it would appear from IPv6's perspective that they are being
> >>"bridged" up to the edge of the remote peer's domain (although there
> >>would still need to be some flavor of NDproxy in operation). Once the
> >>inbound packets hit the edge of the remote peer's domain, the packets
> >>would be decapsulated and steered towards the final destination
> >>within the domain via the delegated IPv6 prefix information.
> >>
> >>The question comes when we consider the inbound packets
> >>arriving at the edge of administrative domain B. Does the edge
> >>node use 6to4 or ISATAP to decapsulate the packets. (And, does
> >>it even matter?)
> >>
> >>
> >
> >Well, as noted, I don't see any reason that site B would have an ISATAP
> >interface active. It won't know that 3ffe:1::1 is anything unusual.
> >Similarly, site A won't have any 6to4 code active. It won't know that
> >2002:0506:0708::1 is anything unusual. They will both send as if these are
> >native addresses, and receive in their normal way (native at site A and
> >6to4 decapsulation at site B).
> >
> >At least that's what I think.
> >
> >   Brian
> >

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM





From owner-v6ops@ops.ietf.org  Fri Apr 16 03:37:57 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19918
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 03:37:57 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BENtM-000GHj-7v
	for v6ops-data@psg.com; Fri, 16 Apr 2004 07:36:04 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BENtK-000GGU-17
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 07:36:02 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3G7a1Ah018054
	for <v6ops@ops.ietf.org>; Fri, 16 Apr 2004 09:36:01 +0200
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 16 Apr 2004 09:36:00 +0200
Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id 25KS904P; Fri, 16 Apr 2004 09:36:09 +0200
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY9WKFA>; Fri, 16 Apr 2004 09:35:53 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E3B5@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 6fae7a2d 2c4885b5 1455e070 00000138
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Fred Templin'" <ftemplin@iprg.nokia.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: RE: 6to4; ISATAP interfaces configured over same IPv4 address (wa
	s: Re: FYI Isatap implementations info)
Date: Fri, 16 Apr 2004 09:35:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 16 Apr 2004 07:36:00.0618 (UTC) FILETIME=[76EE7CA0:01C42385]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Fred,

> >  
> >
> >>If a 6to4 interface and ISATAP interface are configured 
> over the same
> >>IPv4 address, it would have to be a global IPv4 address 
> assigned to an
> >>interface connected to the global Internet due to 6to4 
> >>requirements. In
> >>that case, I believe the correct behavior should be for the 
> >>6to4 interface
> >>to take precedence for packets received with an on-link 
> 6to4 prefix in
> >>the IPv6 destination, and for the ISATAP interface to take 
> precedence
> >>for all others. Comments?
> >>    
> >>
> >
> >When I say takes precedence over I (still) mean the following:
> >First Priority:	If the prefix of the source address in 
> the inner 
> >     IPv6 header of the encapsulated packet matches a prefix of the 
> >     ISATAP interface, the packet is processed by this 
> tunnel interface.
> >
> 
> This would seem like the correct natural choice, since it 
> seems consistent
> with the notion of "intra-site". Again, I assume by this you 
> are intending
> to include link-locals? (Perhaps that's *all* you are 
> intending to include?)
> 

Prefixes local to the Intra-site of the Isatap interface
including link-locals are what I intend to include.

> >Second Priority: If the prefix of either the source or 
> destination address 
> >      in the inner IPv6 header is a 6to4 prefix, the packet 
> >      is processed by the 6to4 tunnel interface.
> >
> 

> Let's take a closer look at the cases; please tell me if I 
> mis-represent 
> anything:
> 
>   1) If both the source and destination are 6to4, then the packet is 
> originating
>      and terminating within the 6to4 domain. So, use of the 6to4 
> interface would
>      seem natural and appropriate. (Note that the destination 
> might not 
> belong to
>      *this* 6to4 router in which case L3 might forward 
> (redirect?) the 
> packet to
>      the correct 6to4 router - but, this is irrelevant for L2.5 
> decapsulation.)
> 

I agree, though in case the destination is 6to4 but doesn't belong to this router, 
the packet will and should be silently discarded by the 6to4 tunnel interface. 
[in compliance with e.g. section 5.2 of draft-ietf-v6ops-6to4-security-02.txt].


>   2) If the destination is 6to4, but the source is not 6to4, then the 
> packet is
>      originating from behind a 6to4 relay router and 
> terminating within the
>      6to4 domain. Again, the 6to4 interface seems the natural choice.
> 

I agree.

>   3) If the source is 6to4, but the destination is not 6to4, 
> then the packet
>      is originating from within the 6to4 domain and will eventually
>      terminate within the native IPv6 Internet. To do this, 
> it will have
>      to transition from the 6to4 domain to the native IPv6 
> Internet via
>      a relay router which may/may not occur on *this* 6to4 router.
> 
>      Is the 6to4 interface the correct interface to 
> decapsulate for this 
> case?
>      It seems somewhat less obvious to me, but still a better 
> choice than
>      the ISATAP interface when the source prefix is not on-link.

If the 6to4 interface isn't a 6to4 relay interface 
the 6to4 interface will and should discard the packet silently.

> 
> >**Here again it should be emphasized that these rules are 
> not intended to
> >apply to the Isatap router-to-router tunnelling situation.**
> >
> 
> I am fine with leaving this aspect out from the current discussion.
> 
> >I am not 100 % sure what you mean by an on-link 6to4 prefix.
> >
> 
> I think I may have been stuck with a mis-conception that 6to4 
> interfaces
> should only decapsulate packets with an IPv6 destination prefix of
> 2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the
> node's IPv4 interfaces.
> 
> >I can imagine that you refer to one of the following 2 situations:
> >(I)
> > _ _ _ _                         - - - - - - - - - - - - - - 
> >|       |     ___               |  Global Internet/exterior  
> |         
> >|  6to4 |-v6-/ R \              | _ _ _ _ _                  |
> >|  Site |    \___/-globalV4ADDR-|   Intra  |                 |
> >|_ _ _ _|                       |   -site  |                 | 
> >                                 - - - - - - - - - - - - - - 
> > 
> >(II)                     - - - - - - - - - - 
> >     ___               |  Global Internet/   |         
> >    / R \              | _ _ _ _ _   exterior|
> >    \___/-globalV4ADDR-|   Intra   |         |                   
> >                       |   -site   |         | 
> >                       |   of 6to4 |         |   
> >                       |  prefix   |         | 
> >                        - - - - - - - - - -
> >
> >In both situations a packet with the mentioned inner source address
> >should be from within the intra-site and should be processed 
> by the Isatap
> >interface and not the 6to4 interface turned towards the exterior.
> >
> >In (I), then in our 6to4 implementation, the packet with the 
> mentioned source address,
> >will be discarded by the 6to4 tunnel interfaces as we rely 
> on trusted relay routers.
> >It wil not be accepted as a packet from a 6to4 border router 
> since the v6 and the v4 sources
> >don't add up.
> > 
> >In (II)
> >The packet is a packet coming from and destined for the 
> Intra-site and should
> >be processed by the intra-site router interface (i.e. the Isatap
> >interface).  Again
> >the 6to4 interface would discard the packet,
> >further It should be redirected but thats another matter.
> >
> 
> I'm not prepared to comment on this in detail since I'm not 
> entirely sure
> what you are referring to by "the mentioned inner source address", and
> your examples might have been motivated by the misconception 
> I mentioned
> above. Perhaps this discussion is obviated by the examination 
> of the cases
> I provided earlier?
> 

I apologize. The above was an attempt to explain why the
Isatap source address check should precede the 6to4 destination check when allocating
the appropriate tunnel interface on the inbound path in case
where both 6to4 and isatap interfaces are anchored on the same ipv4 interface. 

But then I understand now that we may be in agreement on that.

By "mentioned inner source address", I mean an encapsulated packet where inner
 source address matches a prefix of the ISATAP interface.

BR, Karen




From owner-v6ops@ops.ietf.org  Fri Apr 16 10:02:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09863
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 10:02:18 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BETsE-000G7P-UN
	for v6ops-data@psg.com; Fri, 16 Apr 2004 13:59:18 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BETsB-000G6m-HW
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 13:59:15 +0000
Received: from consulintel02 ([10.0.0.135])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000014335.msg
	for <v6ops@ops.ietf.org>; Fri, 16 Apr 2004 16:05:40 +0200
Message-ID: <0ed101c423bb$e334a070$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Subject: new I-D
Date: Fri, 16 Apr 2004 16:05:34 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
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.1165
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Fri, 16 Apr 2004 16:05:40 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 10.0.0.135
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Fri, 16 Apr 2004 16:05:45 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi,

As part of the work that we are doing, as already indicated by Pekka a few weeks ago, we sent yesterday a 1st version of the "Evaluation of v6ops Auto-discovery for Tunneling Mechanisms".

For the impatiens, we have uploaded it at http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-00.txt.

Please, let's know your inputs so we can update it quickly, as we will like to submit at least a new version before next meeting.

Regards,
Jordi





**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Fri Apr 16 11:00:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14320
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 11:00:06 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEUms-0003BJ-QL
	for v6ops-data@psg.com; Fri, 16 Apr 2004 14:57:50 +0000
Received: from [131.228.20.26] (helo=mgw-x3.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEUmk-00032w-5B
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 14:57:42 +0000
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GEvVn05541;
	Fri, 16 Apr 2004 17:57:31 +0300 (EET DST)
X-Scanned: Fri, 16 Apr 2004 17:57:13 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3GEvDSG004956;
	Fri, 16 Apr 2004 17:57:13 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks001.ntc.nokia.com 00CuEG6c; Fri, 16 Apr 2004 17:57:12 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GEvBs01282;
	Fri, 16 Apr 2004 17:57:11 +0300 (EET DST)
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Apr 2004 17:57:10 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00 .txt
Date: Fri, 16 Apr 2004 17:57:09 +0300
Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE2E6@esebe005.ntc.nokia.com>
Thread-Topic: comments on draft-durand-v6ops-assisted-tunneling-requirement s-00 .txt
thread-index: AcQjEnyDDHmUcy6qToOPFVuYRQ8EUgAVznlwABYXrUA=
From: <juha.wiljakka@nokia.com>
To: <H.Soliman@flarion.com>, <Alain.Durand@Sun.COM>,
        <karim.el-malki@ericsson.com>
Cc: <Marc.Blanchet@hexago.com>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 16 Apr 2004 14:57:10.0134 (UTC) FILETIME=[17FE1960:01C423C3]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable


 Hi all!

This has been a good discussion. I also agree on the principle having no =
NAT in the UE.

Karim commented in an earlier e-mail:
"There are no NATs in mobile phones today since there is no use
for them and I sure hope never to see them. I think most people
would agree. So there is nothing today that hints at this
development and I think we should not be proposing solutions
that are compatible with this.

Mobile manufacturers will be shipping dual-stack mobile terminals
and that is what we should be (and are) favouring. If a PAN is
needed behind the terminal then it's an excellent case for using
IPv6."

Yes, *if* (Bluetooth) PAN is needed behind the terminal, just use IPv6 =
for that. That's a very simple guideline.

Cheers,
	 -Juha-

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext Soliman Hesham
Sent: 16 April, 2004 07:28

 > > You wouldn't need or want a NAT for that.
 >=20
 > Yes I want it for my IPv4 connections.

=3D> No you don't. There is another alternative:
use multiple PDP contexts. It's not a nice thing
but it's sure better and more realistic (in terms=20
of what mobile vendors are likely to support)
than a NAT. Note that there will likely be a NAT
in the core net anyway, so the NAT in the UE is useless.

Hesham



From owner-v6ops@ops.ietf.org  Fri Apr 16 11:09:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14785
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 11:09:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEUvs-0005SI-Ry
	for v6ops-data@psg.com; Fri, 16 Apr 2004 15:07:08 +0000
Received: from [131.228.20.27] (helo=mgw-x4.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEUvU-0005Li-Eq
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 15:06:44 +0000
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GF6fH18969;
	Fri, 16 Apr 2004 18:06:41 +0300 (EET DST)
X-Scanned: Fri, 16 Apr 2004 18:05:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3GF5uWc012745;
	Fri, 16 Apr 2004 18:05:56 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks003.ntc.nokia.com 00fj2KVb; Fri, 16 Apr 2004 18:05:50 EEST
Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GF5jF20928;
	Fri, 16 Apr 2004 18:05:45 +0300 (EET DST)
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Apr 2004 18:05:45 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: comments on draft-durand-v6ops-assisted-tunneling-requirement	s-00 .txt
Date: Fri, 16 Apr 2004 18:05:45 +0300
Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE2E7@esebe005.ntc.nokia.com>
Thread-Topic: comments on draft-durand-v6ops-assisted-tunneling-requirement	s-00 .txt
thread-index: AcQjEA4zYorEep6VSpygWEevIrXezgAsw0JQ
From: <juha.wiljakka@nokia.com>
To: <karim.el-malki@ericsson.com>, <Alain.Durand@Sun.COM>
Cc: <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 16 Apr 2004 15:05:45.0117 (UTC) FILETIME=[4AF244D0:01C423C4]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Karim,

It is good that you write "future" in your comment. Near future 3GPP UEs =
will still mainly be hosts, and not real mobile routers. But some level =
of "mobile router" functionality can be necessary (when thinking e.g. =
Bluetooth PAN).

Cheers,
	 -Juha-

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext Karim El-Malki (HF/EAB)

>IP support routing. 3GPP does not support routing in the handset.
>Does this makes IP not suitable for 3GPP?
>No. You simply do not use this feature.
>Same analogy applies here. We are not trying to design something
>that works only in the 3GPP case, but can works elsewhere as well.

Your analogy doesn't fit at all IMO. You are comparing implementing
an IPv6 mobile router with an IPv4 NAT in a mobile phone. IMO an
IPv6 mobile router in a terminal is a good thing for the future of
IPv6 in 3gpp nets while a NAT is absolutely not.

/Karim



From owner-v6ops@ops.ietf.org  Fri Apr 16 12:09:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18367
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 12:08:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEVqx-000IlQ-9h
	for v6ops-data@psg.com; Fri, 16 Apr 2004 16:06:07 +0000
Received: from [211.48.62.165] (helo=relay5.kornet.net)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEVqr-000Ik7-Fz
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 16:06:01 +0000
Received: from [221.147.173.177] (natpp00@kornet.net) by 
          relay5.kornet.net (Terrace MailWatcher) 
          with ESMTP id 2004041701:05:51:954092.13472.4644
          for <jordi.palet@consulintel.es>; 
          Sat, 17 Apr 2004 01:05:51 +0900 (KST) 
Message-ID: <011201c423cc$afefb7c0$b1ad93dd@shpark>
From: "S. Daniel Park" <natpp00@kornet.net>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
Cc: "???" <soohong.park@samsung.com>
References: <1082125271321299240.0.ppp12@ppp12>
Subject: Re: new I-D - DHCP solution
Date: Sat, 17 Apr 2004 01:05:49 +0900
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jordi, this draft is very interesting and here are some comments on this.

As you cited in this draft, I already proposed a DHCP solution
to provide IPv6-over-IPv4 tunnel service on the dual host.
In Scenarios, I think DHCP can satisfy their needs simply
for example: finding a nearest tunnel and load balancing, with
simple extensions (e.g., configured tunnel end-point option,
nearest TB address option and so on...). Regarding load balancing,
DHCP already had it on the server side.

Typically, we live near the DHCP servers not just one
location and if they provide available tunnel end-points (or TB)
in their local area, all host will make use of the best tunnel service.
Of course, all host must have this function.

After very very roughly reading it, I feel this draft has a bias
toward anycast solution. Is it your intentional approach or
anything else ?

I will let you know more comments after looking into it.

Regards.


- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, Samsung Electronics.


----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, April 16, 2004 11:05 PM
Subject: new I-D


Hi,

As part of the work that we are doing, as already indicated by Pekka a few
weeks ago, we sent yesterday a 1st version of the "Evaluation of v6ops
Auto-discovery for Tunneling Mechanisms".

For the impatiens, we have uploaded it at
http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-00.txt.

Please, let's know your inputs so we can update it quickly, as we will like
to submit at least a new version before next meeting.

Regards,
Jordi





**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.










From owner-v6ops@ops.ietf.org  Fri Apr 16 12:36:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19928
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 12:36:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEWIF-000ON4-4L
	for v6ops-data@psg.com; Fri, 16 Apr 2004 16:34:19 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEWIC-000OLO-4D
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 16:34:16 +0000
Received: from consulintel02 ([10.0.0.135])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000014790.msg
	for <v6ops@ops.ietf.org>; Fri, 16 Apr 2004 18:40:44 +0200
Message-ID: <021b01c423d1$8a613560$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <1082125271321299240.0.ppp12@ppp12> <011201c423cc$afefb7c0$b1ad93dd@shpark>
Subject: Re: new I-D - DHCP solution
Date: Fri, 16 Apr 2004 18:40:34 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
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.1165
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Fri, 16 Apr 2004 18:40:44 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 10.0.0.135
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Fri, 16 Apr 2004 18:40:47 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Daniel,

Thanks for your comments. I will work on your inputs about the DHCP in the next release.

I must recognize that we went more in-deep in the anycast one because we believe it could be the best, but we didn't want to discard others, and indeed will be very happy to have some contributors in the other possibilities to produce a non-biased document.

The other reason is also because anycast is already in use for 6to4, and the ideal solution will be one that is valid for 6to4, TB, TS, Teredo, may be ISATAP, and other mechanism. At this was we can have a single host supporting several transition mechanism, acting as the Tunnel End Point for all of them (I call this simply TS, Tunnel Server, to simplify), and probably making easier the transition because we will need to deploy less boxes with more functionalities and at the same time offering more solutions that facilitate somehow the interworking of clients using different mechanisms.

As you say, DHCP is a very good one, but requires updating the DHCP client to support the new option, and may be this is less practical, but I must say this is a quick thought and we need to go further to make a balanced decision. Also remember that not always we are using DHCP, and for example, the DHCP server at the ISP might provide it to the customers, but in the IPv4 world, most of the customer networks have their own NAT box, with their own DHCP server, that not necessarily is reading (and getting updated) the ISP DHCP server info (and if this is the case, this router should be also upgraded to support the new DHCP option).

I will be happy to heard new inputs from your side when you have some more time.

Regards,
Jordi

----- Original Message -----=20
From: "S. Daniel Park" <natpp00@kornet.net>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
Cc: "???" <soohong.park@samsung.com>
Sent: Friday, April 16, 2004 6:05 PM
Subject: Re: new I-D - DHCP solution


> Jordi, this draft is very interesting and here are some comments on this.
>=20
> As you cited in this draft, I already proposed a DHCP solution
> to provide IPv6-over-IPv4 tunnel service on the dual host.
> In Scenarios, I think DHCP can satisfy their needs simply
> for example: finding a nearest tunnel and load balancing, with
> simple extensions (e.g., configured tunnel end-point option,
> nearest TB address option and so on...). Regarding load balancing,
> DHCP already had it on the server side.
>=20
> Typically, we live near the DHCP servers not just one
> location and if they provide available tunnel end-points (or TB)
> in their local area, all host will make use of the best tunnel service.
> Of course, all host must have this function.
>=20
> After very very roughly reading it, I feel this draft has a bias
> toward anycast solution. Is it your intentional approach or
> anything else ?
>=20
> I will let you know more comments after looking into it.
>=20
> Regards.
>=20
>=20
> - Daniel (Soohong Daniel Park)
> - Mobile Platform Laboratory, Samsung Electronics.
>=20
>=20
> ----- Original Message -----=20
> From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
> To: <v6ops@ops.ietf.org>
> Sent: Friday, April 16, 2004 11:05 PM
> Subject: new I-D
>=20
>=20
> Hi,
>=20
> As part of the work that we are doing, as already indicated by Pekka a few
> weeks ago, we sent yesterday a 1st version of the "Evaluation of v6ops
> Auto-discovery for Tunneling Mechanisms".
>=20
> For the impatiens, we have uploaded it at
> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-00.txt.
>=20
> Please, let's know your inputs so we can update it quickly, as we will like
> to submit at least a new version before next meeting.
>=20
> Regards,
> Jordi
>=20
>=20
>=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Fri Apr 16 12:41:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20300
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 12:41:56 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEWOE-0000de-6O
	for v6ops-data@psg.com; Fri, 16 Apr 2004 16:40:30 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEWOB-0000d3-FP
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 16:40:27 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3GGeNr27479;
	Fri, 16 Apr 2004 09:40:23 -0700
X-mProtect: <200404161640> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdtlaZ6I; Fri, 16 Apr 2004 09:40:06 PDT
Message-ID: <40800C79.9050006@iprg.nokia.com>
Date: Fri, 16 Apr 2004 09:40:25 -0700
From: Fred 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: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: 6to4; ISATAP interfaces configured over same IPv4 address (was:
 Re: FYI Isatap implementations info)
References: <C26BB8276599A44B85D52F9CE41035E10229E3B5@esealnt944.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Karen,

It looks like we have reached conclusions on this topic. Conclusions
are that, if a 6to4 interface and isatap interface are configured over
the same IPv4 address, a received packet's inner IPv6 source address
is first checked to see if it has an on-link prefix on the isatap interface.
Next, if the packet does not belong to the isatap interface, it is checked
to see if it belongs to the 6to4 interface.

Can we consider this case now closed?

Fred
ftemplin@iprg.nokia.com

Karen E. Nielsen (AH/TED) wrote:

>Hi Fred,
>
>  
>
>>> 
>>>
>>>      
>>>
>>>>If a 6to4 interface and ISATAP interface are configured 
>>>>        
>>>>
>>over the same
>>    
>>
>>>>IPv4 address, it would have to be a global IPv4 address 
>>>>        
>>>>
>>assigned to an
>>    
>>
>>>>interface connected to the global Internet due to 6to4 
>>>>requirements. In
>>>>that case, I believe the correct behavior should be for the 
>>>>6to4 interface
>>>>to take precedence for packets received with an on-link 
>>>>        
>>>>
>>6to4 prefix in
>>    
>>
>>>>the IPv6 destination, and for the ISATAP interface to take 
>>>>        
>>>>
>>precedence
>>    
>>
>>>>for all others. Comments?
>>>>   
>>>>
>>>>        
>>>>
>>>When I say takes precedence over I (still) mean the following:
>>>First Priority:	If the prefix of the source address in 
>>>      
>>>
>>the inner 
>>    
>>
>>>    IPv6 header of the encapsulated packet matches a prefix of the 
>>>    ISATAP interface, the packet is processed by this 
>>>      
>>>
>>tunnel interface.
>>    
>>
>>This would seem like the correct natural choice, since it 
>>seems consistent
>>with the notion of "intra-site". Again, I assume by this you 
>>are intending
>>to include link-locals? (Perhaps that's *all* you are 
>>intending to include?)
>>
>>    
>>
>
>Prefixes local to the Intra-site of the Isatap interface
>including link-locals are what I intend to include.
>
>  
>
>>>Second Priority: If the prefix of either the source or 
>>>      
>>>
>>destination address 
>>    
>>
>>>     in the inner IPv6 header is a 6to4 prefix, the packet 
>>>     is processed by the 6to4 tunnel interface.
>>>
>>>      
>>>
>
>  
>
>>Let's take a closer look at the cases; please tell me if I 
>>mis-represent 
>>anything:
>>
>>  1) If both the source and destination are 6to4, then the packet is 
>>originating
>>     and terminating within the 6to4 domain. So, use of the 6to4 
>>interface would
>>     seem natural and appropriate. (Note that the destination 
>>might not 
>>belong to
>>     *this* 6to4 router in which case L3 might forward 
>>(redirect?) the 
>>packet to
>>     the correct 6to4 router - but, this is irrelevant for L2.5 
>>decapsulation.)
>>
>>    
>>
>
>I agree, though in case the destination is 6to4 but doesn't belong to this router, 
>the packet will and should be silently discarded by the 6to4 tunnel interface. 
>[in compliance with e.g. section 5.2 of draft-ietf-v6ops-6to4-security-02.txt].
>
>
>  
>
>>  2) If the destination is 6to4, but the source is not 6to4, then the 
>>packet is
>>     originating from behind a 6to4 relay router and 
>>terminating within the
>>     6to4 domain. Again, the 6to4 interface seems the natural choice.
>>
>>    
>>
>
>I agree.
>
>  
>
>>  3) If the source is 6to4, but the destination is not 6to4, 
>>then the packet
>>     is originating from within the 6to4 domain and will eventually
>>     terminate within the native IPv6 Internet. To do this, 
>>it will have
>>     to transition from the 6to4 domain to the native IPv6 
>>Internet via
>>     a relay router which may/may not occur on *this* 6to4 router.
>>
>>     Is the 6to4 interface the correct interface to 
>>decapsulate for this 
>>case?
>>     It seems somewhat less obvious to me, but still a better 
>>choice than
>>     the ISATAP interface when the source prefix is not on-link.
>>    
>>
>
>If the 6to4 interface isn't a 6to4 relay interface 
>the 6to4 interface will and should discard the packet silently.
>
>  
>
>>>**Here again it should be emphasized that these rules are 
>>>      
>>>
>>not intended to
>>    
>>
>>>apply to the Isatap router-to-router tunnelling situation.**
>>>
>>>      
>>>
>>I am fine with leaving this aspect out from the current discussion.
>>
>>    
>>
>>>I am not 100 % sure what you mean by an on-link 6to4 prefix.
>>>
>>>      
>>>
>>I think I may have been stuck with a mis-conception that 6to4 
>>interfaces
>>should only decapsulate packets with an IPv6 destination prefix of
>>2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the
>>node's IPv4 interfaces.
>>
>>    
>>
>>>I can imagine that you refer to one of the following 2 situations:
>>>(I)
>>>_ _ _ _                         - - - - - - - - - - - - - - 
>>>|       |     ___               |  Global Internet/exterior  
>>>      
>>>
>>|         
>>    
>>
>>>|  6to4 |-v6-/ R \              | _ _ _ _ _                  |
>>>|  Site |    \___/-globalV4ADDR-|   Intra  |                 |
>>>|_ _ _ _|                       |   -site  |                 | 
>>>                                - - - - - - - - - - - - - - 
>>>
>>>(II)                     - - - - - - - - - - 
>>>    ___               |  Global Internet/   |         
>>>   / R \              | _ _ _ _ _   exterior|
>>>   \___/-globalV4ADDR-|   Intra   |         |                   
>>>                      |   -site   |         | 
>>>                      |   of 6to4 |         |   
>>>                      |  prefix   |         | 
>>>                       - - - - - - - - - -
>>>
>>>In both situations a packet with the mentioned inner source address
>>>should be from within the intra-site and should be processed 
>>>      
>>>
>>by the Isatap
>>    
>>
>>>interface and not the 6to4 interface turned towards the exterior.
>>>
>>>In (I), then in our 6to4 implementation, the packet with the 
>>>      
>>>
>>mentioned source address,
>>    
>>
>>>will be discarded by the 6to4 tunnel interfaces as we rely 
>>>      
>>>
>>on trusted relay routers.
>>    
>>
>>>It wil not be accepted as a packet from a 6to4 border router 
>>>      
>>>
>>since the v6 and the v4 sources
>>    
>>
>>>don't add up.
>>>
>>>In (II)
>>>The packet is a packet coming from and destined for the 
>>>      
>>>
>>Intra-site and should
>>    
>>
>>>be processed by the intra-site router interface (i.e. the Isatap
>>>interface).  Again
>>>the 6to4 interface would discard the packet,
>>>further It should be redirected but thats another matter.
>>>
>>>      
>>>
>>I'm not prepared to comment on this in detail since I'm not 
>>entirely sure
>>what you are referring to by "the mentioned inner source address", and
>>your examples might have been motivated by the misconception 
>>I mentioned
>>above. Perhaps this discussion is obviated by the examination 
>>of the cases
>>I provided earlier?
>>
>>    
>>
>
>I apologize. The above was an attempt to explain why the
>Isatap source address check should precede the 6to4 destination check when allocating
>the appropriate tunnel interface on the inbound path in case
>where both 6to4 and isatap interfaces are anchored on the same ipv4 interface. 
>
>But then I understand now that we may be in agreement on that.
>
>By "mentioned inner source address", I mean an encapsulated packet where inner
> source address matches a prefix of the ISATAP interface.
>
>BR, Karen
>
>
>  
>





From owner-v6ops@ops.ietf.org  Fri Apr 16 12:52:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21294
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 12:52:22 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEWYD-00035c-6t
	for v6ops-data@psg.com; Fri, 16 Apr 2004 16:50:49 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEWY3-00030n-W3
	for v6ops@ops.ietf.org; Fri, 16 Apr 2004 16:50:40 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3GGoTZ24684;
	Fri, 16 Apr 2004 09:50:29 -0700
X-mProtect: <200404161650> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdlE69IO; Fri, 16 Apr 2004 09:50:26 PDT
Message-ID: <40800EE5.10906@iprg.nokia.com>
Date: Fri, 16 Apr 2004 09:50:45 -0700
From: Fred 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 <brc@zurich.ibm.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs 
 alternatives in 3GPP [Re: comments on draft-ietf-v6   ops-3gpp-analysis-09
  .txt] ]
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com> <406C223B.6AB75BC5@zurich.ibm.com> <406CAD48.1070301@iprg.nokia.com> <40726D87.AE521541@zurich.ibm.com> <407C4EC9.2000507@iprg.nokia.com> <407EC384.A8809418@zurich.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Brian,

The subject that got this thread started (when to use ISATAP vs.
6to4 when both are configured over the same IPv4 address) seems
to have reached conclusions under a related thread on the list. I'm
tempted to ask what you mean by "(mathematically) coincidental"
below, but  perhaps it's better to let the 30k+ foot viewpoint
discussion rest for now.

Thanks - Fred
ftemplin@iprg.nokia.com

Brian E Carpenter wrote:

>Fred,
>
>  
>
>>  As the main point of this note, if we further equate the term
>>  "site" with the term "domainname", we have a way of tying
>>  addresses to domainnames that matches the natural order of
>>  things in such a way that we have a ready-made, natural
>>  routing engine in the form of the global DNS.
>>    
>>
>
>Well, Gurusprasad among others have proposed ideas along these
>lines in the past. However, that isn't how the Internet works today;
>the naming structure and the addressing structure and the routing
>structure are not congruent. IPv6 has some degree of congruence
>between the addressing and routing structures, but any congruence
>with the naming structure is (mathematically) coincidental.
>
>   Brian
>
>Fred Templin wrote:
>  
>
>>Hello Brian,
>>
>>Brian E Carpenter wrote:
>>
>>    
>>
>>>Fred,
>>>
>>>Thanks. I've PDF'ed the picture in case anyone here is PPT-challenged.
>>>
>>>      
>>>
>>PDF is fine for me; thanks. If it's OK with you, I'd rather not
>>try to tackle all of the points from your message below in one
>>fell swoop, but rather see if we can establish things through
>>an iterative dialogue.
>>
>>The first aspect I would like to call to attention is the "Admin.
>>Domain B" portion of the PDF figure. Note that we see what
>>appear to be nested sub-domains within a parent domain. This
>>might present something of a challenge to the traditional notion
>>of what constitutes a "site", in that  sites need not be viewed as
>>disjoint. Rather, sites can be seen as recursively nested one within
>>another. Moreover, it seems to me that such recursive nesting of
>>sites can extend outwards or inwards from a given point as far
>>as one would like (within practical limitations, that is).
>>
>>In comparison to the natural order of things, such a view
>>makes perfect sense:
>>
>>  - our universe is a "site" for which all known entities are
>>    a member (it's probably best to leave the discussion of
>>    parallel universes aside for now...).
>> - the universe comprises a number of  galaxies; each of which
>>   is an autonomous "site" unto itself, yet a sibling of others.
>> - each galaxy comprises a number of stars/solar systems that
>>   are, again, autonomous "sites" yet siblings to others.
>> - each star/solar system (presumably) comprises a number
>>   of planets/planetiods that are, again...
>>
>>and so on, until the desired degree of granularity is reached.
>>
>>Now, if we could rig a ubiquitous naming system to match up
>>with this natural order, we could assign a ".universe" TLD to
>>the center of mass of the universe and recursively assign
>>sub-domains going outward. For example (neglecting for
>>now finer granularities) I could be reached via this naming
>>system at:
>>
>> fredtemplin.california.usa.earth.sun.milkyway.universe
>>
>>More relative to the subject topic of this thread, we can consider
>>each node "xyz.foo.bar.com" in the Internet as a site unto itself,
>>and consider its default router as the "center of mass" for its parent
>>site "foo.bar.com". But then, this default router is yet again
>>(the head of) a site unto itself with its *own* default router as
>>the center of mass for *its* parent site "bar.com". If we allow
>>each such default router to delegate the addressing scheme for its
>>constituents, then we have a way of tying addresses with sites
>>that matches the natural order of things.
>>
>>  As the main point of this note, if we further equate the term
>>  "site" with the term "domainname", we have a way of tying
>>  addresses to domainnames that matches the natural order of
>>  things in such a way that we have a ready-made, natural
>>  routing engine in the form of the global DNS.
>>
>>As I said, I'd like to take this discussion in iterative fashion,
>>so I'll stop here for now and await comments. What I've said
>>so far might appear as obvious and/or off-topic to a portion
>>of this list readership, but I'm hoping that the relation to the
>>6to4/ISATAP/etc discussion will become more evident as
>>we drill down into details from this 30k+ foot vantage point.
>>
>>Thanks - Fred
>>ftemplin@iprg.nokia.com
>>
>>    
>>
>>>Fred Templin wrote:
>>>
>>>
>>>      
>>>
>>>>Brian E Carpenter wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Can somebody draw me a picture? [Emphasis on the word "useful."]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>Brian,
>>>>
>>>>Attached, please find a rough-cut and incomplete picture. It depicts
>>>>two administrative domains (A and B), each with a node that is
>>>>engaged in a peer-to-peer session (a.com and b.com). Domain A
>>>>uses a native IPv6 prefix space and has delegated a portion of the
>>>>space to a (b)router upstream from the node "a.com". Domain B
>>>>uses a 6to4 prefix space and has delegated portions of the space
>>>>to a hierarchically nested pair of (b)routers upstream from node
>>>>"b.com".
>>>>
>>>>If the DNS entries for 'a.com' and 'b.com' are populated with AAAA
>>>>resource records as shown in the picture, one could view the presence
>>>>of the ISATAP-format link local addresses
>>>>
>>>>
>>>>        
>>>>
>>>Well, I wouldn't expect those AAAA records to be visible outside the
>>>originating sites. They would typically be suppressed by a 2-faced DNS
>>>setup.
>>>
>>>I don't think the link local address you have for b.com is correct,
>>>anyway. Inside site B, link locals are formed using Ethernet addresses
>>>or whatever. The hosts inside a 6to4 site have no knowledge of 6to4.
>>>
>>>
>>>
>>>      
>>>
>>>>as an unambiguous
>>>>indication that the nodes "support the protocol",
>>>>
>>>>
>>>>        
>>>>
>>>I regard it as highly unlikely that site B would contain logic to
>>>identify fe80::0200:5efe:0506:0708 as a foreign ISATAP-like address.
>>>Site B is running 6to4; why would it have any ISATAP-related code active?
>>>
>>>
>>>
>>>      
>>>
>>>>and could use
>>>>the ISATAP link-local address as the IPv6 next-hop toward
>>>>the final destination.
>>>>
>>>>The picture shows a stream of packets emanating from a.com towards
>>>>b.com (and, similarly, for packets emanating from b.com towards
>>>>a.com). These outbound packets would be encapsulated using ISATAP
>>>>and it would appear from IPv6's perspective that they are being
>>>>"bridged" up to the edge of the remote peer's domain (although there
>>>>would still need to be some flavor of NDproxy in operation). Once the
>>>>inbound packets hit the edge of the remote peer's domain, the packets
>>>>would be decapsulated and steered towards the final destination
>>>>within the domain via the delegated IPv6 prefix information.
>>>>
>>>>The question comes when we consider the inbound packets
>>>>arriving at the edge of administrative domain B. Does the edge
>>>>node use 6to4 or ISATAP to decapsulate the packets. (And, does
>>>>it even matter?)
>>>>
>>>>
>>>>        
>>>>
>>>Well, as noted, I don't see any reason that site B would have an ISATAP
>>>interface active. It won't know that 3ffe:1::1 is anything unusual.
>>>Similarly, site A won't have any 6to4 code active. It won't know that
>>>2002:0506:0708::1 is anything unusual. They will both send as if these are
>>>native addresses, and receive in their normal way (native at site A and
>>>6to4 decapsulation at site B).
>>>
>>>At least that's what I think.
>>>
>>>  Brian
>>>
>>>      
>>>
>
>  
>





From owner-v6ops@ops.ietf.org  Fri Apr 16 20:27:34 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22581
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 20:27:33 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEdab-0003Ct-SL
	for v6ops-data@psg.com; Sat, 17 Apr 2004 00:21:45 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEdab-0003Cb-4F
	for v6ops@ops.ietf.org; Sat, 17 Apr 2004 00:21:45 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3H0Lia00537;
	Fri, 16 Apr 2004 17:21:44 -0700
X-mProtect: <200404170021> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd7IBgcI; Fri, 16 Apr 2004 17:21:39 PDT
Message-ID: <408078A7.4000303@iprg.nokia.com>
Date: Fri, 16 Apr 2004 17:21:59 -0700
From: Fred 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: IPv6 Operations <v6ops@ops.ietf.org>
CC: ftemplin@iprg.nokia.com
Subject: ISATAP Extensions for Mobility, Multihoming and Efficiency Improvement
 (IEMMEI)
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com> <406C223B.6AB75BC5@zurich.ibm.com> <406CAD48.1070301@iprg.nokia.com> <40726D87.AE521541@zurich.ibm.com> <407C4EC9.2000507@iprg.nokia.com> <407EC384.A8809418@zurich.ibm.com> <40800EE5.10906@ip
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

A new draft of the above name has been submitted to the
I-D registrar and is also available for early review to:

      www.geocities.com/osprey67/isatap/iemmei-00.txt
    
The purpose of this submission is to provide informational
and/or Best Current Practices input to the community. The
author requests that this document be adopted as a v6ops
wg document. The abstract appears below: 

Fred L. Templin
ftemplin@iprg.nokia.com

--- cut here ---

Abstract

   The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
   IPv6 hosts/routers over IPv4 networks via automatic tunneling using a
   link abstraction similar to the Non-Broadcast, Multiple Access (NBMA)
   model. This document describes operational extensions for ISATAP that
   enable a dynamic tunnel interface management abstraction similar to
   the ATM Permanent/Switched Virtual Circuit model. Nodes can use these
   extensions to realize mobility, multihoming and efficiency
   improvements not available via the ISATAP base specification alone






From owner-v6ops@ops.ietf.org  Fri Apr 16 20:27:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22599
	for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2004 20:27:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BEdaK-00039o-1p
	for v6ops-data@psg.com; Sat, 17 Apr 2004 00:21:28 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BEdaJ-00039b-2Y
	for v6ops@ops.ietf.org; Sat, 17 Apr 2004 00:21:27 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3H0LQL31296;
	Fri, 16 Apr 2004 17:21:26 -0700
X-mProtect: <200404170021> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd9gyhJJ; Fri, 16 Apr 2004 17:21:23 PDT
Message-ID: <40807897.6050603@iprg.nokia.com>
Date: Fri, 16 Apr 2004 17:21:43 -0700
From: Fred 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: IPv6 Operations <v6ops@ops.ietf.org>
CC: dthaler@microsoft.com, mohitt@microsoft.com, tgleeson@cisco.com,
        ftemplin@iprg.nokia.com
Subject: draft-ietf-ngtrans-isatap-21.txt
References: <20040331144759.5257.qmail@web80510.mail.yahoo.com> <406C223B.6AB75BC5@zurich.ibm.com> <406CAD48.1070301@iprg.nokia.com> <40726D87.AE521541@zurich.ibm.com> <407C4EC9.2000507@iprg.nokia.com> <407EC384.A8809418@zurich.ibm.com> <40800EE5.10906@ip
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

A new version of the ISATAP specification (isatap-21) has
been submitted to the I-D registrar and is also available
for early review at:

      www.geocities.com/osprey67/isatap/isatap-21.txt
    
The purpose of the -21 version is to satisfy the clear requirement 
for documenting the widely-deployed implementations. We request that
the -21 version now be adopted as a v6ops wg document.

Fred L. Templin (for the ISATAP co-authors)
ftemplin@iprg.nokia.com





From owner-v6ops@ops.ietf.org  Sun Apr 18 04:35:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07484
	for <v6ops-archive@lists.ietf.org>; Sun, 18 Apr 2004 04:35:13 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BF7hQ-0000Z2-Bs
	for v6ops-data@psg.com; Sun, 18 Apr 2004 08:30:48 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BF7hO-0000YR-Kt
	for v6ops@ops.ietf.org; Sun, 18 Apr 2004 08:30:46 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3I8UgB12412;
	Sun, 18 Apr 2004 11:30:42 +0300
Date: Sun, 18 Apr 2004 11:30:42 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: new I-D - DHCP solution
In-Reply-To: <021b01c423d1$8a613560$8700000a@consulintel.es>
Message-ID: <Pine.LNX.4.44.0404181102370.11614-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 16 Apr 2004, JORDI PALET MARTINEZ wrote:
> [...] most of the customer
> networks have their own NAT box, with their own DHCP server, that
> not necessarily is reading (and getting updated) the ISP DHCP server
> info (and if this is the case, this router should be also upgraded
> to support the new DHCP option).

Was this stated clearly enough?  This is probably a very good point 
that needs to be stated clearly.

Either the DHCP server at the NAT box would have to propagate the 
option, or the NAT box would have to support IPv6 to create the tunnel 
on its own.

...

A bit of brainstorming of my own; compared to anycast, DHCP seems to
have a few tradeoffs:

pro-DHCP:
 + it would only be used when there _is_ guaranteed service, i.e., one 
would not have to send the packets to anycast address if there is no 
service (whether this is a concern depends on how anycast discovery 
would be done, see specific issues w/ anycast below).
 + DHCP for configuration parameters is a technique for v4 which we're 
familiar with already (for the good and bad).

pro-anycast:
 + works also when the provider's DHCP info is not propagated to the
ultimate user (e.g., due to NAT box)
 + does not require any implementation which couldn't be done in the 
tunnel server system itself, either at DHCP server or DHCP 
client software; i.e., no 3rd party dependencies, which is pretty 
important
 + can be reasonably constrained if combined with a DNS lookup, and 
anycasting the result. (compare to the discovery mechanism for 
ISATAP.)

specific issues in anycast which need to be addressed:
 * it may be undesirable to allocate an interdomain anycast prefix ala 
6to4 for this purpose due to a number of reasons, e.g.:
  - when there is no service to be offered at all, the search may take 
long to terminate, especially if you don't get back 
network-unreachable.
  - there is far less incentive for 3rd parties to provide service 
than with 6to4 relays, so the chances of finding a willing tunnel 
server with interdomain anycast is pretty slim.
  - when you move between domains, it might still be easiest if you 
were able to use your "home ISP's server".  The ISP could be blocking 
that, of course, but esp. if you're authenticated, it should still 
work.

 * if naycast is not an assigned interdomain anycast prefix, it needs
to be discovered somehow.  DNS lookup is a strong candidate, but there
are devils in the details.  This could be a simple "A" query for e.g.,
tunnel-server.<search-path>, NAPTR query (two roundtrips, extra
implementation), or whatever.  This would be easily configured
manually as well.  That would have to be figured out.

 * when the user moves from an ISP's network to another (e.g., due to 
mobility/roaming), there needs to be some process that notices this 
change.

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




From owner-v6ops@ops.ietf.org  Mon Apr 19 03:29:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22427
	for <v6ops-archive@lists.ietf.org>; Mon, 19 Apr 2004 03:29:26 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFT94-0006aX-1W
	for v6ops-data@psg.com; Mon, 19 Apr 2004 07:24:46 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BFT90-0006Zb-2R
	for v6ops@ops.ietf.org; Mon, 19 Apr 2004 07:24:42 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3J7OfPA000424
	for <v6ops@ops.ietf.org>; Mon, 19 Apr 2004 09:24:41 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 19 Apr 2004 09:24:40 +0200
Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id JDM09PHA; Mon, 19 Apr 2004 09:24:03 +0200
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY9W3RM>; Mon, 19 Apr 2004 09:23:55 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E3B7@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 797a59a1 2c4885b5 2f9c3433 00000138
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Fred Templin'" <ftemplin@iprg.nokia.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: RE: 6to4; ISATAP interfaces configured over same IPv4 address (wa
	s: Re: FYI Isatap implementations info)
Date: Mon, 19 Apr 2004 09:23:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 19 Apr 2004 07:24:40.0903 (UTC) FILETIME=[61077570:01C425DF]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Fred,

Yes, 
given that router-to-router tunnelling isn't an issue.
I agree wrt the router case.

Wrt the host case, 
I believe that the rules should be bound to the
destination address rather than the source address - that is:
if a 6to4 interface and an isatap interface are configured over
the same IPv4 address, a received packet's inner IPv6 destination address
is first checked to see if it matches an address of the Isatap interface 
(in which case it should be processed by that interface).
Next, if the packet does not belong to the isatap interface, 
it is checked to see if it belongs to the 6to4 interface.

BR, Karen


> -----Original Message-----
> From: Fred Templin [mailto:ftemplin@iprg.nokia.com]
> Sent: 16. april 2004 18:40
> To: Karen E. Nielsen (AH/TED)
> Cc: IPv6 Operations
> Subject: Re: 6to4; ISATAP interfaces configured over same IPv4 address
> (was: Re: FYI Isatap implementations info)
> 
> 
> Hi Karen,
> 
> It looks like we have reached conclusions on this topic. Conclusions
> are that, if a 6to4 interface and isatap interface are configured over
> the same IPv4 address, a received packet's inner IPv6 source address
> is first checked to see if it has an on-link prefix on the 
> isatap interface.
> Next, if the packet does not belong to the isatap interface, 
> it is checked
> to see if it belongs to the 6to4 interface.
> 
> Can we consider this case now closed?
> 
> Fred
> ftemplin@iprg.nokia.com
> 
> Karen E. Nielsen (AH/TED) wrote:
> 
> >Hi Fred,
> >
> >  
> >
> >>> 
> >>>
> >>>      
> >>>
> >>>>If a 6to4 interface and ISATAP interface are configured 
> >>>>        
> >>>>
> >>over the same
> >>    
> >>
> >>>>IPv4 address, it would have to be a global IPv4 address 
> >>>>        
> >>>>
> >>assigned to an
> >>    
> >>
> >>>>interface connected to the global Internet due to 6to4 
> >>>>requirements. In
> >>>>that case, I believe the correct behavior should be for the 
> >>>>6to4 interface
> >>>>to take precedence for packets received with an on-link 
> >>>>        
> >>>>
> >>6to4 prefix in
> >>    
> >>
> >>>>the IPv6 destination, and for the ISATAP interface to take 
> >>>>        
> >>>>
> >>precedence
> >>    
> >>
> >>>>for all others. Comments?
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>When I say takes precedence over I (still) mean the following:
> >>>First Priority:	If the prefix of the source address in 
> >>>      
> >>>
> >>the inner 
> >>    
> >>
> >>>    IPv6 header of the encapsulated packet matches a prefix of the 
> >>>    ISATAP interface, the packet is processed by this 
> >>>      
> >>>
> >>tunnel interface.
> >>    
> >>
> >>This would seem like the correct natural choice, since it 
> >>seems consistent
> >>with the notion of "intra-site". Again, I assume by this you 
> >>are intending
> >>to include link-locals? (Perhaps that's *all* you are 
> >>intending to include?)
> >>
> >>    
> >>
> >
> >Prefixes local to the Intra-site of the Isatap interface
> >including link-locals are what I intend to include.
> >
> >  
> >
> >>>Second Priority: If the prefix of either the source or 
> >>>      
> >>>
> >>destination address 
> >>    
> >>
> >>>     in the inner IPv6 header is a 6to4 prefix, the packet 
> >>>     is processed by the 6to4 tunnel interface.
> >>>
> >>>      
> >>>
> >
> >  
> >
> >>Let's take a closer look at the cases; please tell me if I 
> >>mis-represent 
> >>anything:
> >>
> >>  1) If both the source and destination are 6to4, then the 
> packet is 
> >>originating
> >>     and terminating within the 6to4 domain. So, use of the 6to4 
> >>interface would
> >>     seem natural and appropriate. (Note that the destination 
> >>might not 
> >>belong to
> >>     *this* 6to4 router in which case L3 might forward 
> >>(redirect?) the 
> >>packet to
> >>     the correct 6to4 router - but, this is irrelevant for L2.5 
> >>decapsulation.)
> >>
> >>    
> >>
> >
> >I agree, though in case the destination is 6to4 but doesn't 
> belong to this router, 
> >the packet will and should be silently discarded by the 6to4 
> tunnel interface. 
> >[in compliance with e.g. section 5.2 of 
> draft-ietf-v6ops-6to4-security-02.txt].
> >
> >
> >  
> >
> >>  2) If the destination is 6to4, but the source is not 
> 6to4, then the 
> >>packet is
> >>     originating from behind a 6to4 relay router and 
> >>terminating within the
> >>     6to4 domain. Again, the 6to4 interface seems the 
> natural choice.
> >>
> >>    
> >>
> >
> >I agree.
> >
> >  
> >
> >>  3) If the source is 6to4, but the destination is not 6to4, 
> >>then the packet
> >>     is originating from within the 6to4 domain and will eventually
> >>     terminate within the native IPv6 Internet. To do this, 
> >>it will have
> >>     to transition from the 6to4 domain to the native IPv6 
> >>Internet via
> >>     a relay router which may/may not occur on *this* 6to4 router.
> >>
> >>     Is the 6to4 interface the correct interface to 
> >>decapsulate for this 
> >>case?
> >>     It seems somewhat less obvious to me, but still a better 
> >>choice than
> >>     the ISATAP interface when the source prefix is not on-link.
> >>    
> >>
> >
> >If the 6to4 interface isn't a 6to4 relay interface 
> >the 6to4 interface will and should discard the packet silently.
> >
> >  
> >
> >>>**Here again it should be emphasized that these rules are 
> >>>      
> >>>
> >>not intended to
> >>    
> >>
> >>>apply to the Isatap router-to-router tunnelling situation.**
> >>>
> >>>      
> >>>
> >>I am fine with leaving this aspect out from the current discussion.
> >>
> >>    
> >>
> >>>I am not 100 % sure what you mean by an on-link 6to4 prefix.
> >>>
> >>>      
> >>>
> >>I think I may have been stuck with a mis-conception that 6to4 
> >>interfaces
> >>should only decapsulate packets with an IPv6 destination prefix of
> >>2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the
> >>node's IPv4 interfaces.
> >>
> >>    
> >>
> >>>I can imagine that you refer to one of the following 2 situations:
> >>>(I)
> >>>_ _ _ _                         - - - - - - - - - - - - - - 
> >>>|       |     ___               |  Global Internet/exterior  
> >>>      
> >>>
> >>|         
> >>    
> >>
> >>>|  6to4 |-v6-/ R \              | _ _ _ _ _                  |
> >>>|  Site |    \___/-globalV4ADDR-|   Intra  |                 |
> >>>|_ _ _ _|                       |   -site  |                 | 
> >>>                                - - - - - - - - - - - - - - 
> >>>
> >>>(II)                     - - - - - - - - - - 
> >>>    ___               |  Global Internet/   |         
> >>>   / R \              | _ _ _ _ _   exterior|
> >>>   \___/-globalV4ADDR-|   Intra   |         |                   
> >>>                      |   -site   |         | 
> >>>                      |   of 6to4 |         |   
> >>>                      |  prefix   |         | 
> >>>                       - - - - - - - - - -
> >>>
> >>>In both situations a packet with the mentioned inner source address
> >>>should be from within the intra-site and should be processed 
> >>>      
> >>>
> >>by the Isatap
> >>    
> >>
> >>>interface and not the 6to4 interface turned towards the exterior.
> >>>
> >>>In (I), then in our 6to4 implementation, the packet with the 
> >>>      
> >>>
> >>mentioned source address,
> >>    
> >>
> >>>will be discarded by the 6to4 tunnel interfaces as we rely 
> >>>      
> >>>
> >>on trusted relay routers.
> >>    
> >>
> >>>It wil not be accepted as a packet from a 6to4 border router 
> >>>      
> >>>
> >>since the v6 and the v4 sources
> >>    
> >>
> >>>don't add up.
> >>>
> >>>In (II)
> >>>The packet is a packet coming from and destined for the 
> >>>      
> >>>
> >>Intra-site and should
> >>    
> >>
> >>>be processed by the intra-site router interface (i.e. the Isatap
> >>>interface).  Again
> >>>the 6to4 interface would discard the packet,
> >>>further It should be redirected but thats another matter.
> >>>
> >>>      
> >>>
> >>I'm not prepared to comment on this in detail since I'm not 
> >>entirely sure
> >>what you are referring to by "the mentioned inner source 
> address", and
> >>your examples might have been motivated by the misconception 
> >>I mentioned
> >>above. Perhaps this discussion is obviated by the examination 
> >>of the cases
> >>I provided earlier?
> >>
> >>    
> >>
> >
> >I apologize. The above was an attempt to explain why the
> >Isatap source address check should precede the 6to4 
> destination check when allocating
> >the appropriate tunnel interface on the inbound path in case
> >where both 6to4 and isatap interfaces are anchored on the 
> same ipv4 interface. 
> >
> >But then I understand now that we may be in agreement on that.
> >
> >By "mentioned inner source address", I mean an encapsulated 
> packet where inner
> > source address matches a prefix of the ISATAP interface.
> >
> >BR, Karen
> >
> >
> >  
> >
> 
> 



From owner-v6ops@ops.ietf.org  Mon Apr 19 08:52:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08478
	for <v6ops-archive@lists.ietf.org>; Mon, 19 Apr 2004 08:52:00 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFYBr-0007Yq-HL
	for v6ops-data@psg.com; Mon, 19 Apr 2004 12:47:59 +0000
Received: from [66.218.79.72] (helo=web80502.mail.yahoo.com)
	by psg.com with smtp (Exim 4.30; FreeBSD)
	id 1BFYBq-0007YR-7y
	for v6ops@ops.ietf.org; Mon, 19 Apr 2004 12:47:58 +0000
Message-ID: <20040419124758.255.qmail@web80502.mail.yahoo.com>
Received: from [63.197.18.101] by web80502.mail.yahoo.com via HTTP; Mon, 19 Apr 2004 05:47:58 PDT
Date: Mon, 19 Apr 2004 05:47:58 -0700 (PDT)
From: Fred Templin <osprey67@yahoo.com>
Subject: RE: 6to4; ISATAP interfaces configured over same IPv4 address (wa s: Re: FYI Isatap implementations info)
To: "Karen E. Nielsen \(AH/TED\)" <karen.e.nielsen@ericsson.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E10229E3B7@esealnt944.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-37992272-1082378878=:146"
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,
	FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--0-37992272-1082378878=:146
Content-Type: text/plain; charset=us-ascii

Hi Karen,
 
Almost, except that I think it might be possible for more than one ISATAP
interface to be configured over the same IPv4 address (IPv4 address-to-
interface mapping, actually). For each such ISATAP interface for which
the  IPv6 source is on-link, the IPv6 destination address should be checked
until a match is found. If no matching ISATAP interface is found, the 6to4
interface(s) should be checked next. BTW, checking for a matching IPv6
destination address is part of what I mean when I say "belongs to" an
interface.
 
Fred Templin
osprey67@yahoo.com

"Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com> wrote:
Hi Fred,

Yes, 
given that router-to-router tunnelling isn't an issue.
I agree wrt the router case.

Wrt the host case, 
I believe that the rules should be bound to the
destination address rather than the source address - that is:
if a 6to4 interface and an isatap interface are configured over
the same IPv4 address, a received packet's inner IPv6 destination address
is first checked to see if it matches an address of the Isatap interface 
(in which case it should be processed by that interface).
Next, if the packet does not belong to the isatap interface, 
it is checked to see if it belongs to the 6to4 interface.

BR, Karen


> -----Original Message-----
> From: Fred Templin [mailto:ftemplin@iprg.nokia.com]
> Sent: 16. april 2004 18:40
> To: Karen E. Nielsen (AH/TED)
> Cc: IPv6 Operations
> Subject: Re: 6to4; ISATAP interfaces configured over same IPv4 address
> (was: Re: FYI Isatap implementations info)
> 
> 
> Hi Karen,
> 
> It looks like we have reached conclusions on this topic. Conclusions
> are that, if a 6to4 interface and isatap interface are configured over
> the same IPv4 address, a received packet's inner IPv6 source address
> is first checked to see if it has an on-link prefix on the 
> isatap interface.
> Next, if the packet does not belong to the isatap interface, 
> it is checked
> to see if it belongs to the 6to4 interface.
> 
> Can we consider this case now closed?
> 
> Fred
> ftemplin@iprg.nokia.com
> 
> Karen E. Nielsen (AH/TED) wrote:
> 
> >Hi Fred,
> >
> > 
> >
> >>> 
> >>>
> >>> 
> >>>
> >>>>If a 6to4 interface and ISATAP interface are configured 
> >>>> 
> >>>>
> >>over the same
> >> 
> >>
> >>>>IPv4 address, it would have to be a global IPv4 address 
> >>>> 
> >>>>
> >>assigned to an
> >> 
> >>
> >>>>interface connected to the global Internet due to 6to4 
> >>>>requirements. In
> >>>>that case, I believe the correct behavior should be for the 
> >>>>6to4 interface
> >>>>to take precedence for packets received with an on-link 
> >>>> 
> >>>>
> >>6to4 prefix in
> >> 
> >>
> >>>>the IPv6 destination, and for the ISATAP interface to take 
> >>>> 
> >>>>
> >>precedence
> >> 
> >>
> >>>>for all others. Comments?
> >>>> 
> >>>>
> >>>> 
> >>>>
> >>>When I say takes precedence over I (still) mean the following:
> >>>First Priority: If the prefix of the source address in 
> >>> 
> >>>
> >>the inner 
> >> 
> >>
> >>> IPv6 header of the encapsulated packet matches a prefix of the 
> >>> ISATAP interface, the packet is processed by this 
> >>> 
> >>>
> >>tunnel interface.
> >> 
> >>
> >>This would seem like the correct natural choice, since it 
> >>seems consistent
> >>with the notion of "intra-site". Again, I assume by this you 
> >>are intending
> >>to include link-locals? (Perhaps that's *all* you are 
> >>intending to include?)
> >>
> >> 
> >>
> >
> >Prefixes local to the Intra-site of the Isatap interface
> >including link-locals are what I intend to include.
> >
> > 
> >
> >>>Second Priority: If the prefix of either the source or 
> >>> 
> >>>
> >>destination address 
> >> 
> >>
> >>> in the inner IPv6 header is a 6to4 prefix, the packet 
> >>> is processed by the 6to4 tunnel interface.
> >>>
> >>> 
> >>>
> >
> > 
> >
> >>Let's take a closer look at the cases; please tell me if I 
> >>mis-represent 
> >>anything:
> >>
> >> 1) If both the source and destination are 6to4, then the 
> packet is 
> >>originating
> >> and terminating within the 6to4 domain. So, use of the 6to4 
> >>interface would
> >> seem natural and appropriate. (Note that the destination 
> >>might not 
> >>belong to
> >> *this* 6to4 router in which case L3 might forward 
> >>(redirect?) the 
> >>packet to
> >> the correct 6to4 router - but, this is irrelevant for L2.5 
> >>decapsulation.)
> >>
> >> 
> >>
> >
> >I agree, though in case the destination is 6to4 but doesn't 
> belong to this router, 
> >the packet will and should be silently discarded by the 6to4 
> tunnel interface. 
> >[in compliance with e.g. section 5.2 of 
> draft-ietf-v6ops-6to4-security-02.txt].
> >
> >
> > 
> >
> >> 2) If the destination is 6to4, but the source is not 
> 6to4, then the 
> >>packet is
> >> originating from behind a 6to4 relay router and 
> >>terminating within the
> >> 6to4 domain. Again, the 6to4 interface seems the 
> natural choice.
> >>
> >> 
> >>
> >
> >I agree.
> >
> > 
> >
> >> 3) If the source is 6to4, but the destination is not 6to4, 
> >>then the packet
> >> is originating from within the 6to4 domain and will eventually
> >> terminate within the native IPv6 Internet. To do this, 
> >>it will have
> >> to transition from the 6to4 domain to the native IPv6 
> >>Internet via
> >> a relay router which may/may not occur on *this* 6to4 router.
> >>
> >> Is the 6to4 interface the correct interface to 
> >>decapsulate for this 
> >>case?
> >> It seems somewhat less obvious to me, but still a better 
> >>choice than
> >> the ISATAP interface when the source prefix is not on-link.
> >> 
> >>
> >
> >If the 6to4 interface isn't a 6to4 relay interface 
> >the 6to4 interface will and should discard the packet silently.
> >
> > 
> >
> >>>**Here again it should be emphasized that these rules are 
> >>> 
> >>>
> >>not intended to
> >> 
> >>
> >>>apply to the Isatap router-to-router tunnelling situation.**
> >>>
> >>> 
> >>>
> >>I am fine with leaving this aspect out from the current discussion.
> >>
> >> 
> >>
> >>>I am not 100 % sure what you mean by an on-link 6to4 prefix.
> >>>
> >>> 
> >>>
> >>I think I may have been stuck with a mis-conception that 6to4 
> >>interfaces
> >>should only decapsulate packets with an IPv6 destination prefix of
> >>2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the
> >>node's IPv4 interfaces.
> >>
> >> 
> >>
> >>>I can imagine that you refer to one of the following 2 situations:
> >>>(I)
> >>>_ _ _ _ - - - - - - - - - - - - - - 
> >>>| | ___ | Global Internet/exterior 
> >>> 
> >>>
> >>| 
> >> 
> >>
> >>>| 6to4 |-v6-/ R \ | _ _ _ _ _ |
> >>>| Site | \___/-globalV4ADDR-| Intra | |
> >>>|_ _ _ _| | -site | | 
> >>> - - - - - - - - - - - - - - 
> >>>
> >>>(II) - - - - - - - - - - 
> >>> ___ | Global Internet/ | 
> >>> / R \ | _ _ _ _ _ exterior|
> >>> \___/-globalV4ADDR-| Intra | | 
> >>> | -site | | 
> >>> | of 6to4 | | 
> >>> | prefix | | 
> >>> - - - - - - - - - -
> >>>
> >>>In both situations a packet with the mentioned inner source address
> >>>should be from within the intra-site and should be processed 
> >>> 
> >>>
> >>by the Isatap
> >> 
> >>
> >>>interface and not the 6to4 interface turned towards the exterior.
> >>>
> >>>In (I), then in our 6to4 implementation, the packet with the 
> >>> 
> >>>
> >>mentioned source address,
> >> 
> >>
> >>>will be discarded by the 6to4 tunnel interfaces as we rely 
> >>> 
> >>>
> >>on trusted relay routers.
> >> 
> >>
> >>>It wil not be accepted as a packet from a 6to4 border router 
> >>> 
> >>>
> >>since the v6 and the v4 sources
> >> 
> >>
> >>>don't add up.
> >>>
> >>>In (II)
> >>>The packet is a packet coming from and destined for the 
> >>> 
> >>>
> >>Intra-site and should
> >> 
> >>
> >>>be processed by the intra-site router interface (i.e. the Isatap
> >>>interface). Again
> >>>the 6to4 interface would discard the packet,
> >>>further It should be redirected but thats another matter.
> >>>
> >>> 
> >>>
> >>I'm not prepared to comment on this in detail since I'm not 
> >>entirely sure
> >>what you are referring to by "the mentioned inner source 
> address", and
> >>your examples might have been motivated by the misconception 
> >>I mentioned
> >>above. Perhaps this discussion is obviated by the examination 
> >>of the cases
> >>I provided earlier?
> >>
> >> 
> >>
> >
> >I apologize. The above was an attempt to explain why the
> >Isatap source address check should precede the 6to4 
> destination check when allocating
> >the appropriate tunnel interface on the inbound path in case
> >where both 6to4 and isatap interfaces are anchored on the 
> same ipv4 interface. 
> >
> >But then I understand now that we may be in agreement on that.
> >
> >By "mentioned inner source address", I mean an encapsulated 
> packet where inner
> > source address matches a prefix of the ISATAP interface.
> >
> >BR, Karen
> >
> >
> > 
> >
> 
> 

--0-37992272-1082378878=:146
Content-Type: text/html; charset=us-ascii

<DIV>Hi Karen,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Almost, except that I think it might be possible for more than one ISATAP</DIV>
<DIV>interface to be configured over the same IPv4 address (IPv4 address-to-</DIV>
<DIV>interface mapping, actually).&nbsp;For each such ISATAP interface for which</DIV>
<DIV>the &nbsp;IPv6 source is on-link,&nbsp;the IPv6 destination address should be checked</DIV>
<DIV>until a match is found. If no matching ISATAP interface is found, the 6to4</DIV>
<DIV>interface(s) should be checked next. BTW, checking for a matching IPv6</DIV>
<DIV>destination address is part of what I mean when I say "belongs to" an</DIV>
<DIV>interface.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred Templin</DIV>
<DIV><A href="mailto:osprey67@yahoo.com">osprey67@yahoo.com</A><BR><BR><B><I>"Karen E. Nielsen (AH/TED)" &lt;karen.e.nielsen@ericsson.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi Fred,<BR><BR>Yes, <BR>given that router-to-router tunnelling isn't an issue.<BR>I agree wrt the router case.<BR><BR>Wrt the host case, <BR>I believe that the rules should be bound to the<BR>destination address rather than the source address - that is:<BR>if a 6to4 interface and an isatap interface are configured over<BR>the same IPv4 address, a received packet's inner IPv6 destination address<BR>is first checked to see if it matches an address of the Isatap interface <BR>(in which case it should be processed by that interface).<BR>Next, if the packet does not belong to the isatap interface, <BR>it is checked to see if it belongs to the 6to4 interface.<BR><BR>BR, Karen<BR><BR><BR>&gt; -----Original Message-----<BR>&gt; From: Fred Templin [mailto:ftemplin@iprg.nokia.com]<BR>&gt; Sent: 16. april 2004 18:40<BR>&gt; To: Karen E. Nielsen (AH/TED)<BR>&gt; Cc: IPv6 Operations<BR>&gt;
 Subject: Re: 6to4; ISATAP interfaces configured over same IPv4 address<BR>&gt; (was: Re: FYI Isatap implementations info)<BR>&gt; <BR>&gt; <BR>&gt; Hi Karen,<BR>&gt; <BR>&gt; It looks like we have reached conclusions on this topic. Conclusions<BR>&gt; are that, if a 6to4 interface and isatap interface are configured over<BR>&gt; the same IPv4 address, a received packet's inner IPv6 source address<BR>&gt; is first checked to see if it has an on-link prefix on the <BR>&gt; isatap interface.<BR>&gt; Next, if the packet does not belong to the isatap interface, <BR>&gt; it is checked<BR>&gt; to see if it belongs to the 6to4 interface.<BR>&gt; <BR>&gt; Can we consider this case now closed?<BR>&gt; <BR>&gt; Fred<BR>&gt; ftemplin@iprg.nokia.com<BR>&gt; <BR>&gt; Karen E. Nielsen (AH/TED) wrote:<BR>&gt; <BR>&gt; &gt;Hi Fred,<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;If a 6to4 interface
 and ISATAP interface are configured <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;over the same<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;IPv4 address, it would have to be a global IPv4 address <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;assigned to an<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;interface connected to the global Internet due to 6to4 <BR>&gt; &gt;&gt;&gt;&gt;requirements. In<BR>&gt; &gt;&gt;&gt;&gt;that case, I believe the correct behavior should be for the <BR>&gt; &gt;&gt;&gt;&gt;6to4 interface<BR>&gt; &gt;&gt;&gt;&gt;to take precedence for packets received with an on-link <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;6to4 prefix in<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;the IPv6 destination, and for the ISATAP interface to take <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;precedence<BR>&gt; &gt;&gt; <BR>&gt;
 &gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;for all others. Comments?<BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;When I say takes precedence over I (still) mean the following:<BR>&gt; &gt;&gt;&gt;First Priority: If the prefix of the source address in <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;the inner <BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt; IPv6 header of the encapsulated packet matches a prefix of the <BR>&gt; &gt;&gt;&gt; ISATAP interface, the packet is processed by this <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;tunnel interface.<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;This would seem like the correct natural choice, since it <BR>&gt; &gt;&gt;seems consistent<BR>&gt; &gt;&gt;with the notion of "intra-site". Again, I assume by this you <BR>&gt; &gt;&gt;are intending<BR>&gt; &gt;&gt;to include link-locals? (Perhaps that's *all* you are <BR>&gt;
 &gt;&gt;intending to include?)<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;Prefixes local to the Intra-site of the Isatap interface<BR>&gt; &gt;including link-locals are what I intend to include.<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt;&gt;Second Priority: If the prefix of either the source or <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;destination address <BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt; in the inner IPv6 header is a 6to4 prefix, the packet <BR>&gt; &gt;&gt;&gt; is processed by the 6to4 tunnel interface.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt;Let's take a closer look at the cases; please tell me if I <BR>&gt; &gt;&gt;mis-represent <BR>&gt; &gt;&gt;anything:<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; 1) If both the source and destination are 6to4, then the <BR>&gt; packet is <BR>&gt; &gt;&gt;originating<BR>&gt; &gt;&gt; and
 terminating within the 6to4 domain. So, use of the 6to4 <BR>&gt; &gt;&gt;interface would<BR>&gt; &gt;&gt; seem natural and appropriate. (Note that the destination <BR>&gt; &gt;&gt;might not <BR>&gt; &gt;&gt;belong to<BR>&gt; &gt;&gt; *this* 6to4 router in which case L3 might forward <BR>&gt; &gt;&gt;(redirect?) the <BR>&gt; &gt;&gt;packet to<BR>&gt; &gt;&gt; the correct 6to4 router - but, this is irrelevant for L2.5 <BR>&gt; &gt;&gt;decapsulation.)<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;I agree, though in case the destination is 6to4 but doesn't <BR>&gt; belong to this router, <BR>&gt; &gt;the packet will and should be silently discarded by the 6to4 <BR>&gt; tunnel interface. <BR>&gt; &gt;[in compliance with e.g. section 5.2 of <BR>&gt; draft-ietf-v6ops-6to4-security-02.txt].<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt; 2) If the destination is 6to4, but the source is not <BR>&gt; 6to4, then the <BR>&gt; &gt;&gt;packet
 is<BR>&gt; &gt;&gt; originating from behind a 6to4 relay router and <BR>&gt; &gt;&gt;terminating within the<BR>&gt; &gt;&gt; 6to4 domain. Again, the 6to4 interface seems the <BR>&gt; natural choice.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;I agree.<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt; 3) If the source is 6to4, but the destination is not 6to4, <BR>&gt; &gt;&gt;then the packet<BR>&gt; &gt;&gt; is originating from within the 6to4 domain and will eventually<BR>&gt; &gt;&gt; terminate within the native IPv6 Internet. To do this, <BR>&gt; &gt;&gt;it will have<BR>&gt; &gt;&gt; to transition from the 6to4 domain to the native IPv6 <BR>&gt; &gt;&gt;Internet via<BR>&gt; &gt;&gt; a relay router which may/may not occur on *this* 6to4 router.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; Is the 6to4 interface the correct interface to <BR>&gt; &gt;&gt;decapsulate for this <BR>&gt; &gt;&gt;case?<BR>&gt; &gt;&gt; It seems somewhat less obvious to me, but
 still a better <BR>&gt; &gt;&gt;choice than<BR>&gt; &gt;&gt; the ISATAP interface when the source prefix is not on-link.<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;If the 6to4 interface isn't a 6to4 relay interface <BR>&gt; &gt;the 6to4 interface will and should discard the packet silently.<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt;&gt;**Here again it should be emphasized that these rules are <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;not intended to<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;apply to the Isatap router-to-router tunnelling situation.**<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;I am fine with leaving this aspect out from the current discussion.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;I am not 100 % sure what you mean by an on-link 6to4 prefix.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;I think I may
 have been stuck with a mis-conception that 6to4 <BR>&gt; &gt;&gt;interfaces<BR>&gt; &gt;&gt;should only decapsulate packets with an IPv6 destination prefix of<BR>&gt; &gt;&gt;2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the<BR>&gt; &gt;&gt;node's IPv4 interfaces.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;I can imagine that you refer to one of the following 2 situations:<BR>&gt; &gt;&gt;&gt;(I)<BR>&gt; &gt;&gt;&gt;_ _ _ _ - - - - - - - - - - - - - - <BR>&gt; &gt;&gt;&gt;| | ___ | Global Internet/exterior <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;| <BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;| 6to4 |-v6-/ R \ | _ _ _ _ _ |<BR>&gt; &gt;&gt;&gt;| Site | \___/-globalV4ADDR-| Intra | |<BR>&gt; &gt;&gt;&gt;|_ _ _ _| | -site | | <BR>&gt; &gt;&gt;&gt; - - - - - - - - - - - - - - <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;(II) - - - - - - - - - - <BR>&gt; &gt;&gt;&gt; ___ | Global Internet/ | <BR>&gt; &gt;&gt;&gt; / R \ | _
 _ _ _ _ exterior|<BR>&gt; &gt;&gt;&gt; \___/-globalV4ADDR-| Intra | | <BR>&gt; &gt;&gt;&gt; | -site | | <BR>&gt; &gt;&gt;&gt; | of 6to4 | | <BR>&gt; &gt;&gt;&gt; | prefix | | <BR>&gt; &gt;&gt;&gt; - - - - - - - - - -<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;In both situations a packet with the mentioned inner source address<BR>&gt; &gt;&gt;&gt;should be from within the intra-site and should be processed <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;by the Isatap<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;interface and not the 6to4 interface turned towards the exterior.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;In (I), then in our 6to4 implementation, the packet with the <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;mentioned source address,<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;will be discarded by the 6to4 tunnel interfaces as we rely <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;on trusted relay routers.<BR>&gt;
 &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;It wil not be accepted as a packet from a 6to4 border router <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;since the v6 and the v4 sources<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;don't add up.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;In (II)<BR>&gt; &gt;&gt;&gt;The packet is a packet coming from and destined for the <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;Intra-site and should<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;be processed by the intra-site router interface (i.e. the Isatap<BR>&gt; &gt;&gt;&gt;interface). Again<BR>&gt; &gt;&gt;&gt;the 6to4 interface would discard the packet,<BR>&gt; &gt;&gt;&gt;further It should be redirected but thats another matter.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;I'm not prepared to comment on this in detail since I'm not <BR>&gt; &gt;&gt;entirely sure<BR>&gt; &gt;&gt;what you are referring to by "the
 mentioned inner source <BR>&gt; address", and<BR>&gt; &gt;&gt;your examples might have been motivated by the misconception <BR>&gt; &gt;&gt;I mentioned<BR>&gt; &gt;&gt;above. Perhaps this discussion is obviated by the examination <BR>&gt; &gt;&gt;of the cases<BR>&gt; &gt;&gt;I provided earlier?<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;I apologize. The above was an attempt to explain why the<BR>&gt; &gt;Isatap source address check should precede the 6to4 <BR>&gt; destination check when allocating<BR>&gt; &gt;the appropriate tunnel interface on the inbound path in case<BR>&gt; &gt;where both 6to4 and isatap interfaces are anchored on the <BR>&gt; same ipv4 interface. <BR>&gt; &gt;<BR>&gt; &gt;But then I understand now that we may be in agreement on that.<BR>&gt; &gt;<BR>&gt; &gt;By "mentioned inner source address", I mean an encapsulated <BR>&gt; packet where inner<BR>&gt; &gt; source address matches a prefix of the ISATAP interface.<BR>&gt;
 &gt;<BR>&gt; &gt;BR, Karen<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; <BR>&gt; <BR></BLOCKQUOTE>
--0-37992272-1082378878=:146--



From owner-v6ops@ops.ietf.org  Tue Apr 20 02:51:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26906
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 02:51:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFp2G-000IHJ-14
	for v6ops-data@psg.com; Tue, 20 Apr 2004 06:47:12 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BFp2B-000IFq-Ph
	for v6ops@ops.ietf.org; Tue, 20 Apr 2004 06:47:07 +0000
Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3K6l2WR021229
	for <v6ops@ops.ietf.org>; Tue, 20 Apr 2004 08:47:06 +0200 (MEST)
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Tue, 20 Apr 2004 08:47:02 +0200
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id JJGK1PLG; Tue, 20 Apr 2004 08:46:32 +0200
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY0CZ6L>; Tue, 20 Apr 2004 08:46:18 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E3C8@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 2d47a3d8 2c4885b5 276f8cf6 00000138
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Fred Templin'" <osprey67@yahoo.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: RE: 6to4; ISATAP interfaces configured over same IPv4 address (wa
	 s: Re: FYI Isatap implementations info)
Date: Tue, 20 Apr 2004 08:46:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C426A3.2E06F7FC"
X-OriginalArrivalTime: 20 Apr 2004 06:47:02.0499 (UTC) FILETIME=[49541B30:01C426A3]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C426A3.2E06F7FC
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Fred,
 
Please see enclosed.
 
BR, Karen

-----
Almost, except that I think it might be possible for more than one ISATAP
interface to be configured over the same IPv4 address (IPv4 address-to-
interface mapping, actually). 
 
OK.
 
  For each such ISATAP interface for which
the  IPv6 source is on-link,  
 
Why should the IPv6 source be on-link - 
The IPv6 source could be anything in principle, couldn't it ?
 
Shouldn't the destination address alone point the packet
to the Isatap interface. Letting Isatap 
specific decapsulation checks be applied subsequent
as part of Isatap interface receive processing - ?
 
 the IPv6 destination address should be checked
until a match is found. If no matching ISATAP interface is found, the 6to4
interface(s) should be checked next. BTW, checking for a matching IPv6
destination address is part of what I mean when I say "belongs to" an
interface.
 
Fred Templin
osprey67@yahoo.com <mailto:osprey67@yahoo.com> 

"Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com> wrote:

Hi Fred,

Yes, 
given that router-to-router tunnelling isn't an issue.
I agree wrt the router case.

Wrt the host case, 
I believe that the rules should be bound to the
destination address rather than the source address - that is:
if a 6to4 interface and an isatap interface are configured over
the same IPv4 address, a received packet's inner IPv6 destination address
is first checked to see if it matches an address of the Isatap interface 
(in which case it should be processed by that interface).
Next, if the packet does not belong to the isatap interface, 
it is checked to see if it belongs to the 6to4 interface.

BR, Karen


> -----Original Message-----
> From: Fred Templin [mailto:ftemplin@iprg.nokia.com]
> Sent: 16. april 2004 18:40
> To: Karen E. Nielsen (AH/TED)
> Cc: IPv6 Operations
&! gt; Subject: Re: 6to4; ISATAP interfaces configured over same IPv4 address
> (was: Re: FYI Isatap implementations info)
> 
> 
> Hi Karen,
> 
> It looks like we have reached conclusions on this topic. Conclusions
> are that, if a 6to4 interface and isatap interface are configured over
> the same IPv4 address, a received packet's inner IPv6 source address
> is first checked to see if it has an on-link prefix on the 
> isatap interface.
> Next, if the packet does not belong to the isatap interface, 
> it is checked
> to see if it belongs to the 6to4 interface.
> 
> Can we consider this case now closed?
> 
> Fred
> ftemplin@iprg.nokia.com
> 
> Karen E. Nielsen (AH/TED) wrote:
> 
> >Hi Fred,
> >
> > 
> >
> >>> 
> >>>
> >>> 
> >>>
> >>>>If a 6to4 i! nterface and ISATAP interface are configured 
> >>>> 
> >>>>
> >>over the same
> >> 
> >>
> >>>>IPv4 address, it would have to be a global IPv4 address 
> >>>> 
> >>>>
> >>assigned to an
> >> 
> >>
> >>>>interface connected to the global Internet due to 6to4 
> >>>>requirements. In
> >>>>that case, I believe the correct behavior should be for the 
> >>>>6to4 interface
> >>>>to take precedence for packets received with an on-link 
> >>>> 
> >>>>
> >>6to4 prefix in
> >> 
> >>
> >>>>the IPv6 destination, and for the ISATAP interface to take 
> >>>> 
> >>>>
> >>precedence
> >> 
> >>
> >>>>for all others. Comments?
> >>>> 
> >>>>
> >>>> 
> >>>>
> >>>When I say takes precedence over I (still) mean the following:
> >>>First Priority: If the prefix of the source address in 
> >>> 
> >>>
> >>the inner 
> >> 
> >>
> >>> IPv6 header of the encapsulated packet matches a prefix of the 
> >>> ISATAP interface, the packet is processed by this 
> >>> 
> >>>
> >>tunnel interface.
> >> 
> >>
> >>This would seem like the correct natural choice, since it 
> >>seems consistent
> >>with the notion of "intra-site". Again, I assume by this you 
> >>are intending
> >>to include link-locals? (Perhaps that's *all* you are 
> >>intending to include?)
> >>
> >> 
> >>
> >
> >Prefixes local to the Intra-site of the Isatap interface
> >including link-locals are what I intend to include.
> >
> > 
> >
> >>>Second Priority: If the prefix of either the source or 
> >>> 
> >>>
> >>destination address 
> >> 
> >>
> >>> in the inner IPv6 header is a 6to4 prefix, the packet 
> >>> is processed by the 6to4 tunnel interface.
> >>>
> >>> 
> >>>
> >
> > 
> >
> >>Let's take a closer look at the cases; please tell me if I 
> >>mis-represent 
> >>anything:
> >>
> >> 1) If both the source and destination are 6to4, then the 
> packet is 
> >>originating
> >! > and terminating within the 6to4 domain. So, use of the 6to4 
> >>interface would
> >> seem natural and appropriate. (Note that the destination 
> >>might not 
> >>belong to
> >> *this* 6to4 router in which case L3 might forward 
> >>(redirect?) the 
> >>packet to
> >> the correct 6to4 router - but, this is irrelevant for L2.5 
> >>decapsulation.)
> >>
> >> 
> >>
> >
> >I agree, though in case the destination is 6to4 but doesn't 
> belong to this router, 
> >the packet will and should be silently discarded by the 6to4 
> tunnel interface. 
> >[in compliance with e.g. section 5.2 of 
> draft-ietf-v6ops-6to4-security-02.txt].
> >
> >
> > 
> >
> >> 2) If the destination is 6to4, but the source is not 
> 6to4, then the 
> >>! ;packet is
> >> originating from behind a 6to4 relay router and 
> >>terminating within the
> >> 6to4 domain. Again, the 6to4 interface seems the 
> natural choice.
> >>
> >> 
> >>
> >
> >I agree.
> >
> > 
> >
> >> 3) If the source is 6to4, but the destination is not 6to4, 
> >>then the packet
> >> is originating from within the 6to4 domain and will eventually
> >> terminate within the native IPv6 Internet. To do this, 
> >>it will have
> >> to transition from the 6to4 domain to the native IPv6 
> >>Internet via
> >> a relay router which may/may not occur on *this* 6to4 router.
> >>
> >> Is the 6to4 interface the correct interface to 
> >>decapsulate for this 
> >>case?
> >> It seems somewhat less obvious to! me, but still a better 
> >>choice than
> >> the ISATAP interface when the source prefix is not on-link.
> >> 
> >>
> >
> >If the 6to4 interface isn't a 6to4 relay interface 
> >the 6to4 interface will and should discard the packet silently.
> >
> > 
> >
> >>>**Here again it should be emphasized that these rules are 
> >>> 
> >>>
> >>not intended to
> >> 
> >>
> >>>apply to the Isatap router-to-router tunnelling situation.**
> >>>
> >>> 
> >>>
> >>I am fine with leaving this aspect out from the current discussion.
> >>
> >> 
> >>
> >>>I am not 100 % sure what you mean by an on-link 6to4 prefix.
> >>>
> >>> 
> >>>
> >>I think ! I may have been stuck with a mis-conception that 6to4 
> >>interfaces
> >>should only decapsulate packets with an IPv6 destination prefix of
> >>2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the
> >>node's IPv4 interfaces.
> >>
> >> 
> >>
> >>>I can imagine that you refer to one of the following 2 situations:
> >>>(I)
> >>>_ _ _ _ - - - - - - - - - - - - - - 
> >>>| | ___ | Global Internet/exterior 
> >>> 
> >>>
> >>| 
> >> 
> >>
> >>>| 6to4 |-v6-/ R \ | _ _ _ _ _ |
> >>>| Site | \___/-globalV4ADDR-| Intra | |
> >>>|_ _ _ _| | -site | | 
> >>> - - - - - - - - - - - - - - 
> >>>
> >>>(II) - - - - - - - - - - 
> >>> ___ | Global Internet/ | 
> >>> /! R \ | _ _ _ _ _ exterior|
> >>> \___/-globalV4ADDR-| Intra | | 
> >>> | -site | | 
> >>> | of 6to4 | | 
> >>> | prefix | | 
> >>> - - - - - - - - - -
> >>>
> >>>In both situations a packet with the mentioned inner source address
> >>>should be from within the intra-site and should be processed 
> >>> 
> >>>
> >>by the Isatap
> >> 
> >>
> >>>interface and not the 6to4 interface turned towards the exterior.
> >>>
> >>>In (I), then in our 6to4 implementation, the packet with the 
> >>> 
> >>>
> >>mentioned source address,
> >> 
> >>
> >>>will be discarded by the 6to4 tunnel interfaces as we rely 
> >>> 
> >>>
> >>on trusted relay routers! .
> >> 
> >>
> >>>It wil not be accepted as a packet from a 6to4 border router 
> >>> 
> >>>
> >>since the v6 and the v4 sources
> >> 
> >>
> >>>don't add up.
> >>>
> >>>In (II)
> >>>The packet is a packet coming from and destined for the 
> >>> 
> >>>
> >>Intra-site and should
> >> 
> >>
> >>>be processed by the intra-site router interface (i.e. the Isatap
> >>>interface). Again
> >>>the 6to4 interface would discard the packet,
> >>>further It should be redirected but thats another matter.
> >>>
> >>> 
> >>>
> >>I'm not prepared to comment on this in detail since I'm not 
> >>entirely sure
> >>what you are referring t! o by "the mentioned inner source 
> address", and
> >>your examples might have been motivated by the misconception 
> >>I mentioned
> >>above. Perhaps this discussion is obviated by the examination 
> >>of the cases
> >>I provided earlier?
> >>
> >> 
> >>
> >
> >I apologize. The above was an attempt to explain why the
> >Isatap source address check should precede the 6to4 
> destination check when allocating
> >the appropriate tunnel interface on the inbound path in case
> >where both 6to4 and isatap interfaces are anchored on the 
> same ipv4 interface. 
> >
> >But then I understand now that we may be in agreement on that.
> >
> >By "mentioned inner source address", I mean an encapsulated 
> packet where inner
> > source address matches a prefix of the ISATAP interface.
> >
> >BR, Karen
> >
> >
> > 
> >
> 
> 



------_=_NextPart_001_01C426A3.2E06F7FC
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=641422106-20042004>Hi 
Fred,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=641422106-20042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=641422106-20042004>Please 
see enclosed.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=641422106-20042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=641422106-20042004>BR, 
Karen</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----</FONT></DIV>
  <DIV>Almost, except that I think it might be possible for more than one 
  ISATAP</DIV>
  <DIV>interface to be configured over the same IPv4 address (IPv4 
  address-to-</DIV>
  <DIV>interface mapping, actually).<SPAN class=641422106-20042004><FONT 
  face=Arial color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff 
  size=2>OK.</FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=641422106-20042004>&nbsp;</SPAN>&nbsp;For each such ISATAP 
  interface for which</DIV>
  <DIV>the &nbsp;IPv6 source is on-link,&nbsp;<SPAN 
  class=641422106-20042004><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff size=2>Why 
  should the IPv6 source be on-link - </FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff size=2>The 
  IPv6 source could be anything in principle, couldn't it ?</FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff 
  size=2>Shouldn't the destination address alone point the 
  packet</FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff size=2>to 
  the Isatap interface. Letting Isatap 
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff 
  size=2>specific decapsulation checks</FONT></SPAN><SPAN 
  class=641422106-20042004><FONT face=Arial color=#0000ff size=2> be applied 
  subsequent</FONT></SPAN></DIV></FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff size=2>as 
  part of Isatap interface receive processing - ?</FONT></SPAN></DIV>
  <DIV><SPAN class=641422106-20042004><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=641422106-20042004>&nbsp;</SPAN>the IPv6 destination address 
  should be checked</DIV>
  <DIV>until a match is found. If no matching ISATAP interface is found, the 
  6to4</DIV>
  <DIV>interface(s) should be checked next. BTW, checking for a matching 
  IPv6</DIV>
  <DIV>destination address is part of what I mean when I say "belongs to" 
  an</DIV>
  <DIV>interface.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Fred Templin</DIV>
  <DIV><A 
  href="mailto:osprey67@yahoo.com">osprey67@yahoo.com</A><BR><BR><B><I>"Karen E. 
  Nielsen (AH/TED)" &lt;karen.e.nielsen@ericsson.com&gt;</I></B> wrote:</DIV>
  <BLOCKQUOTE class=replbq 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi 
    Fred,<BR><BR>Yes, <BR>given that router-to-router tunnelling isn't an 
    issue.<BR>I agree wrt the router case.<BR><BR>Wrt the host case, <BR>I 
    believe that the rules should be bound to the<BR>destination address rather 
    than the source address - that is:<BR>if a 6to4 interface and an isatap 
    interface are configured over<BR>the same IPv4 address, a received packet's 
    inner IPv6 destination address<BR>is first checked to see if it matches an 
    address of the Isatap interface <BR>(in which case it should be processed by 
    that interface).<BR>Next, if the packet does not belong to the isatap 
    interface, <BR>it is checked to see if it belongs to the 6to4 
    interface.<BR><BR>BR, Karen<BR><BR><BR>&gt; -----Original 
    Message-----<BR>&gt; From: Fred Templin 
    [mailto:ftemplin@iprg.nokia.com]<BR>&gt; Sent: 16. april 2004 18:40<BR>&gt; 
    To: Karen E. Nielsen (AH/TED)<BR>&gt; Cc: IPv6 Operations<BR>&amp;! gt; 
    Subject: Re: 6to4; ISATAP interfaces configured over same IPv4 
    address<BR>&gt; (was: Re: FYI Isatap implementations info)<BR>&gt; <BR>&gt; 
    <BR>&gt; Hi Karen,<BR>&gt; <BR>&gt; It looks like we have reached 
    conclusions on this topic. Conclusions<BR>&gt; are that, if a 6to4 interface 
    and isatap interface are configured over<BR>&gt; the same IPv4 address, a 
    received packet's inner IPv6 source address<BR>&gt; is first checked to see 
    if it has an on-link prefix on the <BR>&gt; isatap interface.<BR>&gt; Next, 
    if the packet does not belong to the isatap interface, <BR>&gt; it is 
    checked<BR>&gt; to see if it belongs to the 6to4 interface.<BR>&gt; <BR>&gt; 
    Can we consider this case now closed?<BR>&gt; <BR>&gt; Fred<BR>&gt; 
    ftemplin@iprg.nokia.com<BR>&gt; <BR>&gt; Karen E. Nielsen (AH/TED) 
    wrote:<BR>&gt; <BR>&gt; &gt;Hi Fred,<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; 
    &gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; 
    <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;If a 6to4 i! nterface and 
    ISATAP interface are configured <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;over the same<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;IPv4 address, it would have to be a global 
    IPv4 address <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; 
    &gt;&gt;assigned to an<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; 
    &gt;&gt;&gt;&gt;interface connected to the global Internet due to 6to4 
    <BR>&gt; &gt;&gt;&gt;&gt;requirements. In<BR>&gt; &gt;&gt;&gt;&gt;that case, 
    I believe the correct behavior should be for the <BR>&gt; 
    &gt;&gt;&gt;&gt;6to4 interface<BR>&gt; &gt;&gt;&gt;&gt;to take precedence 
    for packets received with an on-link <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;6to4 prefix in<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;the IPv6 destination, and for the ISATAP 
    interface to take <BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;precedence<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt;for all others. Comments?<BR>&gt; 
    &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;When I say takes precedence over I 
    (still) mean the following:<BR>&gt; &gt;&gt;&gt;First Priority: If the 
    prefix of the source address in <BR>&gt; &gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;the inner <BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;&gt;&gt; IPv6 header of the encapsulated packet matches 
    a prefix of the <BR>&gt; &gt;&gt;&gt; ISATAP interface, the packet is 
    processed by this <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; 
    &gt;&gt;tunnel interface.<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; 
    &gt;&gt;This would seem like the correct natural choice, since it <BR>&gt; 
    &gt;&gt;seems consistent<BR>&gt; &gt;&gt;with the notion of "intra-site". 
    Again, I assume by this you <BR>&gt; &gt;&gt;are intending<BR>&gt; 
    &gt;&gt;to include link-locals? (Perhaps that's *all* you are <BR>&gt; 
    &gt;&gt;intending to include?)<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;Prefixes local to the Intra-site of the 
    Isatap interface<BR>&gt; &gt;including link-locals are what I intend to 
    include.<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt;&gt;Second 
    Priority: If the prefix of either the source or <BR>&gt; &gt;&gt;&gt; 
    <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;destination address <BR>&gt; &gt;&gt; 
    <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt; in the inner IPv6 header is a 6to4 
    prefix, the packet <BR>&gt; &gt;&gt;&gt; is processed by the 6to4 tunnel 
    interface.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt;Let's 
    take a closer look at the cases; please tell me if I <BR>&gt; 
    &gt;&gt;mis-represent <BR>&gt; &gt;&gt;anything:<BR>&gt; &gt;&gt;<BR>&gt; 
    &gt;&gt; 1) If both the source and destination are 6to4, then the <BR>&gt; 
    packet is <BR>&gt; &gt;&gt;originating<BR>&gt; &gt;! &gt; and terminating 
    within the 6to4 domain. So, use of the 6to4 <BR>&gt; &gt;&gt;interface 
    would<BR>&gt; &gt;&gt; seem natural and appropriate. (Note that the 
    destination <BR>&gt; &gt;&gt;might not <BR>&gt; &gt;&gt;belong to<BR>&gt; 
    &gt;&gt; *this* 6to4 router in which case L3 might forward <BR>&gt; 
    &gt;&gt;(redirect?) the <BR>&gt; &gt;&gt;packet to<BR>&gt; &gt;&gt; the 
    correct 6to4 router - but, this is irrelevant for L2.5 <BR>&gt; 
    &gt;&gt;decapsulation.)<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;I agree, though in case the destination is 
    6to4 but doesn't <BR>&gt; belong to this router, <BR>&gt; &gt;the packet 
    will and should be silently discarded by the 6to4 <BR>&gt; tunnel interface. 
    <BR>&gt; &gt;[in compliance with e.g. section 5.2 of <BR>&gt; 
    draft-ietf-v6ops-6to4-security-02.txt].<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; 
    &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt; 2) If the destination is 6to4, but the 
    source is not <BR>&gt; 6to4, then the <BR>&gt; &gt;&gt;! ;packet is<BR>&gt; 
    &gt;&gt; originating from behind a 6to4 relay router and <BR>&gt; 
    &gt;&gt;terminating within the<BR>&gt; &gt;&gt; 6to4 domain. Again, the 6to4 
    interface seems the <BR>&gt; natural choice.<BR>&gt; &gt;&gt;<BR>&gt; 
    &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;I agree.<BR>&gt; 
    &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt; 3) If the source is 6to4, 
    but the destination is not 6to4, <BR>&gt; &gt;&gt;then the packet<BR>&gt; 
    &gt;&gt; is originating from within the 6to4 domain and will 
    eventually<BR>&gt; &gt;&gt; terminate within the native IPv6 Internet. To do 
    this, <BR>&gt; &gt;&gt;it will have<BR>&gt; &gt;&gt; to transition from the 
    6to4 domain to the native IPv6 <BR>&gt; &gt;&gt;Internet via<BR>&gt; 
    &gt;&gt; a relay router which may/may not occur on *this* 6to4 
    router.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; Is the 6to4 interface the correct 
    interface to <BR>&gt; &gt;&gt;decapsulate for this <BR>&gt; 
    &gt;&gt;case?<BR>&gt; &gt;&gt; It seems somewhat less obvious to! me, but 
    still a better <BR>&gt; &gt;&gt;choice than<BR>&gt; &gt;&gt; the ISATAP 
    interface when the source prefix is not on-link.<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;If the 6to4 interface isn't a 6to4 relay 
    interface <BR>&gt; &gt;the 6to4 interface will and should discard the packet 
    silently.<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; &gt;&gt;&gt;**Here 
    again it should be emphasized that these rules are <BR>&gt; &gt;&gt;&gt; 
    <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;not intended to<BR>&gt; &gt;&gt; 
    <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;apply to the Isatap router-to-router 
    tunnelling situation.**<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;I am fine with leaving this aspect out from the 
    current discussion.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;&gt;&gt;I am not 100 % sure what you mean by an on-link 
    6to4 prefix.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;I think ! I may have been stuck with a 
    mis-conception that 6to4 <BR>&gt; &gt;&gt;interfaces<BR>&gt; &gt;&gt;should 
    only decapsulate packets with an IPv6 destination prefix of<BR>&gt; 
    &gt;&gt;2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the<BR>&gt; 
    &gt;&gt;node's IPv4 interfaces.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;&gt;&gt;I can imagine that you refer to one of the 
    following 2 situations:<BR>&gt; &gt;&gt;&gt;(I)<BR>&gt; &gt;&gt;&gt;_ _ _ _ 
    - - - - - - - - - - - - - - <BR>&gt; &gt;&gt;&gt;| | ___ | Global 
    Internet/exterior <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; 
    &gt;&gt;| <BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;| 6to4 
    |-v6-/ R \ | _ _ _ _ _ |<BR>&gt; &gt;&gt;&gt;| Site | \___/-globalV4ADDR-| 
    Intra | |<BR>&gt; &gt;&gt;&gt;|_ _ _ _| | -site | | <BR>&gt; &gt;&gt;&gt; - 
    - - - - - - - - - - - - - <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;(II) - - 
    - - - - - - - - <BR>&gt; &gt;&gt;&gt; ___ | Global Internet/ | <BR>&gt; 
    &gt;&gt;&gt; /! R \ | _ _ _ _ _ exterior|<BR>&gt; &gt;&gt;&gt; 
    \___/-globalV4ADDR-| Intra | | <BR>&gt; &gt;&gt;&gt; | -site | | <BR>&gt; 
    &gt;&gt;&gt; | of 6to4 | | <BR>&gt; &gt;&gt;&gt; | prefix | | <BR>&gt; 
    &gt;&gt;&gt; - - - - - - - - - -<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;In 
    both situations a packet with the mentioned inner source address<BR>&gt; 
    &gt;&gt;&gt;should be from within the intra-site and should be processed 
    <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;by the 
    Isatap<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;interface and 
    not the 6to4 interface turned towards the exterior.<BR>&gt; 
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;In (I), then in our 6to4 implementation, 
    the packet with the <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; 
    &gt;&gt;mentioned source address,<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; 
    &gt;&gt;&gt;will be discarded by the 6to4 tunnel interfaces as we rely 
    <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;on trusted relay 
    routers! .<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;It wil not 
    be accepted as a packet from a 6to4 border router <BR>&gt; &gt;&gt;&gt; 
    <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;since the v6 and the v4 
    sources<BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;don't add 
    up.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;In (II)<BR>&gt; &gt;&gt;&gt;The 
    packet is a packet coming from and destined for the <BR>&gt; &gt;&gt;&gt; 
    <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;Intra-site and should<BR>&gt; &gt;&gt; 
    <BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;&gt;be processed by the intra-site router 
    interface (i.e. the Isatap<BR>&gt; &gt;&gt;&gt;interface). Again<BR>&gt; 
    &gt;&gt;&gt;the 6to4 interface would discard the packet,<BR>&gt; 
    &gt;&gt;&gt;further It should be redirected but thats another 
    matter.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; 
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;I'm not prepared to comment on this in detail 
    since I'm not <BR>&gt; &gt;&gt;entirely sure<BR>&gt; &gt;&gt;what you are 
    referring t! o by "the mentioned inner source <BR>&gt; address", and<BR>&gt; 
    &gt;&gt;your examples might have been motivated by the misconception 
    <BR>&gt; &gt;&gt;I mentioned<BR>&gt; &gt;&gt;above. Perhaps this discussion 
    is obviated by the examination <BR>&gt; &gt;&gt;of the cases<BR>&gt; 
    &gt;&gt;I provided earlier?<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; <BR>&gt; 
    &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;I apologize. The above was an attempt to 
    explain why the<BR>&gt; &gt;Isatap source address check should precede the 
    6to4 <BR>&gt; destination check when allocating<BR>&gt; &gt;the appropriate 
    tunnel interface on the inbound path in case<BR>&gt; &gt;where both 6to4 and 
    isatap interfaces are anchored on the <BR>&gt; same ipv4 interface. <BR>&gt; 
    &gt;<BR>&gt; &gt;But then I understand now that we may be in agreement on 
    that.<BR>&gt; &gt;<BR>&gt; &gt;By "mentioned inner source address", I mean 
    an encapsulated <BR>&gt; packet where inner<BR>&gt; &gt; source address 
    matches a prefix of the ISATAP interface.<BR>&gt; &gt;<BR>&gt; &gt;BR, 
    Karen<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; <BR>&gt; &gt;<BR>&gt; <BR>&gt; 
    <BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C426A3.2E06F7FC--



From owner-v6ops@ops.ietf.org  Tue Apr 20 09:33:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16942
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 09:33:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFvJ8-000Pmo-1d
	for v6ops-data@psg.com; Tue, 20 Apr 2004 13:29:02 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BFvJ2-000Pkn-RB
	for v6ops@ops.ietf.org; Tue, 20 Apr 2004 13:28:57 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3KDStPA029058
	for <v6ops@ops.ietf.org>; Tue, 20 Apr 2004 15:28:56 +0200 (MEST)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Tue, 20 Apr 2004 15:28:55 +0200
Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id JJL7S0KS; Tue, 20 Apr 2004 15:19:47 +0200
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY9WT0Q>; Tue, 20 Apr 2004 15:19:39 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E3D0@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 585c4c19 2c4885b5 276f8cf6 00000138
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Fred Templin'" <ftemplin@iprg.nokia.com>,
        IPv6 Operations
	 <v6ops@ops.ietf.org>
Cc: dthaler@microsoft.com, mohitt@microsoft.com, tgleeson@cisco.com
Subject: RE: draft-ietf-ngtrans-isatap-21.txt
Date: Tue, 20 Apr 2004 15:19:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 20 Apr 2004 13:28:55.0613 (UTC) FILETIME=[6DDD4ED0:01C426DB]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

I think that this new draft is excellent and very focused.

FWIW, you may wish to take the following comments into consideration:


Section 7:

The draft refers to [mech] for the basic tunneling 
mech including outer IP header construction, but in principle 
the Isatap draft doesn't say anything about
how the outer header IPv4 destination address is chosen.
Shouldn't there be a section about encapsulation like
in the early Isatap drafts, e.g v12, 
specifying something like:

Encapsulation (from section 6.2 of v12)

   The specifications in [mech] section 3 are used.
   Additionally, the IPv6 next-hop address for packets encapsulated on
   an ISATAP link MUST be an ISATAP address; other packets are discarded
   and an ICMPv6 destination unreachable indication with code 3 (Address
   Unreachable) is returned to the source.

   The IPv4 address of the tunnel endpoint is determined from
   the Isatap interface identifier of the next-hop address.

Section 7.2:

Perhaps is should here be clarified that the PRLs only
are maintained on host interfaces and as such this check does not
apply to router interfaces.

Further, it may be worthwhile to specify the following additional
decapsulation check for Isatap host interfaces:
 - destination address should be an Isatap Address.

Section 8 general:
I miss a section stating that
multicast emulation isn't considered and that DAD
shouldn't be performed as part of address autoconfiguration.

Section 8.2:
"Unsolicited Router Advertisements are not sent on Isatap interfaces"
could be added for clarity.

Section 8.3.2:
Perhaps it would be worthwhile to specify one (or several)
MUST be supported mechanism(s) for PRL population.

A standard FQDN identifier to use for DNS record lookups
should be specified, e.g., "isatap.<domain_name>", where
<domain_name> is the DNS suffix configured on the underlying 
IPv4 interface.

Section 8.3.3:
The following check should also be applied to RAs:
- the ipv6 source address is an 
Isatap address that embeds the Ipv4 source address
in its interface identifier.

(this is not ensured by the "or'ed" rules in 7.2).

Section 8.4:

From a security perspective
as well as from an implementation perspective
I would like to see this section strengthened a bit
 along the following lines:

IPv6 Address resolution on Isatap interfaces consists of two steps:
- Link-layer address resolution
- IPv6 address reachability confirmation

Link-layer address resolution on Isatap interfaces 
is performed by static computation from the Isatap Interface identifier
of the next-hop Isatap address.

Link-layer addresses in Neighbor cache entries on Isatap Interfaces
MUST NOT be used unless they pass the following validity check:
 * Link-layer address must correspond to the Ipv4 address embedded within 
the Isatap interface identifier of the neighbor address.

IPv6 address reachability confirmation is performed by sending 
unicast Neighbor Solicitation 
messages and receiving a Neighbor Advertisment message.

During address resolution then a neighbor entry is considered
in INCOMPLETE state until Reachability Confirmation in form
 of a solicited Neighbor Advertisement has been received.

For security and scalability reasons the
IPv6 address reachability Confirmation step SHOULD be omitted
on Router Interfaces. 
[[FOR DISCUSSION: This behavior could be configurable on Router interfaces.
in trusted environments it could be useful to have NUD on the router also.
Default should be not to perform the reachability step]]

Host SHOULD perform the IPv6 address reachability step when performing
address resolution.
If the IPv6 address reachability step is omitted, NUD will not succeed.

Section 10:

You may wish to take the following observations into consideration:

A number of the threats described in [SENDPS] on Isatap ND are 
non-applicable to and/or easily preventable, Indeed:

4.1.1. Non-applicable given the above mentioned validity check
on neighbor cache entries - that is:
Link-layer addresses in Neighbor cache entries on Isatap Interfaces
MUST NOT be used unless they pass the following validity check:
 * Link-layer address must correspond to the Ipv4 address embedded within 
the Isatap interface identifier of the neighbor address.

4.1.3: Non-applicable if DAD is omitted

4.2.1: Non-applicable given that a trust worthy PRL population
mechanism is deployed.

4.2.2: 
Threat may be prevented all together by specifying that
an Isatap host interface MUST NOT operate with a non-zero PRL list.
That is, host-to-host only scenario not considered.

4.2.3:
Limited to the time in between successive refreshments of the PRL
given that a trust worthy PRL population
mechanism is deployed.

4.2.4
One may want to consider eliminating 4.2.4 of [SENDPS] simply 
(and boldly) by disallowing the redirect functionality on Isatap interfaces. 
The risk of not supporting the redirect functionality is very small;
The Redirect function is generally used to: 
§	Inform Isatap hosts of destinations with Isatap prefixes 
that are directly reachable by ISATAP tunneling from the IPv4 site of the Isatap host. 
§	Redirect Isatap hosts to a better first-hop on-link Isatap router for a specific destination
However, in the first situation above, a correct functioning Isatap host 
will learn of the on-link ISATAP prefixes from the RS/RA exchange performed 
periodically with all routers from its, also periodically updated, PRL list, 
and hence only a limited amount of time can elapse before it would correct its behavior.
The second situation is probably not relevant for ISATAP scenarios given that
router-to-router tunneling isn't supported. Indeed it is our experience that
routers typically only send Redirect messages indicating better 
first-hop router if the egress interface towards this better 
first-hop router for the packet in question is the same as 
the ingress that it received the packet on. In ISATAP scenarios,
 the ingress interface would be an ISATAP interface and 
such an interface cannot be used for Router-to-Router forwarding.

4.3.2:
Non-applicable if the Ipv6 address reachability step of
address resolution isn't implemented on Isatap router interfaces.

Security threats on Isatap ND in secured corporate intranet/enterprises :
------------------------------------------------------------------------

Given that 4.2.2 and 4.2.4 are prevented by specifying a particular behavior
on Isatap interfaces (as indicated right above). Then in accordance with
the table in section 4.4. of [SENDPS] only 4.3.1 remain a real concern
in this environment. This is for further investigation.

Security threats on Isatap ND in IPv4 source proof and protocol-41 perimeter guarded sites:
-------------------------------------------------------------------------------------------

The additional security treats associated with IPv6 neighbor discovery
described in [SENDPS] for the most part are non-applicable or 
can be prevented by simple measures to
Isatap host and routers in sites that are 
guarded against ip-protocol-41 at the perimeter
and for which IPv4 source spoofing isn't possible.

A prime example of an IPv4 source proof and protocol-41 perimeter guarded site
is the network a mobile operator where the GGSN have 
activated IPv4 address spoofing protection
and which in addition implement ip-protocol-41 filtering at the edges.

Note that IPv4 source address proof and ip-protocol-41 
site perimeter filtering together with the Isatap decapsulation rules
effectively establish source proofing on IPv6 Isatap addresses.

The following refer to the threats described in [SENDPS]:

4.1.2: Given Ipv4 source address proof, 
this attack may be prevented by requirering the following validity check
to be applied to received NA messages on Isatap interfaces:
In addition to the validity checks given in RFC 2461 a NA message must
pass the following validity check:
* the IPv6 address in the target field must 
be an Isatap address which embeds the v4 source address.

However it should be noted that this check will disallow ND proxy functionality
on Isatap sites, whether that's undesirable is not clear to me.
(one implication of course would be that the MIpv6 HA service cannot be provided
on Isatap sites but one would never want to do that anyway I think).

4.2.5+4.2.6+4.2.7:
Non-applicable given IPv4 source address spoofing prevention
if trustworthy PRL population mechanism is deployed.

4.2.2: 
Spoofed RA message with zero-lifetime is not applicable.
As mentioned above this threat may be prevented all together by specifying that
an Isatap host interface MUST NOT operate with a non-zero PRL list.

4.2.3:
Limited to the time in between successive refreshments of the PRL
 for the same reasons as 4.2.1.
In addition then compromising the Isatap router itself
 is a doubtful scenario in carefully managed networks 
such as e.g. 3GPP/3GPP2 and enterprise networks.

4.2.4:
Is limited by Ipv4 source address spoofing prevention.
In addition then compromising the Isatap router itself
 is a doubtful scenario in 3GPP/3GPP2 and enterprise networks
May be prevented altogether by disallowing the redirect 
functionality on Isatap interfaces as mentioned above.

4.3.1:
Non-applicable by Ipv4 source address spoofing prevention.


BR, Karen

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Fred Templin
> Sent: 17. april 2004 02:22
> To: IPv6 Operations
> Cc: dthaler@microsoft.com; mohitt@microsoft.com; tgleeson@cisco.com;
> ftemplin@iprg.nokia.com
> Subject: draft-ietf-ngtrans-isatap-21.txt
> 
> 
> Hello,
> 
> A new version of the ISATAP specification (isatap-21) has
> been submitted to the I-D registrar and is also available
> for early review at:
> 
>       www.geocities.com/osprey67/isatap/isatap-21.txt
>     
> The purpose of the -21 version is to satisfy the clear requirement 
> for documenting the widely-deployed implementations. We request that
> the -21 version now be adopted as a v6ops wg document.
> 
> Fred L. Templin (for the ISATAP co-authors)
> ftemplin@iprg.nokia.com
> 
> 
> 



From owner-v6ops@ops.ietf.org  Tue Apr 20 11:03:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23897
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 11:03:23 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFwjv-000M0u-JO
	for v6ops-data@psg.com; Tue, 20 Apr 2004 15:00:47 +0000
Received: from [131.228.20.21] (helo=mgw-x1.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BFwjc-000Lul-Kf; Tue, 20 Apr 2004 15:00:28 +0000
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KF0Qk10270;
	Tue, 20 Apr 2004 18:00:26 +0300 (EET DST)
X-Scanned: Tue, 20 Apr 2004 17:59:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3KExbsI002565;
	Tue, 20 Apr 2004 17:59:37 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 002mYBZ9; Tue, 20 Apr 2004 17:59:35 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KExJs23576;
	Tue, 20 Apr 2004 17:59:19 +0300 (EET DST)
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 20 Apr 2004 17:56:42 +0300
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 20 Apr 2004 17:56:42 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS Scenario 1
Date: Tue, 20 Apr 2004 17:56:41 +0300
Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE2FA@esebe005.ntc.nokia.com>
Thread-Topic: 3GPP Analysis - further IESG comments
thread-index: AcQjvmnb9qCQmFR8SLC65gwwP2ye9gAAALYwAMhQThA=
From: <juha.wiljakka@nokia.com>
To: <v6ops@ops.ietf.org>, <mankin@psg.com>, <jon.peterson@neustar.biz>
Cc: <pekkas@netcore.fi>, <Jonne.Soininen@nokia.com>, <david.kessens@nokia.com>
X-OriginalArrivalTime: 20 Apr 2004 14:56:42.0771 (UTC) FILETIME=[B155D630:01C426E7]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable


 Hi!

3GPP Analysis has -09 received some comments from the IESG and I start =
the mailing list discussion with the comments considering IMS Scenario =
1. There are two comments from Allison and Jon:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(1)
Commented by:Mankin, Allison =20
Comment:My understanding is that this analysis is for 3GPP, rather than =
reflecting an existing
fully-formed 3GPP analysis, so that we influence what 3GPP thinks.

3GPP desperately needs to grapple with a robust model for IMS systems =
when
they communication with IPv4 only hosts.  (They also needs a model for =
those
systems to deal with expressing a preference for IPv6 usage should =
vendors
provide IPv4 IMS capability).=20

The document wisely says that the SIP WG can do a good job of providing =
this
model, but then unwisely both describes a model and references a more
detailed draft.  Both models are not good cross-area products, since =
they
design a SIP ALG and a NAT-PT structure for SIP's SDP.=20

Since SIP terminates the connection endpoints at proxies, it can change
the Internet protocol at those points, therefore, it would be possible =
to
provide a reverse NAT for IPv4 addresses and route them to translating
proxies at a boundary point where the IMS system had dual stack
capability (this is just one idea).  The media situation is harder, but
the review of this needs to consider capabilities such as terminating
the media at a mixer and changing the Internet protocol there (SDP
rewriting is not OK), using only DNS names by policy, so both ends
of the media user could use a generic transition mechanism not
specialized into 3GPP.

My recommendation is that this section only contain a strong referral
with a deadline for the SIP/SDP community to do this work, rather
than sketching problematic approaches.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I fully agree that we need a referral with a deadline for the SIP/SDP =
community, and we could use stronger wording than we have in -09 (would =
a good deadline be by the end of this year?). It is clear that we leave =
the closer details of the solution to be specified by the SIPpish wgs - =
specifying new mechanisms is out of the scope of this document. The =
current text says:

   "This section presents higher level details of a solution based on=20
    the use of a translator and SIP ALG. [3GPPtr] provides additional=20
    information and presents a bit different solution proposal based on=20
    SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to=20
    solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF=20
    SIP wg(s)."

Removal of [3GPPtr] informative reference is needed?

I understand that rewriting SDP is one of your concerns. But would it be =
acceptable in cases when a solution is needed, and there is no other way =
around to solve the problem? We could state in the draft that =
alternative mechanisms will be developed in the future to solve the =
problem in some other way than rewriting the SDP, and when those =
mechanisms will be available, SDP rewriting should not be applied any =
more. And write text on the problems with rewriting SDP.

Anyway, I wouldn't like to remove all details in section 4.1, because =
that would make our document less useful.

Comments on the mailing list are more than welcome!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(2)
Commented by:Peterson, Jon =20
Comment:The use of SIP ALGs has security implications - namely, it =
precludes certain security mechanisms (namely S/MIME) described in =
RFC3261 which might protect the integrity or confidentiality of SDP, or =
even SIP headers in some instances. While this document does suggest =
that more work needs to be done in the SIPpish WGs to address the SIP =
6-to-4 problem, it describes no other solution than the use of SIP ALGs. =
Accordingly, a mention of the effects of ALGs on SIP security in the =
Security Considerations is probably warranted.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We could mention that the usage of an ALG has known security issues in =
the Security Considerations section. And in the case the SIP messages =
are S/MIME protected, then the usage of the SIP-ALG might not be =
possible. Would that address the concerns?

Best Regards,
	           -Juha W.-



From owner-v6ops@ops.ietf.org  Tue Apr 20 11:14:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24525
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 11:14:57 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFwvr-000Pbq-DI
	for v6ops-data@psg.com; Tue, 20 Apr 2004 15:13:07 +0000
Received: from [212.16.99.49] (helo=burp.tkv.asdf.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BFwu8-000PJi-UR
	for v6ops@ops.ietf.org; Tue, 20 Apr 2004 15:11:21 +0000
Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1])
	by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i3KFAxH3031729;
	Tue, 20 Apr 2004 18:10:59 +0300
Received: (from msa@localhost)
	by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3KFAxMk031726;
	Tue, 20 Apr 2004 18:10:59 +0300
Date: Tue, 20 Apr 2004 18:10:59 +0300
Message-Id: <200404201510.i3KFAxMk031726@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: karen.e.nielsen@ericsson.com
CC: ftemplin@iprg.nokia.com, v6ops@ops.ietf.org, dthaler@microsoft.com,
        mohitt@microsoft.com, tgleeson@cisco.com
In-reply-to: 
	<C26BB8276599A44B85D52F9CE41035E10229E3D0@esealnt944.al.sw.ericsson.se>
	(karen.e.nielsen@ericsson.com)
Subject: Re: draft-ietf-ngtrans-isatap-21.txt
References: <C26BB8276599A44B85D52F9CE41035E10229E3D0@esealnt944.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


I've some problem with section 8:

  ...
  8. Neighbor Discovery for ISATAP Interfaces

   ISATAP nodes use the neighbor discovery mechanisms specified in
   [RFC2461] to create/change neighbor cache entries. ISATAP interfaces
   also implement the following specifications:
  ...

I don't see how a neighbor cache entries would get created. You cannot
run normal RFC2461 neighbor discovery on ISATAP interface to detect
link layer addresses: ISATAP interface does not support multicast!

I think all references to neighbor cache could be removed (there is no
need for link layer addresses). Like, in section 8.4

  ...
  8.4 Address Resolution

   The specification in ([RFC2461], section 7.2) is used. ISATAP
   addresses for which the neighbor's link-layer address cannot
   otherwise be determined (e.g., from a neighbor cache entry) are
   resolved to link-layer addresses by a static computation, i.e., the
   last four octets are treated as an IPv4 address.
  ...

Change above just into

  ...
  8.4 Address Resolution

   ISATAP addresses are resolved to link-layer addresses by a static
   computation, i.e., the last four octets are treated as an IPv4
   address.
  ...

A corollary to above is: ISATAP IPv6 "nexthop address" is always based
on one of the PRL addresses.




From owner-v6ops@ops.ietf.org  Tue Apr 20 13:16:06 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05275
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 13:16:06 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFyoP-00071p-RQ
	for v6ops-data@psg.com; Tue, 20 Apr 2004 17:13:33 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BFyoF-0006zf-EJ
	for v6ops@ops.ietf.org; Tue, 20 Apr 2004 17:13:23 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3KHDMWR011322
	for <v6ops@ops.ietf.org>; Tue, 20 Apr 2004 19:13:22 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Tue, 20 Apr 2004 19:13:22 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <JJ3VLXDT>; Tue, 20 Apr 2004 19:12:44 +0200
Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639BAB@ESEALNT442.al.sw.ericsson.se>
From: "Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>
To: "'juha.wiljakka@nokia.com'" <juha.wiljakka@nokia.com>, v6ops@ops.ietf.org,
        mankin@psg.com, jon.peterson@neustar.biz
Cc: pekkas@netcore.fi, Jonne.Soininen@nokia.com, david.kessens@nokia.com,
        "Gonzalo Camarillo (JO/LMF)" <gonzalo.camarillo@ericsson.com>
Subject: RE: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS 
	Scenario 1
Date: Tue, 20 Apr 2004 19:12:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-OriginalArrivalTime: 20 Apr 2004 17:13:22.0386 (UTC) FILETIME=[C8AFCB20:01C426FA]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

 > 3GPP Analysis has -09 received some comments from the IESG 
 > and I start the mailing list discussion with the comments 
 > considering IMS Scenario 1. There are two comments from 
 > Allison and Jon:
 > 
 > =====================================
 > (1)
 > Commented by:Mankin, Allison  
 > Comment:My understanding is that this analysis is for 3GPP, 
 > rather than reflecting an existing
 > fully-formed 3GPP analysis, so that we influence what 3GPP thinks.
 > 
 > 3GPP desperately needs to grapple with a robust model for 
 > IMS systems when
 > they communication with IPv4 only hosts.  (They also needs a 
 > model for those
 > systems to deal with expressing a preference for IPv6 usage 
 > should vendors
 > provide IPv4 IMS capability). 
 > 
 > The document wisely says that the SIP WG can do a good job 
 > of providing this
 > model, but then unwisely both describes a model and references a more
 > detailed draft.  Both models are not good cross-area 
 > products, since they
 > design a SIP ALG and a NAT-PT structure for SIP's SDP.
 > 
 > Since SIP terminates the connection endpoints at proxies, it 
 > can change
 > the Internet protocol at those points, therefore, it would 
 > be possible to
 > provide a reverse NAT for IPv4 addresses and route them to 
 > translating
 > proxies at a boundary point where the IMS system had dual stack
 > capability (this is just one idea).  The media situation is 
 > harder, but
 > the review of this needs to consider capabilities such as terminating
 > the media at a mixer and changing the Internet protocol there (SDP
 > rewriting is not OK), using only DNS names by policy, so both ends
 > of the media user could use a generic transition mechanism not
 > specialized into 3GPP.

I assume that the more detailed reference draft mentioned above is
draft-elmalki-sipping-3gpp-translator-00 [3gpptr].
This draft does not design a SIP ALG and NAT-PT but avoids SDP editing
since this had been pointed out by some SIP experts already. So the purpose 
was exactly to address a number of the comments you bring up and continue
working on a solution in SIPPING. Regarding the 3gpp analysis draft I think
it could state the issues more clearly (esp. SDP editing consequences) but
I am afraid that if it doesn't provide any guidance on SIP IMS it won't be
as helpful to 3gpp.

/Karim



From owner-v6ops@ops.ietf.org  Tue Apr 20 14:02:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08831
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 14:02:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BFzXb-000JSF-Ll
	for v6ops-data@psg.com; Tue, 20 Apr 2004 18:00:15 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BFzXP-000JK2-FV
	for v6ops@ops.ietf.org; Tue, 20 Apr 2004 18:00:03 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3KI02PA020774
	for <v6ops@ops.ietf.org>; Tue, 20 Apr 2004 20:00:02 +0200 (MEST)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	 Tue, 20 Apr 2004 20:00:02 +0200
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id JJL7WWKG; Tue, 20 Apr 2004 19:58:50 +0200
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HJY0C9LR>; Tue, 20 Apr 2004 19:58:49 +0200
Message-ID: <C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 8ce8fcfa 2c4885b5 9fd3eb93 00000138
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Markku Savela'" <msa@burp.tkv.asdf.org>
Cc: ftemplin@iprg.nokia.com, v6ops@ops.ietf.org, dthaler@microsoft.com,
        mohitt@microsoft.com, tgleeson@cisco.com
Subject: RE: draft-ietf-ngtrans-isatap-21.txt
Date: Tue, 20 Apr 2004 19:58:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 20 Apr 2004 18:00:02.0070 (UTC) FILETIME=[4D6DAB60:01C42701]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk



On Isatap interfaces the purpose of the NC isn't to maintain mappings of
Neighbor Ipv6 addresses (which are always Isatap addresses) 
to link-layer addresses, since that is indeed achieved
by static computation from the interface identifier part of the neighbors Isatap Address.

The purpose of the NC on Isatap interface, in my understanding of the draft, is
to maintain reachability information used for NUD.

> -----Original Message-----
> From: Markku Savela [mailto:msa@burp.tkv.asdf.org]
> Sent: 20. april 2004 17:11
> To: Karen E. Nielsen (AH/TED)
> Cc: ftemplin@iprg.nokia.com; v6ops@ops.ietf.org; 
> dthaler@microsoft.com;
> mohitt@microsoft.com; tgleeson@cisco.com
> Subject: Re: draft-ietf-ngtrans-isatap-21.txt
> 
> 
> 
> I've some problem with section 8:
> 
>   ...
>   8. Neighbor Discovery for ISATAP Interfaces
> 
>    ISATAP nodes use the neighbor discovery mechanisms specified in
>    [RFC2461] to create/change neighbor cache entries. ISATAP 
> interfaces
>    also implement the following specifications:
>   ...
> 
> I don't see how a neighbor cache entries would get created. You cannot
> run normal RFC2461 neighbor discovery on ISATAP interface to detect
> link layer addresses: ISATAP interface does not support multicast!
> 
> I think all references to neighbor cache could be removed (there is no
> need for link layer addresses). Like, in section 8.4
> 
>   ...
>   8.4 Address Resolution
> 
>    The specification in ([RFC2461], section 7.2) is used. ISATAP
>    addresses for which the neighbor's link-layer address cannot
>    otherwise be determined (e.g., from a neighbor cache entry) are
>    resolved to link-layer addresses by a static computation, i.e., the
>    last four octets are treated as an IPv4 address.
>   ...
> 
> Change above just into
> 
>   ...
>   8.4 Address Resolution
> 
>    ISATAP addresses are resolved to link-layer addresses by a static
>    computation, i.e., the last four octets are treated as an IPv4
>    address.
>   ...
> 

I on the other hand think that address resolution on Isatap interfaces
in general should be a two step procedure consisting of
address resolution performed by static computation followed by
a unicast NS/NA exchange confirming reachability of the Ipv6 peer IPv6.

When I say in general this refer to the fact that step two may be
too resource demanding on some routers as well as it opens
up for the canionical DoS attack in this respect (4.3.2 of SENDPS).

> A corollary to above is: ISATAP IPv6 "nexthop address" is always based
> on one of the PRL addresses.
> 

Why ?

BR, Karen



From owner-v6ops@ops.ietf.org  Tue Apr 20 16:10:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19669
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 16:10:54 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BG1XA-000PRf-8h
	for v6ops-data@psg.com; Tue, 20 Apr 2004 20:07:56 +0000
Received: from [212.16.99.49] (helo=burp.tkv.asdf.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BG1X7-000PRE-KB
	for v6ops@ops.ietf.org; Tue, 20 Apr 2004 20:07:53 +0000
Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1])
	by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i3KK7PX5002093;
	Tue, 20 Apr 2004 23:07:25 +0300
Received: (from msa@localhost)
	by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3KK7Oqm002090;
	Tue, 20 Apr 2004 23:07:24 +0300
Date: Tue, 20 Apr 2004 23:07:24 +0300
Message-Id: <200404202007.i3KK7Oqm002090@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: karen.e.nielsen@ericsson.com
CC: ftemplin@iprg.nokia.com, v6ops@ops.ietf.org, dthaler@microsoft.com,
        mohitt@microsoft.com, tgleeson@cisco.com
In-reply-to: 
	<C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se>
	(karen.e.nielsen@ericsson.com)
Subject: Re: draft-ietf-ngtrans-isatap-21.txt
References: <C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


> From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
> 
> I on the other hand think that address resolution on Isatap interfaces
> in general should be a two step procedure consisting of
> address resolution performed by static computation followed by
> a unicast NS/NA exchange confirming reachability of the Ipv6 peer IPv6.

I was hoping that the ISATAP interface would look like standard IPv6
interface to the stack. The above procedure is not what stack would do
on any interface. The currently defined choices for "standard" IPv6
interfaces are:

  1) Point-to-point (no addresses on the link)

  2) "Ethernet type", link layer addresses, RFC2461 style neighbor
     discovery (which relies on multicast).

> 
> > A corollary to above is: ISATAP IPv6 "nexthop address" is always based
> > on one of the PRL addresses.
> > 
> 
> Why ?

Because, by my conclusion that you cannot run neighbor discovery on
the ISATAP link, the only known addresses associated with the
interface would be the ISATAP routers from PRL. There is no "standard"
process that would bring anything else into NC.

Actually, I would question, what use would there be for any other
addresses? The node can communicate with all potential "neigbors"
directly using normal IPv4. It needs ISATAP only to talk with
non-neighbor IPv6 destinations, for which the next-hop is the ISATAP
router.




From owner-v6ops@ops.ietf.org  Tue Apr 20 16:14:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20007
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 16:14:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BG1cb-0000AD-OU
	for v6ops-data@psg.com; Tue, 20 Apr 2004 20:13:33 +0000
Received: from [212.16.99.49] (helo=burp.tkv.asdf.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BG1ca-00009f-4Y
	for v6ops@ops.ietf.org; Tue, 20 Apr 2004 20:13:32 +0000
Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1])
	by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i3KKDFj5002119;
	Tue, 20 Apr 2004 23:13:15 +0300
Received: (from msa@localhost)
	by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3KKDFaw002116;
	Tue, 20 Apr 2004 23:13:15 +0300
Date: Tue, 20 Apr 2004 23:13:15 +0300
Message-Id: <200404202013.i3KKDFaw002116@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: karen.e.nielsen@ericsson.com
CC: ftemplin@iprg.nokia.com, v6ops@ops.ietf.org, dthaler@microsoft.com,
        mohitt@microsoft.com, tgleeson@cisco.com
In-reply-to: 
	<C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se>
	(karen.e.nielsen@ericsson.com)
Subject: Re: draft-ietf-ngtrans-isatap-21.txt
References: <C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Oh, additional thing: I did make an experimental implementaion based
on ISATAP-20 draft (or something), which used IPv6 multicast mapped to
IPv4 multicast (organisation scope). This worked just fine, as long as
the nodes "heard" the multicast. Even link local name resolution
(LLMNR) worked nicely over ISATAP interface, neighbors find each other
just fine.

But, it's really ugly looking to communicate with tunneled packets
between hosts on the same LAN :-)




From owner-v6ops@ops.ietf.org  Tue Apr 20 20:37:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11184
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 20:37:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BG5ga-000FF4-Lb
	for v6ops-data@psg.com; Wed, 21 Apr 2004 00:33:56 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BG5gZ-000FEf-QH
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 00:33:55 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3L0XbP03935;
	Tue, 20 Apr 2004 17:33:37 -0700
X-mProtect: <200404210033> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd8zSi1p; Tue, 20 Apr 2004 16:03:28 PDT
Message-ID: <4085AC43.2040904@iprg.nokia.com>
Date: Tue, 20 Apr 2004 16:03:31 -0700
From: Fred 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: Markku Savela <msa@burp.tkv.asdf.org>
CC: karen.e.nielsen@ericsson.com, v6ops@ops.ietf.org, dthaler@microsoft.com,
        mohitt@microsoft.com, tgleeson@cisco.com, ftemplin@iprg.nokia.com
Subject: Re: draft-ietf-ngtrans-isatap-21.txt
References: <C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se> <200404202013.i3KKDFaw002116@burp.tkv.asdf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Markku Savela wrote:

>Oh, additional thing: I did make an experimental implementaion based
>on ISATAP-20 draft (or something), which used IPv6 multicast mapped to
>IPv4 multicast (organisation scope).
>  
>
Please note that isatap-20 is now obsoleted by the 4/16/04
draft submission announcements.

Fred
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Tue Apr 20 20:57:29 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12127
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 20:57:28 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BG61h-000LRQ-J5
	for v6ops-data@psg.com; Wed, 21 Apr 2004 00:55:45 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BG61e-000LQh-W5
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 00:55:43 +0000
Received: from consulintel02 ([204.244.68.59])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000024421.msg
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 03:02:17 +0200
Message-ID: <19a601c4273c$3beff880$2d44f4cc@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <Pine.LNX.4.44.0404181102370.11614-100000@netcore.fi>
Subject: Re: new I-D - DHCP solution
Date: Tue, 20 Apr 2004 18:01:50 -0700
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 21 Apr 2004 03:02:17 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 204.244.68.59
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 21 Apr 2004 03:02:22 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Pekka,

Thanks for your comments we will take them in consideration for the next review for the document.

Will also make sure that the DHCP cons are clear enough, same as the anycast issues.

It will be very good to have other people looking at this document before we issue a new version.

Regards,
Jordi

----- Original Message -----=20
From: "Pekka Savola" <pekkas@netcore.fi>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Sunday, April 18, 2004 1:30 AM
Subject: Re: new I-D - DHCP solution


> On Fri, 16 Apr 2004, JORDI PALET MARTINEZ wrote:
> > [...] most of the customer
> > networks have their own NAT box, with their own DHCP server, that
> > not necessarily is reading (and getting updated) the ISP DHCP server
> > info (and if this is the case, this router should be also upgraded
> > to support the new DHCP option).
>=20
> Was this stated clearly enough?  This is probably a very good point=20
> that needs to be stated clearly.
>=20
> Either the DHCP server at the NAT box would have to propagate the=20
> option, or the NAT box would have to support IPv6 to create the tunnel=20
> on its own.
>=20
> ...
>=20
> A bit of brainstorming of my own; compared to anycast, DHCP seems to
> have a few tradeoffs:
>=20
> pro-DHCP:
>  + it would only be used when there _is_ guaranteed service, i.e., one=20
> would not have to send the packets to anycast address if there is no=20
> service (whether this is a concern depends on how anycast discovery=20
> would be done, see specific issues w/ anycast below).
>  + DHCP for configuration parameters is a technique for v4 which we're=20
> familiar with already (for the good and bad).
>=20
> pro-anycast:
>  + works also when the provider's DHCP info is not propagated to the
> ultimate user (e.g., due to NAT box)
>  + does not require any implementation which couldn't be done in the=20
> tunnel server system itself, either at DHCP server or DHCP=20
> client software; i.e., no 3rd party dependencies, which is pretty=20
> important
>  + can be reasonably constrained if combined with a DNS lookup, and=20
> anycasting the result. (compare to the discovery mechanism for=20
> ISATAP.)
>=20
> specific issues in anycast which need to be addressed:
>  * it may be undesirable to allocate an interdomain anycast prefix ala=20
> 6to4 for this purpose due to a number of reasons, e.g.:
>   - when there is no service to be offered at all, the search may take=20
> long to terminate, especially if you don't get back=20
> network-unreachable.
>   - there is far less incentive for 3rd parties to provide service=20
> than with 6to4 relays, so the chances of finding a willing tunnel=20
> server with interdomain anycast is pretty slim.
>   - when you move between domains, it might still be easiest if you=20
> were able to use your "home ISP's server".  The ISP could be blocking=20
> that, of course, but esp. if you're authenticated, it should still=20
> work.
>=20
>  * if naycast is not an assigned interdomain anycast prefix, it needs
> to be discovered somehow.  DNS lookup is a strong candidate, but there
> are devils in the details.  This could be a simple "A" query for e.g.,
> tunnel-server.<search-path>, NAPTR query (two roundtrips, extra
> implementation), or whatever.  This would be easily configured
> manually as well.  That would have to be figured out.
>=20
>  * when the user moves from an ISP's network to another (e.g., due to=20
> mobility/roaming), there needs to be some process that notices this=20
> change.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Tue Apr 20 21:45:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14416
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 21:45:22 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BG6lI-00064r-Oo
	for v6ops-data@psg.com; Wed, 21 Apr 2004 01:42:52 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BG6lF-00064P-Vz
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 01:42:50 +0000
Received: from consulintel02 ([204.244.68.59])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000024438.msg
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 03:49:25 +0200
Message-ID: <1a2401c42742$d3d73e00$2d44f4cc@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <200404201950.PAA17972@ietf.org>
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Date: Tue, 20 Apr 2004 18:48:41 -0700
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 21 Apr 2004 03:49:25 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 204.244.68.59
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 21 Apr 2004 03:49:29 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Pekka,

May be I miss in the list something about:
   Notes: 6to4 does not work behind a NAT, so it is not applicable in
   3GPP scenarios, and practically also not applicable in Enterprise
   scenarios

Is not clear to me that the 3GPP deployments will be done with NAT (in the network side, as is clear that the UE will not have NAT ?). May be this requires a clarification or rewording it to differentiate two cases (NAT used in the 3GPP network, or NAT not being used).

For example, today, using GPRS, you get usually a public IPv4 address, and 6to4 is working fine across Europe.

Looking at the latest documents posted in the list, I believe that unman 1.1 can also be realized with a non-authenticated TS, that can be auto-discovered (probably an update of TSP).

Regards,
Jordi

----- Original Message -----=20
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Sent: Tuesday, April 20, 2004 12:50 PM
Subject: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>=20
>=20
> Title : Evaluation of v6ops Tunneling Scenarios and Mechanisms
> Author(s) : P. Savola, J. Soininen
> Filename : draft-savola-v6ops-tunneling-01.txt
> Pages : 16
> Date : 2004-4-20
>=20
> This memo analyses the v6ops scenarios/analysis work (Unmanaged,
> 3GPP, ISP and Enterprise) for their requirements for tunneling
> solutions, and analyses the proposed mechanisms on how they might fit
> in these requirements, and discusses possibilities for choosing
> solution(s).
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
> to change your subscription settings.
>=20
>=20
> 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-savola-v6ops-tunneling-01.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-savola-v6ops-tunneling-01.txt".
>=20
> 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.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Tue Apr 20 22:59:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17943
	for <v6ops-archive@lists.ietf.org>; Tue, 20 Apr 2004 22:59:12 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BG7u2-000NyO-U0
	for v6ops-data@psg.com; Wed, 21 Apr 2004 02:55:58 +0000
Received: from [159.226.39.4] (helo=mail.ict.ac.cn)
	by psg.com with smtp (Exim 4.30; FreeBSD)
	id 1BG7u1-000Nxt-FV
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 02:55:57 +0000
Received: (qmail 12396 invoked from network); 21 Apr 2004 02:49:09 -0000
Received: from unknown (HELO Amy) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 21 Apr 2004 02:49:09 -0000
From: "Liu Min" <liumin@ict.ac.cn>
To: "'JORDI PALET MARTINEZ'" <jordi.palet@consulintel.es>,
        <v6ops@ops.ietf.org>
Subject: RE: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Date: Wed, 21 Apr 2004 10:55:44 +0800
Message-ID: <000601c4274c$23b50480$7774a8c0@Amy>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <1a2401c42742$d3d73e00$2d44f4cc@consulintel.es>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jordi:
Today in China, using GPRS, you always get a private IPv4 address.

> For example, today, using GPRS, you get usually a public IPv4 address,
and 6to4
> is working fine across Europe.

 
 

Best Wishes,
 
Liu Min
Institute of Computing Technology
Chinese Academy of Sciences
Tel: (86-10) 6256 5533-9240 
E-mail: liumin@ict.ac.cn


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf
> Of JORDI PALET MARTINEZ
> Sent: Wednesday, April 21, 2004 9:49 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
> 
> Hi Pekka,
> 
> May be I miss in the list something about:
>    Notes: 6to4 does not work behind a NAT, so it is not applicable in
>    3GPP scenarios, and practically also not applicable in Enterprise
>    scenarios
> 
> Is not clear to me that the 3GPP deployments will be done with NAT (in
the network
> side, as is clear that the UE will not have NAT ?). May be this
requires a
> clarification or rewording it to differentiate two cases (NAT used in
the 3GPP
> network, or NAT not being used).
> 
> For example, today, using GPRS, you get usually a public IPv4 address,
and 6to4
> is working fine across Europe.
> 
> Looking at the latest documents posted in the list, I believe that
unman 1.1
> can also be realized with a non-authenticated TS, that can be
auto-discovered
> (probably an update of TSP).
> 
> Regards,
> Jordi
> 
> ----- Original Message -----
> From: <Internet-Drafts@ietf.org>
> To: <i-d-announce@ietf.org>
> Sent: Tuesday, April 20, 2004 12:50 PM
> Subject: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
> 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> > Title : Evaluation of v6ops Tunneling Scenarios and Mechanisms
> > Author(s) : P. Savola, J. Soininen
> > Filename : draft-savola-v6ops-tunneling-01.txt
> > Pages : 16
> > Date : 2004-4-20
> >
> > This memo analyses the v6ops scenarios/analysis work (Unmanaged,
> > 3GPP, ISP and Enterprise) for their requirements for tunneling
> > solutions, and analyses the proposed mechanisms on how they might
fit
> > in these requirements, and discusses possibilities for choosing
> > solution(s).
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > i-d-announce-request@ietf.org with the word unsubscribe in the body
of the
> message.
> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-savola-v6ops-tunneling-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-savola-v6ops-tunneling-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> 
> 
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged
or
> confidential. The information is intended to be for the use of the
individual(s)
> named above. If you are not the intended recipient be aware that any
disclosure,
> copying, distribution or use of the contents of this information,
including
> attached files, is prohibited.
> 
> 
> 
> 





From owner-v6ops@ops.ietf.org  Wed Apr 21 01:06:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24185
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 01:06:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BG9ti-00044s-Qa
	for v6ops-data@psg.com; Wed, 21 Apr 2004 05:03:46 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BG9th-00044a-0e
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 05:03:45 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3L53hp09725
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 08:03:43 +0300
Date: Wed, 21 Apr 2004 08:03:43 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: I-D ACTION:draft-savola-v6ops-tunneling-01.txt (fwd)
Message-ID: <Pine.LNX.4.44.0404210803170.9629-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.44.0404210803172.9629@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

FYI.  Feedback welcome.

---------- Forwarded message ----------
Date: Tue, 20 Apr 2004 15:50:19 -0400
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-savola-v6ops-tunneling-01.txt

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


	Title		: Evaluation of v6ops Tunneling Scenarios and Mechanisms
	Author(s)	: P. Savola, J. Soininen
	Filename	: draft-savola-v6ops-tunneling-01.txt
	Pages		: 16
	Date		: 2004-4-20
	
This memo analyses the v6ops scenarios/analysis work (Unmanaged,
3GPP, ISP and Enterprise) for their requirements for tunneling
solutions, and analyses the proposed mechanisms on how they might fit
in these requirements, and discusses possibilities for choosing
solution(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-01.txt




From owner-v6ops@ops.ietf.org  Wed Apr 21 01:28:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25908
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 01:28:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGAGA-0007eG-Uo
	for v6ops-data@psg.com; Wed, 21 Apr 2004 05:26:58 +0000
Received: from [203.254.224.25] (helo=mailout2.samsung.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGAG6-0007d4-VY
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 05:26:55 +0000
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0HWI0002B9ST2Q@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed,
 21 Apr 2004 14:26:53 +0900 (KST)
Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25])
 by mailout2.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0HWI002MC9S7A3@mailout2.samsung.com> for v6ops@ops.ietf.org;
 Wed, 21 Apr 2004 14:26:31 +0900 (KST)
Received: from LocalHost ([168.219.202.103])
 by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23
 2003)) with ESMTPA id <0HWI00BQR9S7CE@mmp2.samsung.com> for
 v6ops@ops.ietf.org; Wed, 21 Apr 2004 14:26:31 +0900 (KST)
Date: Wed, 21 Apr 2004 14:26:57 +0900
From: "S. Daniel Park" <soohong.park@samsung.com>
Subject: [I-D ACTION]:draft-daniel-dhc-ipv6in4-opt-03.txt
To: dhcwg@ietf.org
Cc: v6ops@ops.ietf.org
Message-id: <012701c42761$43d9ba70$67cadba8@LocalHost>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: multipart/alternative;
 boundary="Boundary_(ID_E10QJFlnZRJD3Bq0Ae0+qQ)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_50_60,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_E10QJFlnZRJD3Bq0Ae0+qQ)
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT


fyi... comments/feedbacks are highly welcome.


- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

> -----Original Message-----
> From: i-d-announce-admin@ietf.org 
> [mailto:i-d-announce-admin@ietf.org] On Behalf Of 
> Internet-Drafts@ietf.org
> Sent: Wednesday, April 21, 2004 4:49 AM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-daniel-dhc-ipv6in4-opt-03.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: DHCP Option for Configuring IPv6-in-IPv4
Tunnels
> 	Author(s)	: P. Kim, S. Park
> 	Filename	: draft-daniel-dhc-ipv6in4-opt-03.txt
> 	Pages		: 8
> 	Date		: 2004-4-20
> 	
> This document provides a mechanism by which the DHCPv4 
> servers can     
> provide information about the configured IPv6-in-IPv4 tunnel     
> end-points.  The IPv4/IPv6 dual-stack nodes can use this     
> information to set up a configured tunnel to the tunnel end-point     
> to obtain IPv6 connectivity.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-03.txt



--Boundary_(ID_E10QJFlnZRJD3Bq0Ae0+qQ)
Content-type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.4630.0">
<TITLE>[I-D ACTION]:draft-daniel-dhc-ipv6in4-opt-03.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">fyi... comments/feedbacks are highly welcome.</FONT></SPAN>
</P>
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">- Daniel (Soohong Daniel Park)</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">- Mobile Platform Laboratory, SAMSUNG Electronics. </FONT></SPAN>
</P>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; -----Original Message-----</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; From: i-d-announce-admin@ietf.org </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; [</FONT></SPAN><A HREF="mailto:i-d-announce-admin@ietf.org"><SPAN LANG="ko"><U><FONT COLOR="#0000FF" SIZE=2 FACE="&#44404;&#47548;">mailto:i-d-announce-admin@ietf.org</FONT></U></SPAN></A><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">] On Behalf Of </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; Internet-Drafts@ietf.org</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; Sent: Wednesday, April 21, 2004 4:49 AM</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; To: i-d-announce@ietf.org</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; Subject: I-D ACTION:draft-daniel-dhc-ipv6in4-opt-03.txt</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; A New Internet-Draft is available from the on-line </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; Internet-Drafts directories.</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : DHCP Option for Configuring IPv6-in-IPv4 Tunnels</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : P. Kim, S. Park</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : draft-daniel-dhc-ipv6in4-opt-03.txt</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 8</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2004-4-20</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; This document provides a mechanism by which the DHCPv4 </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; servers can&nbsp;&nbsp;&nbsp;&nbsp; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; provide information about the configured IPv6-in-IPv4 tunnel&nbsp;&nbsp;&nbsp;&nbsp; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; end-points.&nbsp; The IPv4/IPv6 dual-stack nodes can use this&nbsp;&nbsp;&nbsp;&nbsp; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; information to set up a configured tunnel to the tunnel end-point&nbsp;&nbsp;&nbsp;&nbsp; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; to obtain IPv6 connectivity.</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; </FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; A URL for this Internet-Draft is:</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">&gt; </FONT></SPAN><A HREF="http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-03.txt"><SPAN LANG="ko"><U><FONT COLOR="#0000FF" SIZE=2 FACE="&#44404;&#47548;">http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-03.txt</FONT></U></SPAN></A><SPAN LANG="ko"></SPAN>
</P>
<BR>

</BODY>
</HTML>

--Boundary_(ID_E10QJFlnZRJD3Bq0Ae0+qQ)--



From owner-v6ops@ops.ietf.org  Wed Apr 21 02:46:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28525
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 02:46:30 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGBT5-000O70-K1
	for v6ops-data@psg.com; Wed, 21 Apr 2004 06:44:23 +0000
Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGBT4-000O6g-8p
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 06:44:22 +0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3L6iLPk137638
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 06:44:21 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3L6iKDS067396
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 08:44:20 +0200
Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id IAA62268
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 08:44:18 +0200
Message-ID: <4086184F.E9820672@zurich.ibm.com>
Date: Wed, 21 Apr 2004 08:44:31 +0200
From: Brian E Carpenter <brc@zurich.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: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D ACTION:draft-palet-v6ops-tun-auto-disc-00.txt
References: <200404161936.PAA01018@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

A couple of points..

In section 3 (possible solutions) I am surprised that you don't include
SLP. That is the IETF's discovery protocol, after all, and should be
discussed. Why can't we use SLP to find tunnel servers?

Section 4 puzzles me. My understanding is that anycast is best
if used in single-shot mode: send an anycast UDP packet, pick one of
the replies, and then use unicast to establish a session with the host 
that sent that reply. You won't use the anycast address again after
that initial discovery packet. It's the same as the initial broadcast
in DHCP or the initial multicast in SLP. 

Admittedly, that's not the model in RFC 3068 (Anycast for 6to4). But 6to4
is a special case, since there is no tunnel negotiation.

   Brian

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt



From owner-v6ops@ops.ietf.org  Wed Apr 21 03:15:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29860
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 03:15:12 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGBus-0004BM-Uh
	for v6ops-data@psg.com; Wed, 21 Apr 2004 07:13:06 +0000
Received: from [131.228.20.26] (helo=mgw-x3.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGBur-0004B5-Nd
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 07:13:05 +0000
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L7D4m05942;
	Wed, 21 Apr 2004 10:13:04 +0300 (EET DST)
X-Scanned: Wed, 21 Apr 2004 10:11:01 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3L7B1v9001519;
	Wed, 21 Apr 2004 10:11:01 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00Fqz0M8; Wed, 21 Apr 2004 10:11:00 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L7A5s21040;
	Wed, 21 Apr 2004 10:10:05 +0300 (EET DST)
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 21 Apr 2004 10:09:41 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Date: Wed, 21 Apr 2004 10:05:15 +0300
Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE300@esebe005.ntc.nokia.com>
Thread-Topic: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
thread-index: AcQnQtocnP1aCaQwTMW+f2A5qF+03gAK0G1g
From: <juha.wiljakka@nokia.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 21 Apr 2004 07:09:41.0339 (UTC) FILETIME=[9DAC62B0:01C4276F]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jordi,

That depends on the operator. Which operator are you using?

According to my understanding, most 3GPP operators are allocating =
private IPv4 addresses to the UEs. It means that NAT is necessary if =
services in the public Internet are used.

(And there are certainly no NATs in the UEs.)

BR,
	-Juha-

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext JORDI PALET MARTINEZ
Sent: 21 April, 2004 04:49
To: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


Hi Pekka,

May be I miss in the list something about:
   Notes: 6to4 does not work behind a NAT, so it is not applicable in
   3GPP scenarios, and practically also not applicable in Enterprise
   scenarios

Is not clear to me that the 3GPP deployments will be done with NAT (in =
the network side, as is clear that the UE will not have NAT ?). May be =
this requires a clarification or rewording it to differentiate two cases =
(NAT used in the 3GPP network, or NAT not being used).

For example, today, using GPRS, you get usually a public IPv4 address, =
and 6to4 is working fine across Europe.

Looking at the latest documents posted in the list, I believe that unman =
1.1 can also be realized with a non-authenticated TS, that can be =
auto-discovered (probably an update of TSP).

Regards,
Jordi

----- Original Message -----=20
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Sent: Tuesday, April 20, 2004 12:50 PM
Subject: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
> Title : Evaluation of v6ops Tunneling Scenarios and Mechanisms
> Author(s) : P. Savola, J. Soininen
> Filename : draft-savola-v6ops-tunneling-01.txt
> Pages : 16
> Date : 2004-4-20
>=20
> This memo analyses the v6ops scenarios/analysis work (Unmanaged,
> 3GPP, ISP and Enterprise) for their requirements for tunneling
> solutions, and analyses the proposed mechanisms on how they might fit
> in these requirements, and discusses possibilities for choosing
> solution(s).
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce =

> to change your subscription settings.
>=20
>=20
> 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-savola-v6ops-tunneling-01.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-savola-v6ops-tunneling-01.txt".
>=20
> 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.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or =
confidential. The information is intended to be for the use of the =
individual(s) named above. If you are not the intended recipient be =
aware that any disclosure, copying, distribution or use of the contents =
of this information, including attached files, is prohibited.







From owner-v6ops@ops.ietf.org  Wed Apr 21 03:24:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00264
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 03:24:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGC4A-0005kP-HE
	for v6ops-data@psg.com; Wed, 21 Apr 2004 07:22:42 +0000
Received: from [195.64.92.136] (helo=purgatory.unfix.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGC47-0005k4-VJ
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 07:22:40 +0000
Received: from localhost (localhost [127.0.0.1])
	by purgatory.unfix.org (Postfix) with ESMTP
	id 31AF27FAB; Wed, 21 Apr 2004 09:22:37 +0200 (CEST)
Received: from purgatory.unfix.org ([127.0.0.1])
	by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id 23589-24; Wed, 21 Apr 2004 09:22:27 +0200 (CEST)
Received: from dhcp70-109.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP
	id 46BED7FAA; Wed, 21 Apr 2004 09:22:27 +0200 (CEST)
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
From: Jeroen Massar <jeroen@unfix.org>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Cc: v6ops@ops.ietf.org
In-Reply-To: <1a2401c42742$d3d73e00$2d44f4cc@consulintel.es>
References: <200404201950.PAA17972@ietf.org>
	 <1a2401c42742$d3d73e00$2d44f4cc@consulintel.es>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ycvCqrevAnA5mBVme8Jf"
Organization: Unfix
Message-Id: <1082532144.12285.20.camel@segesta.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 21 Apr 2004 09:22:25 +0200
X-Virus-Scanned: purgatory.unfix.org - http://unfix.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-ycvCqrevAnA5mBVme8Jf
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-04-21 at 03:48, JORDI PALET MARTINEZ wrote:
> Hi Pekka,
>=20
> May be I miss in the list something about:
>    Notes: 6to4 does not work behind a NAT, so it is not applicable in
>    3GPP scenarios, and practically also not applicable in Enterprise
>    scenarios

6to4 does work behind a NAT, though depending on the setup:

Situation #1:

[Internet] --- [gw + NAT + 6to4 relay]
                         |
    [2002:aabb:ccdd::/48 RA'd to internal NATted network]

Thus the NAT box does the 6to4 relay, does require the NAT box to do
6to4. Same setup can be done with a tunnel on the NAT box of course.

Situation #2:

[Internet] -- [gw + NAT]
                  |
    [2002:<rfc1918>::/48 on internal NATted network]
    [thus multiple boxes acting as relays as they all]
    [have their own IP address]

The problem with this situation though is that one will not get global
connectivity but the 6to4 stuff will work between the hosts behind the
NAT. Notez bien that afaik XP etc won't allow rfc1918 usage in 6to4
prefixes...

----
5.  Conclusions
<SNIP>
   There seems to be clear need for a tunnel server protocol which is
   able to traverse NATs and work with dynamic IPv4 addresses.  This
   tunnel server should be able to automatically discover the server
   address if the service is provided by the ISP.
-----

The next step ;)

Greets,
 Jeroen


--=-ycvCqrevAnA5mBVme8Jf
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBAhiEwKaooUjM+fCMRAk89AKCcN5085xkJlS8SnT+Pn3uC1mjutwCgtxJX
f3wwj/pDi7wuTD0wb6UyJ7Q=
=b+ym
-----END PGP SIGNATURE-----

--=-ycvCqrevAnA5mBVme8Jf--




From owner-v6ops@ops.ietf.org  Wed Apr 21 04:13:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02812
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 04:13:06 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGCoN-000HHk-QO
	for v6ops-data@psg.com; Wed, 21 Apr 2004 08:10:27 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGCoL-000HFT-UD
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 08:10:26 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3L8AL413012;
	Wed, 21 Apr 2004 11:10:23 +0300
Date: Wed, 21 Apr 2004 11:10:21 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian E Carpenter <brc@zurich.ibm.com>
cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D ACTION:draft-palet-v6ops-tun-auto-disc-00.txt
In-Reply-To: <4086184F.E9820672@zurich.ibm.com>
Message-ID: <Pine.LNX.4.44.0404211106130.12933-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 21 Apr 2004, Brian E Carpenter wrote:
> Section 4 puzzles me. My understanding is that anycast is best
> if used in single-shot mode: send an anycast UDP packet, pick one of
> the replies, and then use unicast to establish a session with the host 
> that sent that reply. You won't use the anycast address again after
> that initial discovery packet. It's the same as the initial broadcast
> in DHCP or the initial multicast in SLP. 
> 
> Admittedly, that's not the model in RFC 3068 (Anycast for 6to4). But 6to4
> is a special case, since there is no tunnel negotiation.

Shared-unicast DNS root servers and other load-balanced services also 
use the similar technique as 6to4.

I.e., when you just use one address, it's closest to you whereever you 
roam in the network where there are multiple anycasting servers.

Obviously, this only works if you don't need to store state in the
anycast server, or if it's OK to lose the state if the routing changes
or you move.

There doesn't have to be stored state if the IPv4 address is embedded
completely or encoded in a reversible fashion in the IPv6 address.

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




From owner-v6ops@ops.ietf.org  Wed Apr 21 04:49:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04691
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 04:49:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGDO1-000ObP-Sq
	for v6ops-data@psg.com; Wed, 21 Apr 2004 08:47:17 +0000
Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGDNz-000OaY-Pv
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 08:47:15 +0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3L8l8YO068940;
	Wed, 21 Apr 2004 08:47:08 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3L8l6DS070638;
	Wed, 21 Apr 2004 10:47:07 +0200
Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id KAA43908;
	Wed, 21 Apr 2004 10:47:04 +0200
Message-ID: <40863514.EE2DF66D@zurich.ibm.com>
Date: Wed, 21 Apr 2004 10:47:16 +0200
From: Brian E Carpenter <brc@zurich.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: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D ACTION:draft-palet-v6ops-tun-auto-disc-00.txt
References: <Pine.LNX.4.44.0404211106130.12933-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka Savola wrote:
> 
> On Wed, 21 Apr 2004, Brian E Carpenter wrote:
> > Section 4 puzzles me. My understanding is that anycast is best
> > if used in single-shot mode: send an anycast UDP packet, pick one of
> > the replies, and then use unicast to establish a session with the host
> > that sent that reply. You won't use the anycast address again after
> > that initial discovery packet. It's the same as the initial broadcast
> > in DHCP or the initial multicast in SLP.
> >
> > Admittedly, that's not the model in RFC 3068 (Anycast for 6to4). But 6to4
> > is a special case, since there is no tunnel negotiation.
> 
> Shared-unicast DNS root servers and other load-balanced services also
> use the similar technique as 6to4.
> 
> I.e., when you just use one address, it's closest to you whereever you
> roam in the network where there are multiple anycasting servers.
> 
> Obviously, this only works if you don't need to store state in the
> anycast server, or if it's OK to lose the state if the routing changes
> or you move.
> 
> There doesn't have to be stored state if the IPv4 address is embedded
> completely or encoded in a reversible fashion in the IPv6 address.

Which isn't the case in configured tunnels, hence my puzzlement at why
we would do it this way.

   Brian



From owner-v6ops@ops.ietf.org  Wed Apr 21 05:21:29 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06023
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 05:21:29 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGDso-0006F6-0l
	for v6ops-data@psg.com; Wed, 21 Apr 2004 09:19:06 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGDsm-0006Eq-Jg
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 09:19:04 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3L9Iwd14016;
	Wed, 21 Apr 2004 12:18:58 +0300
Date: Wed, 21 Apr 2004 12:18:58 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Jeroen Massar <jeroen@unfix.org>
cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
In-Reply-To: <1082532144.12285.20.camel@segesta.zurich.ibm.com>
Message-ID: <Pine.LNX.4.44.0404211111090.12933-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On 21 Apr 2004, Jeroen Massar wrote:
> 6to4 does work behind a NAT, though depending on the setup:
> 
> Situation #1:
> 
> [Internet] --- [gw + NAT + 6to4 relay]
>                          |
>     [2002:aabb:ccdd::/48 RA'd to internal NATted network]
> 
> Thus the NAT box does the 6to4 relay, does require the NAT box to do
> 6to4. Same setup can be done with a tunnel on the NAT box of course.

Obviously yes, but we're talking about the setups where upgrading NAT 
box is not possible.

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





From owner-v6ops@ops.ietf.org  Wed Apr 21 05:32:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06804
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 05:32:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGE4h-0008Wz-ID
	for v6ops-data@psg.com; Wed, 21 Apr 2004 09:31:23 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGE4f-0008Ue-WA
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 09:31:22 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3L9VHe14228;
	Wed, 21 Apr 2004 12:31:19 +0300
Date: Wed, 21 Apr 2004 12:31:17 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian E Carpenter <brc@zurich.ibm.com>
cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D ACTION:draft-palet-v6ops-tun-auto-disc-00.txt
In-Reply-To: <40863514.EE2DF66D@zurich.ibm.com>
Message-ID: <Pine.LNX.4.44.0404211226320.14010-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 21 Apr 2004, Brian E Carpenter wrote:
> Pekka Savola wrote:
[...]
> > There doesn't have to be stored state if the IPv4 address is embedded
> > completely or encoded in a reversible fashion in the IPv6 address.
> 
> Which isn't the case in configured tunnels, hence my puzzlement at why
> we would do it this way.

I general, exactly; this would have problems.

In specific, there has been discussion of different tunnel server
models (e.g., see Alains requirements document).  It could be very
simple to figure out a solution which would give a user an IPv6 /128
address which would embed the topographical v4 address (similar but
simpler compared to e.g. what one could do with ISATAP).

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




From owner-v6ops@ops.ietf.org  Wed Apr 21 07:23:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12594
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 07:23:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGFld-000Abj-Uf
	for v6ops-data@psg.com; Wed, 21 Apr 2004 11:19:49 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGFlc-000AbL-87; Wed, 21 Apr 2004 11:19:48 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3LBJij15948;
	Wed, 21 Apr 2004 14:19:44 +0300
Date: Wed, 21 Apr 2004 14:19:44 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: juha.wiljakka@nokia.com
cc: v6ops@ops.ietf.org, <mankin@psg.com>, <jon.peterson@neustar.biz>,
        <Jonne.Soininen@nokia.com>, <david.kessens@nokia.com>
Subject: Re: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS
 Scenario 1
In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE2FA@esebe005.ntc.nokia.com>
Message-ID: <Pine.LNX.4.44.0404211353400.14563-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Feedback is sought from the WG -- see below..

On Tue, 20 Apr 2004 juha.wiljakka@nokia.com wrote:
[...]
> I fully agree that we need a referral with a deadline for the
> SIP/SDP community, and we could use stronger wording than we have in
> -09 (would a good deadline be by the end of this year?). It is clear
> that we leave the closer details of the solution to be specified by
> the SIPpish wgs - specifying new mechanisms is out of the scope of
> this document. The current text says:
> 
>    "This section presents higher level details of a solution based on 
>     the use of a translator and SIP ALG. [3GPPtr] provides additional 
>     information and presents a bit different solution proposal based on 
>     SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to 
>     solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF 
>     SIP wg(s)."
> 
> Removal of [3GPPtr] informative reference is needed?
> 
> I understand that rewriting SDP is one of your concerns. But would
> it be acceptable in cases when a solution is needed, and there is no
> other way around to solve the problem? 

Clarification: do you mean, "no other way around to solve the problem 
_at the moment_"?

Note that such interop is not required when you communicate between
3GPP boxes as no translation is needed, just externals -- this might
not be the number one critical problem (not sure), so if we were able 
to find (or even publish) a solution before the year's end (for 
example), it might be good enough.

> We could state in the draft
> that alternative mechanisms will be developed in the future to solve
> the problem in some other way than rewriting the SDP, and when those
> mechanisms will be available, SDP rewriting should not be applied
> any more. And write text on the problems with rewriting SDP.
>
> Anyway, I wouldn't like to remove all details in section 4.1,
> because that would make our document less useful.
>
> Comments on the mailing list are more than welcome!

(co-chair hat on)
 
My understanding of Allison's concern was that the document goes on
too much depth describing a particular solution (or a class of
solutions), while this solution has a number of big problems, and
another approach would be better .. but the details of the approach 
would have to be worked out (in very short order).

So, if we agree with that that view, the options would appear to be 
like:

 1) describe the problems with currently proposed mechanisms, and 
    recommend against using them (if already being used) after a 
    better solution is found.  This has a problem that undeploying 
    stuff is very difficult, and if it's already out there, giving 
    IETF "blessing" to a temporary deployment may not be a good idea.
    (This may not clear Allison's Discuss.)

 2) just describe the problem, and get the balls rolling quickly to 
    find the good solution. The problem with this is that it 
    doesn't give any idea about what kind of solution that would be.
 
    2.a) include the justification why currently proposed mechanisms 
         are not good.

    2.b) omit the discussion.

 3) describe the problem, and try to give very high view details of
    a potential solution (e.g., as Allison already stated), and get 
    the balls rolling quickly to find the solution.  The problem with 
    this is that as the details are not yet clear, it might be 
    inappropriate to just describe a sketch here, as it could change 
    still.

    3.a) include the justification why currently proposed mechanisms
         are not good.
                                                                                                
    3.b) omit the discussion.

 4) delay this document until work has gone further.  That is, there 
    are a number generic suggestions, lacking the specifics.  Maybe 
    this is an indicator that we should try to work out more details 
    of the approaches first, and only publish the document when it has 
    enough details to be (more) useful.  The problem with this is that it
    delays the publication for parts which would already be considered 
    useful.

Is this a reasonably good representation of the possibilities? 

Thoughts on the way forward?  Send them on the list by next Tuesday,
27 April (at the latest).

Thanks!

(co-chair hat off)

(By the way, I wrote "get the ball rolling" -- but I'm REALLY, really 
hoping that the ball would already be going down the slope...)







From owner-v6ops@ops.ietf.org  Wed Apr 21 10:10:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22954
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 10:10:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGIMg-000NYH-HP
	for v6ops-data@psg.com; Wed, 21 Apr 2004 14:06:14 +0000
Received: from [217.32.164.138] (helo=i2kc03-ukbr.domain1.systemhost.net)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGIMd-000NX1-97
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 14:06:11 +0000
Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 21 Apr 2004 15:06:09 +0100
Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 21 Apr 2004 15:06:09 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Date: Wed, 21 Apr 2004 15:06:07 +0100
Message-ID: <0AAF93247C75E3408638B965DEE11A7006EA664B@i2km41-ukdy.domain1.systemhost.net>
Thread-Topic: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Thread-Index: AcQnRA9lDoPRnLZwS6yuXh4Ei44mtwAZZTxw
From: <matthew.ford@bt.com>
To: <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 21 Apr 2004 14:06:09.0846 (UTC) FILETIME=[CBFBF560:01C427A9]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jordi,

> For example, today, using GPRS, you get usually a public IPv4=20
> address, and 6to4 is working fine across Europe.

That is simply not true. GPRS with public IPv4 addressing is the
exception, not the rule.

-- Mat



From owner-v6ops@ops.ietf.org  Wed Apr 21 10:10:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22981
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 10:10:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGIPb-000ObW-3n
	for v6ops-data@psg.com; Wed, 21 Apr 2004 14:09:15 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGIPY-000OaJ-2U
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 14:09:12 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3LE9AK18648
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 17:09:10 +0300
Date: Wed, 21 Apr 2004 17:09:10 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
Message-ID: <Pine.LNX.4.44.0404211707080.18618-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Folks --

(co-chair hat on)

 Please send further comments on what you think whether this should be 
 a WG item or not, and optionally why you think it should be an item 
 (or not)?  

 Please do this by next Tuesday, April 27.

(co-chair hat off)

FWIW, I don't have strong personal preference either way; I think we
should move forward from the requirements, and if adopting this as a
WG item would help with that -- fine.  But at the same time I don't
think it is _necessary_ to take up something like this as WG item (at
this point), as it's the result of the requirements that we're anxious
to see, get adopted as WG items etc., and not the requirements
themselves..

On Tue, 13 Apr 2004, Alain Durand wrote:
> I would like to request the wg and is chairs to consider
> draft-durand-v6ops-assisted-tunneling-requirements-00.txt
> as a wg item. I have received a number of comments either privately
> and on the ml, I would like to issue a new revision with a 
> draft-ietf-v6ops title.
> 
> 	- Alain.
> 




From owner-v6ops@ops.ietf.org  Wed Apr 21 10:10:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23012
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 10:10:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGIPl-000OeP-AZ
	for v6ops-data@psg.com; Wed, 21 Apr 2004 14:09:25 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGIPe-000OcD-7T
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 14:09:18 +0000
Received: from consulintel02 ([204.244.68.59])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000026437.msg
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 16:15:56 +0200
Message-ID: <1b7701c427ab$1a4c5ec0$2d44f4cc@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <245DBCAEEC4F074CB77B3F984FF9834F020CE300@esebe005.ntc.nokia.com>
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Date: Wed, 21 Apr 2004 07:15:28 -0700
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 21 Apr 2004 16:15:56 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 204.244.68.59
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 21 Apr 2004 16:15:58 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Juha,

Yes, I see that in China, as Lui Min indicated is the same, so clearly depends on the operator. So then is what I said, "May be this requires a clarification or rewording it to differentiate two cases (NAT used in the 3GPP network, or NAT not being used).".

For some reason, I misunderstood in some message in the list that the UE doesn't have a NAT, now is clear ;-)

Regards,
Jordi

----- Original Message -----=20
From: <juha.wiljakka@nokia.com>
To: <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
Sent: Wednesday, April 21, 2004 12:05 AM
Subject: RE: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


Jordi,

That depends on the operator. Which operator are you using?

According to my understanding, most 3GPP operators are allocating private IPv4 addresses to the UEs. It means that NAT is necessary if services in the public Internet are used.

(And there are certainly no NATs in the UEs.)

BR,
-Juha-

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext JORDI PALET MARTINEZ
Sent: 21 April, 2004 04:49
To: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


Hi Pekka,

May be I miss in the list something about:
   Notes: 6to4 does not work behind a NAT, so it is not applicable in
   3GPP scenarios, and practically also not applicable in Enterprise
   scenarios

Is not clear to me that the 3GPP deployments will be done with NAT (in the network side, as is clear that the UE will not have NAT ?). May be this requires a clarification or rewording it to differentiate two cases (NAT used in the 3GPP network, or NAT not being used).

For example, today, using GPRS, you get usually a public IPv4 address, and 6to4 is working fine across Europe.

Looking at the latest documents posted in the list, I believe that unman 1.1 can also be realized with a non-authenticated TS, that can be auto-discovered (probably an update of TSP).

Regards,
Jordi

----- Original Message -----=20
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Sent: Tuesday, April 20, 2004 12:50 PM
Subject: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>=20
>=20
> Title : Evaluation of v6ops Tunneling Scenarios and Mechanisms
> Author(s) : P. Savola, J. Soininen
> Filename : draft-savola-v6ops-tunneling-01.txt
> Pages : 16
> Date : 2004-4-20
>=20
> This memo analyses the v6ops scenarios/analysis work (Unmanaged,
> 3GPP, ISP and Enterprise) for their requirements for tunneling
> solutions, and analyses the proposed mechanisms on how they might fit
> in these requirements, and discusses possibilities for choosing
> solution(s).
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
> to change your subscription settings.
>=20
>=20
> 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-savola-v6ops-tunneling-01.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-savola-v6ops-tunneling-01.txt".
>=20
> 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.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.








**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Wed Apr 21 10:47:48 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25756
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 10:47:47 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGIz0-00068c-M9
	for v6ops-data@psg.com; Wed, 21 Apr 2004 14:45:50 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGIyw-000680-2y
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 14:45:46 +0000
Received: from consulintel02 ([204.244.68.59])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000026598.msg
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 16:52:25 +0200
Message-ID: <1e7b01c427b0$349390f0$2d44f4cc@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <0AAF93247C75E3408638B965DEE11A7006EA664B@i2km41-ukdy.domain1.systemhost.net>
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Date: Wed, 21 Apr 2004 07:51:59 -0700
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 21 Apr 2004 16:52:25 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 204.244.68.59
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 21 Apr 2004 16:52:27 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Mat,

I guess isn't important to discuss it here, but I tried in several European countries, including Spain, and I got public IPv4 addresses and a 6to4 relay working for me ;-) I did nothing special.

My conclusion is that if there are some (even when it could be only an exception), we should consider this case, specially because the situation can change at any time, for any reasons that are not relevant to us (new providers, value added, ...). Right ?

Regards,
Jordi

----- Original Message -----=20
From: <matthew.ford@bt.com>
To: <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Wednesday, April 21, 2004 7:06 AM
Subject: RE: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


Jordi,

> For example, today, using GPRS, you get usually a public IPv4=20
> address, and 6to4 is working fine across Europe.

That is simply not true. GPRS with public IPv4 addressing is the
exception, not the rule.

-- Mat




**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Wed Apr 21 12:58:34 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02073
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 12:58:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGL0E-000Aq1-Nh
	for v6ops-data@psg.com; Wed, 21 Apr 2004 16:55:14 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGL0C-000ApN-9w
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 16:55:12 +0000
Received: from consulintel02 ([204.244.68.50])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000027092.msg
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 19:01:53 +0200
Message-ID: <212301c427c2$4a50e250$2d44f4cc@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Subject: new I-D available: draft-vives-v6ops-ipv6-security-ps-00.txt
Date: Wed, 21 Apr 2004 10:01:27 -0700
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 21 Apr 2004 19:01:53 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 204.244.68.50
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 21 Apr 2004 19:01:53 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi,

While uploaded by RFC editor, we've uploaded a copy of the document at http://www.consulintel.euro6ix.org/ietf/draft-vives-v6ops-ipv6-security-ps-00.txt

Regards,
Jordi





**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Wed Apr 21 12:59:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02128
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 12:59:07 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGL2k-000BUO-3y
	for v6ops-data@psg.com; Wed, 21 Apr 2004 16:57:50 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGL2i-000BU3-Ty
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 16:57:49 +0000
Received: from consulintel02 ([204.244.68.50])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000027098.msg
	for <v6ops@ops.ietf.org>; Wed, 21 Apr 2004 19:04:28 +0200
Message-ID: <214701c427c2$a6a6bb60$2d44f4cc@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Subject: new I-D available: draft-palet-v6ops-auto-trans-00.txt
Date: Wed, 21 Apr 2004 10:04:02 -0700
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Wed, 21 Apr 2004 19:04:28 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 204.244.68.50
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Wed, 21 Apr 2004 19:04:30 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi all,

While uploaded by RFC editor, we've uploaded a copy of the document at http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-auto-trans-00.txt

Regards,
Jordi




**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Wed Apr 21 15:41:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10359
	for <v6ops-archive@lists.ietf.org>; Wed, 21 Apr 2004 15:41:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGNYf-000PRK-KL
	for v6ops-data@psg.com; Wed, 21 Apr 2004 19:38:57 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGNYd-000PQs-Kw
	for v6ops@ops.ietf.org; Wed, 21 Apr 2004 19:38:55 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10111;
	Wed, 21 Apr 2004 15:38:01 -0400 (EDT)
Message-Id: <200404211938.PAA10111@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-isp-scenarios-analysis-02.txt
Date: Wed, 21 Apr 2004 15:38:01 -0400
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--NextPart

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

	Title		: Scenarios and Analysis for Introducing IPv6
			  into ISP Networks
	Author(s)	: M. Lind, et al.
	Filename	: draft-ietf-v6ops-isp-scenarios-analysis-02.txt
	Pages		: 26
	Date		: 2004-4-21
	
This document first describes different scenarios for the 
introduction of IPv6 into an existing IPv4 ISP network without 
disrupting the IPv4 service. Then, this document analyses these 
scenarios and evaluates the suitability of the already defined 
transition mechanisms in this context. Known challenges are also 
identified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-02.txt

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


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-isp-scenarios-analysis-02.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-isp-scenarios-analysis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--





From owner-v6ops@ops.ietf.org  Thu Apr 22 00:31:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15604
	for <v6ops-archive@lists.ietf.org>; Thu, 22 Apr 2004 00:31:26 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGVof-000I2K-Lh
	for v6ops-data@psg.com; Thu, 22 Apr 2004 04:28:01 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGVoe-000I1m-8B
	for v6ops@ops.ietf.org; Thu, 22 Apr 2004 04:28:00 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3M4Rwg32166;
	Thu, 22 Apr 2004 07:27:58 +0300
Date: Thu, 22 Apr 2004 07:27:58 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
cc: jonne.soininen@nokia.com, <mikael.lind@teliasonera.com>
Subject: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-02.txt
Message-ID: <Pine.LNX.4.44.0404220726021.31988-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi all,

(co-chair hat on)

This is the second WG Last Call for comments on sending
draft-ietf-v6ops-isp-scenarios-analysis-02.txt, " Scenarios and
Analysis for Introducing IPv6 into ISP Networks" to the IESG for
consideration as BCP:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-02.txt

Please review these documents carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this document
is ready to go to the IESG.

The last call will end in about 1 week, on 28th April.

Thanks!





From owner-v6ops@ops.ietf.org  Thu Apr 22 09:58:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27227
	for <v6ops-archive@lists.ietf.org>; Thu, 22 Apr 2004 09:58:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGefc-000L4q-ID
	for v6ops-data@psg.com; Thu, 22 Apr 2004 13:55:16 +0000
Received: from [131.228.20.26] (helo=mgw-x3.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGefa-000L3s-SD
	for v6ops@ops.ietf.org; Thu, 22 Apr 2004 13:55:15 +0000
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MDtDG21567;
	Thu, 22 Apr 2004 16:55:13 +0300 (EET DST)
X-Scanned: Thu, 22 Apr 2004 16:52:18 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3MDqIUK006102;
	Thu, 22 Apr 2004 16:52:18 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00zdosFt; Thu, 22 Apr 2004 16:52:17 EEST
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MDq2F15712;
	Thu, 22 Apr 2004 16:52:02 +0300 (EET DST)
Received: from essat-vlan154-2-22428.ntc.nokia.com ([172.21.224.28]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 22 Apr 2004 16:52:01 +0300
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
From: Jonne Soininen <jonne.soininen@nokia.com>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Cc: v6ops@ops.ietf.org
In-Reply-To: <1e7b01c427b0$349390f0$2d44f4cc@consulintel.es>
References: 
	 <0AAF93247C75E3408638B965DEE11A7006EA664B@i2km41-ukdy.domain1.systemhost.net>
	 <1e7b01c427b0$349390f0$2d44f4cc@consulintel.es>
Content-Type: text/plain
Message-Id: <1082641920.2539.54.camel@essat-vlan154-2-22428.ntc.nokia.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 22 Apr 2004 16:52:01 +0300
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Apr 2004 13:52:01.0479 (UTC) FILETIME=[FCBB2D70:01C42870]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jordi,
you might be in different networks (roaming), but getting the service
from your own operator always. Did you check the IP address from whois?
It may be and most probably is that you always use your home GGSN.

BTW, lucky you if you get a public IP address. I wish that would be the
rule, not the exception!

Cheers,

Jonne.

On Wed, 2004-04-21 at 17:51, ext JORDI PALET MARTINEZ wrote:
> Mat,
> 
> I guess isn't important to discuss it here, but I tried in several European countries, including Spain, and I got public IPv4 addresses and a 6to4 relay working for me ;-) I did nothing special.
> 
> My conclusion is that if there are some (even when it could be only an exception), we should consider this case, specially because the situation can change at any time, for any reasons that are not relevant to us (new providers, value added, ...). Right ?
> 
> Regards,
> Jordi
> 
> ----- Original Message ----- 
> From: <matthew.ford@bt.com>
> To: <jordi.palet@consulintel.es>
> Cc: <v6ops@ops.ietf.org>
> Sent: Wednesday, April 21, 2004 7:06 AM
> Subject: RE: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
> 
> 
> Jordi,
> 
> > For example, today, using GPRS, you get usually a public IPv4 
> > address, and 6to4 is working fine across Europe.
> 
> That is simply not true. GPRS with public IPv4 addressing is the
> exception, not the rule.
> 
> -- Mat
> 
> 
> 
> 
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> 




From owner-v6ops@ops.ietf.org  Thu Apr 22 10:43:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01422
	for <v6ops-archive@lists.ietf.org>; Thu, 22 Apr 2004 10:43:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGfNO-0003BI-Ij
	for v6ops-data@psg.com; Thu, 22 Apr 2004 14:40:30 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGfND-000394-Uz
	for v6ops@ops.ietf.org; Thu, 22 Apr 2004 14:40:20 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000030181.msg
	for <v6ops@ops.ietf.org>; Thu, 22 Apr 2004 16:47:00 +0200
Message-ID: <065701c42878$991cbb00$640a0a0a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <0AAF93247C75E3408638B965DEE11A7006EA664B@i2km41-ukdy.domain1.systemhost.net> <1e7b01c427b0$349390f0$2d44f4cc@consulintel.es> <1082641920.2539.54.camel@essat-vlan154-2-22428.ntc.nokia.com>
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
Date: Thu, 22 Apr 2004 16:46:17 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Thu, 22 Apr 2004 16:47:00 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Thu, 22 Apr 2004 16:47:02 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Jonne,

The IP address was from different LIRs, I confirmed that in 3 occasions, so its not only one operator always ;-)

Regards,
Jordi

PS: Remember that I'm talking about GPRS, but as said, in my opinion, our documents should consider both posibilities (NAT and public address, in 3G).

----- Original Message -----=20
From: "Jonne Soininen" <jonne.soininen@nokia.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Thursday, April 22, 2004 3:52 PM
Subject: Re: I-D ACTION:draft-savola-v6ops-tunneling-01.txt


> Jordi,
> you might be in different networks (roaming), but getting the service
> from your own operator always. Did you check the IP address from whois?
> It may be and most probably is that you always use your home GGSN.
>=20
> BTW, lucky you if you get a public IP address. I wish that would be the
> rule, not the exception!
>=20
> Cheers,
>=20
> Jonne.
>=20
> On Wed, 2004-04-21 at 17:51, ext JORDI PALET MARTINEZ wrote:
> > Mat,
> >=20
> > I guess isn't important to discuss it here, but I tried in several European countries, including Spain, and I got public IPv4 addresses and a 6to4 relay working for me ;-) I did nothing special.
> >=20
> > My conclusion is that if there are some (even when it could be only an exception), we should consider this case, specially because the situation can change at any time, for any reasons that are not relevant to us (new providers, value added, ...). Right ?
> >=20
> > Regards,
> > Jordi
> >=20
> > ----- Original Message -----=20
> > From: <matthew.ford@bt.com>
> > To: <jordi.palet@consulintel.es>
> > Cc: <v6ops@ops.ietf.org>
> > Sent: Wednesday, April 21, 2004 7:06 AM
> > Subject: RE: I-D ACTION:draft-savola-v6ops-tunneling-01.txt
> >=20
> >=20
> > Jordi,
> >=20
> > > For example, today, using GPRS, you get usually a public IPv4=20
> > > address, and 6to4 is working fine across Europe.
> >=20
> > That is simply not true. GPRS with public IPv4 addressing is the
> > exception, not the rule.
> >=20
> > -- Mat
> >=20
> >=20
> >=20
> >=20
> > **********************************
> > Madrid 2003 Global IPv6 Summit
> > Presentations and videos on line at:
> > http://www.ipv6-es.com
> >=20
> > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Thu Apr 22 15:13:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19544
	for <v6ops-archive@lists.ietf.org>; Thu, 22 Apr 2004 15:13:08 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BGja2-0006t4-DU
	for v6ops-data@psg.com; Thu, 22 Apr 2004 19:09:50 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BGja1-0006sI-D7
	for v6ops@ops.ietf.org; Thu, 22 Apr 2004 19:09:49 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3MJ9UO31289;
	Thu, 22 Apr 2004 12:09:30 -0700
X-mProtect: <200404221909> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdlkKTyh; Thu, 22 Apr 2004 12:09:28 PDT
Message-ID: <40881876.8050104@iprg.nokia.com>
Date: Thu, 22 Apr 2004 12:09:42 -0700
From: Fred 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: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>,
        "'Markku Savela'"
 <msa@burp.tkv.asdf.org>
CC: v6ops@ops.ietf.org, dthaler@microsoft.com, mohitt@microsoft.com,
        tgleeson@cisco.com, ftemplin@iprg.nokia.com
Subject: Re: draft-ietf-ngtrans-isatap-21.txt
References: <C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Karen and Markku,

Thank you for your comments on the isatap-21 draft; they
have been added to the ISATAP Issue Tracker page at:

   www.geocities.com/osprey67/isatap/isatap_issues.htm

Fred Templin (for the ISATAP co-authors)
ftemplin@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Fri Apr 23 09:07:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04542
	for <v6ops-archive@lists.ietf.org>; Fri, 23 Apr 2004 09:07:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BH0LA-000HHz-Et
	for v6ops-data@psg.com; Fri, 23 Apr 2004 13:03:36 +0000
Received: from [203.254.224.33] (helo=mailout3.samsung.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BH0L8-000HHN-FO
	for v6ops@ops.ietf.org; Fri, 23 Apr 2004 13:03:34 +0000
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0HWM00101K9WP7@mailout3.samsung.com> for v6ops@ops.ietf.org; Fri,
 23 Apr 2004 22:03:32 +0900 (KST)
Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33])
 by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0HWM009QTK9WQS@mailout3.samsung.com> for v6ops@ops.ietf.org;
 Fri, 23 Apr 2004 22:03:32 +0900 (KST)
Received: from LocalHost ([168.219.202.103])
 by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23
 2003)) with ESMTPA id <0HWM00DXPK9WYO@mmp2.samsung.com> for
 v6ops@ops.ietf.org; Fri, 23 Apr 2004 22:03:32 +0900 (KST)
Date: Fri, 23 Apr 2004 22:03:59 +0900
From: "S. Daniel Park" <soohong.park@samsung.com>
Subject: RE: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
In-reply-to: <Pine.LNX.4.44.0404211707080.18618-100000@netcore.fi>
To: "'Pekka Savola'" <pekkas@netcore.fi>, v6ops@ops.ietf.org
Cc: Alain.Durand@Sun.COM
Message-id: <010601c42933$711bba50$67cadba8@LocalHost>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: multipart/alternative;
 boundary="Boundary_(ID_QkaHzLylnnj1tfOllC9qBg)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE 
	autolearn=ham version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_QkaHzLylnnj1tfOllC9qBg)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT


This draft looks good for me and
I second it should be an WG item. 

==========
One question:

4.1 Address Allocation

Why did you restrict the prefix length as /128 ?
Prefix delegation is not considered in this manner ?
In non-authenticated mode, prefix (maybe /64) can
be delegated to its customers IMHO.


==========
with minor editorial comments.


2. Applicability
Althought the main focus of this document is the ISP scenario,
s/Althought/Although


4.4 Security Threat Analysis
The un-authenticated mode relies on out of band authentication.
s/un-/non- (?)


6.8 Phase Out
connecting a customer, there is no reason to keep using tunnels. So
the tunnel-setup protocol must have a provision to enable the ISP to
signal the user to use native IPv6 instead.
s/tunnel-setup protocol/tunnel set-up protocol


- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 


--Boundary_(ID_QkaHzLylnnj1tfOllC9qBg)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.4630.0">
<TITLE>RE: draft-durand-v6ops-assisted-tunneling-requirements-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">This draft looks good for me and</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">I second it should be an WG item. </FONT></SPAN>
</P>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">==========</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">One question:</FONT></SPAN>
</P>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">4.1 Address Allocation</FONT></SPAN>
</P>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">Why did you restrict the prefix length as /128 ?</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">Prefix delegation is not considered in this manner ?</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">In non-authenticated mode, prefix (maybe /64) can</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">be delegated to its customers IMHO.</FONT></SPAN>
</P>
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">==========</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">with minor editorial comments.</FONT></SPAN>
</P>
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">2. Applicability</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">Althought the main focus of this document is the ISP scenario,</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">s/Althought/Although</FONT></SPAN>
</P>
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">4.4 Security Threat Analysis</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">The un-authenticated mode relies on out of band authentication.</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">s/un-/non- (?)</FONT></SPAN>
</P>
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">6.8 Phase Out</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">connecting a customer, there is no reason to keep using tunnels. So</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">the tunnel-setup protocol must have a provision to enable the ISP to</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">signal the user to use native IPv6 instead.</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">s/tunnel-setup protocol/tunnel set-up protocol</FONT></SPAN>
</P>
<BR>

<P><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">- Daniel (Soohong Daniel Park)</FONT></SPAN>

<BR><SPAN LANG="ko"><FONT SIZE=2 FACE="&#44404;&#47548;">- Mobile Platform Laboratory, SAMSUNG Electronics. </FONT></SPAN>
</P>

</BODY>
</HTML>

--Boundary_(ID_QkaHzLylnnj1tfOllC9qBg)--



From owner-v6ops@ops.ietf.org  Fri Apr 23 17:42:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15023
	for <v6ops-archive@lists.ietf.org>; Fri, 23 Apr 2004 17:42:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BH8Mt-000HRW-5R
	for v6ops-data@psg.com; Fri, 23 Apr 2004 21:37:55 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BH8Ms-000HQn-0C
	for v6ops@ops.ietf.org; Fri, 23 Apr 2004 21:37:54 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3NLbrdc009508
	for <v6ops@ops.ietf.org>; Fri, 23 Apr 2004 15:37:53 -0600 (MDT)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HWN00I98834RD@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 23 Apr 2004 15:37:53 -0600 (MDT)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HWN00CRY833E1@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 23 Apr 2004 15:37:52 -0600 (MDT)
Date: Fri, 23 Apr 2004 14:37:49 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
In-reply-to: <010601c42933$711bba50$67cadba8@LocalHost>
To: "S. Daniel Park" <soohong.park@samsung.com>
Cc: "'Pekka Savola'" <pekkas@netcore.fi>, v6ops@ops.ietf.org
Message-id: <77DC1D1A-956E-11D8-A499-00039358A080@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_rDULx5DQl1XCF4v5ZK2YzA)"
References: <010601c42933$711bba50$67cadba8@LocalHost>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--Boundary_(ID_rDULx5DQl1XCF4v5ZK2YzA)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7BIT


On Apr 23, 2004, at 6:03 AM, S. Daniel Park wrote:

>
>
> This draft looks good for me and
>  I second it should be an WG item.

Thank you for your comments.


>  ==========
>  One question:
>
> 4.1 Address Allocation
>
> Why did you restrict the prefix length as /128 ?
>  Prefix delegation is not considered in this manner ?
>  In non-authenticated mode, prefix (maybe /64) can
>  be delegated to its customers IMHO.

In the current document, /64 prefix allocation is not mandatory.
Our opinion as author was that the non-authenticated mode
was meant to be used in a try-out environment only and
connecting only one node was enough.
In our opinion, any more than that would require authentication.
But this is only one opinion, I would like to get more feedback on this 
point:

Would ISP be willing to deploy IPv6 tunnel service in this 
non-authenticated mode
on production networks?

	- Alain.

--Boundary_(ID_rDULx5DQl1XCF4v5ZK2YzA)
Content-type: text/enriched; charset=US-ASCII
Content-Transfer-Encoding: 7BIT



On Apr 23, 2004, at 6:03 AM, S. Daniel Park wrote:


<excerpt>


<smaller>This draft looks good for me and</smaller> 

 <smaller>I second it should be an WG item.</smaller> 

</excerpt>

Thank you for your comments.



<excerpt> <smaller>==========</smaller> 

 <smaller>One question:</smaller> 


<smaller>4.1 Address Allocation</smaller> 


<smaller>Why did you restrict the prefix length as /128 ?</smaller> 

 <smaller>Prefix delegation is not considered in this manner
?</smaller> 

 <smaller>In non-authenticated mode, prefix (maybe /64) can</smaller> 

 <smaller>be delegated to its customers IMHO.</smaller> 

</excerpt>

In the current document, /64 prefix allocation is not mandatory.

Our opinion as author was that the non-authenticated mode

was meant to be used in a try-out environment only and

connecting only one node was enough.

In our opinion, any more than that would require authentication.

But this is only one opinion, I would like to get more feedback on
this point:


Would ISP be willing to deploy IPv6 tunnel service in this
non-authenticated mode

on production networks?


	- Alain.

--Boundary_(ID_rDULx5DQl1XCF4v5ZK2YzA)--



From owner-v6ops@ops.ietf.org  Fri Apr 23 17:59:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16272
	for <v6ops-archive@lists.ietf.org>; Fri, 23 Apr 2004 17:59:34 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BH8fc-000LbS-NO
	for v6ops-data@psg.com; Fri, 23 Apr 2004 21:57:16 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.30; FreeBSD)
	id 1BH8fa-000LbE-VS
	for v6ops@ops.ietf.org; Fri, 23 Apr 2004 21:57:15 +0000
Received: (qmail 41913 invoked by uid 1007); 23 Apr 2004 21:57:13 -0000
Date: Fri, 23 Apr 2004 23:57:13 +0200
From: Gert Doering <gert@space.net>
To: Alain Durand <Alain.Durand@Sun.COM>
Cc: "S. Daniel Park" <soohong.park@samsung.com>,
        "'Pekka Savola'" <pekkas@netcore.fi>, v6ops@ops.ietf.org
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
Message-ID: <20040423215713.GW13090@Space.Net>
References: <010601c42933$711bba50$67cadba8@LocalHost> <77DC1D1A-956E-11D8-A499-00039358A080@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <77DC1D1A-956E-11D8-A499-00039358A080@sun.com>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Fri, Apr 23, 2004 at 02:37:49PM -0700, Alain Durand wrote:
> Would ISP be willing to deploy IPv6 tunnel service in this 
> non-authenticated mode 
> on production networks? 

Good question.  We certainly are not interested in providing 
non-authenticated (= anonymous?) tunnel services.  

We want/need to be able to backtrace abuse, and (unless I overlook 
anything) this can only be done if we know who setup the tunnel.

On the other hand, we're not a "standard" ISP as we already *do* offer
IPv6 on "standard" products (leased line + ADSL access), so this might
not apply to us anyway.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  60210  (58081)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Sun Apr 25 12:41:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04965
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 12:41:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHmcX-00074G-6h
	for v6ops-data@psg.com; Sun, 25 Apr 2004 16:36:45 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHmcU-00073i-CI
	for v6ops@ops.ietf.org; Sun, 25 Apr 2004 16:36:43 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3PFb3209153;
	Sun, 25 Apr 2004 18:37:05 +0300
Date: Sun, 25 Apr 2004 18:37:03 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Gert Doering <gert@Space.Net>
cc: Alain Durand <Alain.Durand@Sun.COM>,
        "S. Daniel Park" <soohong.park@samsung.com>, <v6ops@ops.ietf.org>
Subject: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
In-Reply-To: <20040423215713.GW13090@Space.Net>
Message-ID: <Pine.LNX.4.44.0404251831010.8852-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Just clarification...

On Fri, 23 Apr 2004, Gert Doering wrote:
> On Fri, Apr 23, 2004 at 02:37:49PM -0700, Alain Durand wrote:
> > Would ISP be willing to deploy IPv6 tunnel service in this 
> > non-authenticated mode 
> > on production networks? 
> 
> Good question.  We certainly are not interested in providing 
> non-authenticated (= anonymous?) tunnel services.  
> 
> We want/need to be able to backtrace abuse, and (unless I overlook 
> anything) this can only be done if we know who setup the tunnel.

The "non-authenticated mode" -terminology is confusing, I think.  It 
would be better if we'd be able to find something else.

The question is: would ISPs in general be willing to host a "try-out 
service" which dependended only on the source IPv4 address of the 
hosts?

In other words, would:
 1) IPv4 source address identification be sufficient for ISPs offering 
    this "try-out tunneling" to their own customers _only_, and

 2) same as above, but also to the outsiders (compare to public 6to4 
    relays, but with IPv6 addresses from your pTLA).

My guess is that for 1), the answer would be generally "yes", and for 
2) generally "no".

(That's host we as a NREN would probably react.)

The similar questions could be asked about the "authenticated" mode as
well, of course.  I have a huch that the responses would be similar,
except in a few special cases.

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




From owner-v6ops@ops.ietf.org  Sun Apr 25 12:57:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05582
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 12:57:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHmvH-000D7e-BR
	for v6ops-data@psg.com; Sun, 25 Apr 2004 16:56:07 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.30; FreeBSD)
	id 1BHmvF-000D7K-RM
	for v6ops@ops.ietf.org; Sun, 25 Apr 2004 16:56:06 +0000
Received: (qmail 63978 invoked by uid 1007); 25 Apr 2004 16:56:04 -0000
Date: Sun, 25 Apr 2004 18:56:04 +0200
From: Gert Doering <gert@space.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Gert Doering <gert@space.net>, Alain Durand <Alain.Durand@Sun.COM>,
        "S. Daniel Park" <soohong.park@samsung.com>, v6ops@ops.ietf.org
Subject: Re: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
Message-ID: <20040425165604.GI13090@Space.Net>
References: <20040423215713.GW13090@Space.Net> <Pine.LNX.4.44.0404251831010.8852-100000@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0404251831010.8852-100000@netcore.fi>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Sun, Apr 25, 2004 at 06:37:03PM +0300, Pekka Savola wrote:
> The question is: would ISPs in general be willing to host a "try-out 
> service" which dependended only on the source IPv4 address of the 
> hosts?
> 
> In other words, would:
>  1) IPv4 source address identification be sufficient for ISPs offering 
>     this "try-out tunneling" to their own customers _only_, and
> 
>  2) same as above, but also to the outsiders (compare to public 6to4 
>     relays, but with IPv6 addresses from your pTLA).
> 
> My guess is that for 1), the answer would be generally "yes", and for 
> 2) generally "no".

Hmmm, for us as "small and somewhat more flexible commercial ISP", your
guess is right.  Offering a "try-this" service for our customers is 
something we regularily do.  

For "the whole world", it's difficult to justify any additional costs 
this might cause, so the typical answer would be "no".

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  60210  (58081)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Sun Apr 25 17:16:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17937
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 17:16:38 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHqwF-00065a-UY
	for v6ops-data@psg.com; Sun, 25 Apr 2004 21:13:23 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHqwE-00065I-PP
	for v6ops@ops.ietf.org; Sun, 25 Apr 2004 21:13:23 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3PLDLMu003309
	for <v6ops@ops.ietf.org>; Sun, 25 Apr 2004 15:13:22 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HWQ006EAWA7AU@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Sun, 25 Apr 2004 15:13:21 -0600 (MDT)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HWQ00K6GWA53N@mail.sun.net> for v6ops@ops.ietf.org; Sun,
 25 Apr 2004 15:13:18 -0600 (MDT)
Date: Sun, 25 Apr 2004 14:13:18 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: "non-authenticated" tunneling [Re:
 draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
In-reply-to: <20040425165604.GI13090@Space.Net>
To: Gert Doering <gert@Space.Net>
Cc: Pekka Savola <pekkas@netcore.fi>,
        "S. Daniel Park" <soohong.park@samsung.com>, v6ops@ops.ietf.org
Message-id: <5F7EAB46-96FD-11D8-8F56-00039358A080@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <20040423215713.GW13090@Space.Net>
 <Pine.LNX.4.44.0404251831010.8852-100000@netcore.fi>
 <20040425165604.GI13090@Space.Net>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

What is the desired level of interaction from an ISP with its IPv4 
customers
to access the new IPv6 service?

The assumption on the draft is that an ISP may be tempted to offer the 
service
as a try-out to any of _its_ customer without asking anything, no 
registration, no fees,
no tracking, no guaranty, no nothing. The so called 'non authenticated' 
mode
(I should rename this 'non-registered' mode) was design for that.
The draft also made the assumption that for anything more production 
oriented,
ISPs would like to see some kind of registration, at least for logging 
perspective.

Supporting two modes of operation certainly add complexity, so the 
question is,
is it worth it? Is there a real need from ISPs to offer this non 
registered mode?

	- Alain.




From owner-v6ops@ops.ietf.org  Sun Apr 25 17:20:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18080
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 17:20:26 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHr1p-0006m5-Id
	for v6ops-data@psg.com; Sun, 25 Apr 2004 21:19:09 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHr1m-0006lR-Kt
	for v6ops@ops.ietf.org; Sun, 25 Apr 2004 21:19:06 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3PLIt813055;
	Mon, 26 Apr 2004 00:18:55 +0300
Date: Mon, 26 Apr 2004 00:18:55 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: Gert Doering <gert@Space.Net>, "S. Daniel Park" <soohong.park@samsung.com>,
        <v6ops@ops.ietf.org>
Subject: Re: "non-authenticated" tunneling [Re:
 draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
In-Reply-To: <5F7EAB46-96FD-11D8-8F56-00039358A080@sun.com>
Message-ID: <Pine.LNX.4.44.0404260014170.13001-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Sun, 25 Apr 2004, Alain Durand wrote:
[...]
> Supporting two modes of operation certainly add complexity, so the
> question is, is it worth it? Is there a real need from ISPs to offer
> this non registered mode?

One could also (IMHO) ask whether there are cases when the ISP would 
only want to offer non-registered mode.

In some networks where the ISP is capable of offering dual-stack
access or other kind of tunneling methods (e.g., L2TP as described by
Gert), the only interest from the ISP side could be this "zero
infrastructure -- zero hassle" mode -- non-registered.

To me, both seem to be applicable but in different context:  
non-registered is an auto-discovered or a "tryout" thing, or meant for
short-term fix.  Registered seems like a more long-term solution for
an ISP which is serious about v6 but cannot/will not offer dual-stack
services for whatever reason yet.

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




From owner-v6ops@ops.ietf.org  Sun Apr 25 17:28:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18282
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 17:28:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHr9Q-0007wF-Vh
	for v6ops-data@psg.com; Sun, 25 Apr 2004 21:27:00 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHr9O-0007vu-L8
	for v6ops@ops.ietf.org; Sun, 25 Apr 2004 21:26:58 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000036359.msg
	for <v6ops@ops.ietf.org>; Sun, 25 Apr 2004 23:26:53 +0200
Message-ID: <162f01c42b0c$e21c6490$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <20040423215713.GW13090@Space.Net> <Pine.LNX.4.44.0404251831010.8852-100000@netcore.fi> <20040425165604.GI13090@Space.Net> <5F7EAB46-96FD-11D8-8F56-00039358A080@sun.com>
Subject: Re: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
Date: Sun, 25 Apr 2004 23:32:58 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Sun, 25 Apr 2004 23:26:53 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

In addition to that I will say that the ISP could be also interested in =
offering the service non only to _its_customers but also to:
- _its_customers when traveling
- _other_customers in order to convince them about the service and gain =
then

I still feel that non-authenticated is acceptable ;-), specially because =
is a clear contraposition to the authenticated mode. Unless we agree =
that the correct denomination is registered and non-registered modes ?

Whatever is the final name, I really believe that both modes are a must.

Regards,
Jordi

----- Original Message -----=20
From: "Alain Durand" <Alain.Durand@Sun.COM>
To: "Gert Doering" <gert@Space.Net>
Cc: "Pekka Savola" <pekkas@netcore.fi>; "S. Daniel Park" =
<soohong.park@samsung.com>; <v6ops@ops.ietf.org>
Sent: Sunday, April 25, 2004 11:13 PM
Subject: Re: "non-authenticated" tunneling [Re: =
draft-durand-v6ops-assisted-tunneling-requirements-00.txt]


> What is the desired level of interaction from an ISP with its IPv4=20
> customers
> to access the new IPv6 service?
>=20
> The assumption on the draft is that an ISP may be tempted to offer the =

> service
> as a try-out to any of _its_ customer without asking anything, no=20
> registration, no fees,
> no tracking, no guaranty, no nothing. The so called 'non =
authenticated'=20
> mode
> (I should rename this 'non-registered' mode) was design for that.
> The draft also made the assumption that for anything more production=20
> oriented,
> ISPs would like to see some kind of registration, at least for logging =

> perspective.
>=20
> Supporting two modes of operation certainly add complexity, so the=20
> question is,
> is it worth it? Is there a real need from ISPs to offer this non=20
> registered mode?
>=20
> - Alain.
>=20
>=20
> 




From owner-v6ops@ops.ietf.org  Sun Apr 25 17:31:21 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18398
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 17:31:21 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHrCO-0008LU-SL
	for v6ops-data@psg.com; Sun, 25 Apr 2004 21:30:04 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHrCN-0008JI-C8
	for v6ops@ops.ietf.org; Sun, 25 Apr 2004 21:30:03 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000036364.msg
	for <v6ops@ops.ietf.org>; Sun, 25 Apr 2004 23:29:58 +0200
Message-ID: <163501c42b0d$5125af90$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <Pine.LNX.4.44.0404260014170.13001-100000@netcore.fi>
Subject: Re: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
Date: Sun, 25 Apr 2004 23:36:04 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Sun, 25 Apr 2004 23:29:58 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Agree ... actually I believe I mention this case in the sense that a =
non-registered mode is very easy to implement, same as a 6to4, and ISPs =
could only go to offer this if adds not overload to their work.

I know ... the workload can come by abusers of the service, but some =
times is much easier to have a non-registered service and then either =
allow the service only in "own" network or filter offending users, or =
whatever.

Regards,
Jordi

----- Original Message -----=20
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Alain Durand" <Alain.Durand@Sun.COM>
Cc: "Gert Doering" <gert@Space.Net>; "S. Daniel Park" =
<soohong.park@samsung.com>; <v6ops@ops.ietf.org>
Sent: Sunday, April 25, 2004 11:18 PM
Subject: Re: "non-authenticated" tunneling [Re: =
draft-durand-v6ops-assisted-tunneling-requirements-00.txt]


> On Sun, 25 Apr 2004, Alain Durand wrote:
> [...]
> > Supporting two modes of operation certainly add complexity, so the
> > question is, is it worth it? Is there a real need from ISPs to offer
> > this non registered mode?
>=20
> One could also (IMHO) ask whether there are cases when the ISP would=20
> only want to offer non-registered mode.
>=20
> In some networks where the ISP is capable of offering dual-stack
> access or other kind of tunneling methods (e.g., L2TP as described by
> Gert), the only interest from the ISP side could be this "zero
> infrastructure -- zero hassle" mode -- non-registered.
>=20
> To me, both seem to be applicable but in different context: =20
> non-registered is an auto-discovered or a "tryout" thing, or meant for
> short-term fix.  Registered seems like a more long-term solution for
> an ISP which is serious about v6 but cannot/will not offer dual-stack
> services for whatever reason yet.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20
> 




From owner-v6ops@ops.ietf.org  Sun Apr 25 17:33:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18510
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 17:33:23 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHrEM-0008hR-9j
	for v6ops-data@psg.com; Sun, 25 Apr 2004 21:32:06 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHrEL-0008h8-Ey
	for v6ops@ops.ietf.org; Sun, 25 Apr 2004 21:32:05 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3PLW5Mu008849
	for <v6ops@ops.ietf.org>; Sun, 25 Apr 2004 15:32:05 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HWQ00J3KX5GAZ@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Sun, 25 Apr 2004 15:32:05 -0600 (MDT)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HWQ00KJ6X5F3K@mail.sun.net> for v6ops@ops.ietf.org; Sun,
 25 Apr 2004 15:32:04 -0600 (MDT)
Date: Sun, 25 Apr 2004 14:32:04 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: "non-authenticated" tunneling [Re:
 draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
In-reply-to: <Pine.LNX.4.44.0404260014170.13001-100000@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Gert Doering <gert@Space.Net>, "S. Daniel Park" <soohong.park@samsung.com>,
        v6ops@ops.ietf.org
Message-id: <FEC5E880-96FF-11D8-8F56-00039358A080@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0404260014170.13001-100000@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Pekka,

I understand what you are saying, but are you speaking
as an ISP, a wg participant or as the wg chair?

	- Alain.




From owner-v6ops@ops.ietf.org  Sun Apr 25 22:44:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02296
	for <v6ops-archive@lists.ietf.org>; Sun, 25 Apr 2004 22:44:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHw4E-000GBJ-Ht
	for v6ops-data@psg.com; Mon, 26 Apr 2004 02:41:58 +0000
Received: from [203.254.224.25] (helo=mailout2.samsung.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHw4A-000GAp-I4
	for v6ops@ops.ietf.org; Mon, 26 Apr 2004 02:41:54 +0000
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0HWR00KFABHT5D@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon,
 26 Apr 2004 11:41:53 +0900 (KST)
Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25])
 by mailout2.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0HWR00035BH4GL@mailout2.samsung.com> for v6ops@ops.ietf.org;
 Mon, 26 Apr 2004 11:41:28 +0900 (KST)
Received: from LocalHost ([168.219.202.103])
 by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23
 2003)) with ESMTPA id <0HWR00C39BH0TX@mmp2.samsung.com> for
 v6ops@ops.ietf.org; Mon, 26 Apr 2004 11:41:25 +0900 (KST)
Date: Mon, 26 Apr 2004 11:41:51 +0900
From: "S. Daniel Park" <soohong.park@samsung.com>
Subject: RE: "non-authenticated" tunneling [Re:
 draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
In-reply-to: <5F7EAB46-96FD-11D8-8F56-00039358A080@sun.com>
To: Alain.Durand@Sun.COM, "'Gert Doering'" <gert@Space.Net>
Cc: "'Pekka Savola'" <pekkas@netcore.fi>, v6ops@ops.ietf.org
Message-id: <004001c42b38$0810faf0$67cadba8@LocalHost>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

> Supporting two modes of operation certainly 
> add complexity, so the question is, 
> is it worth it? Is there a real need from ISPs 
> to offer this non registered mode?

Well, *real need* is so difficult to mention in the 
ISP aspect. I guess ISPs don't like to do it as 
non-registered mode whether it is try-out phase 
or not. If this draft is for requirements, it is not
bad to describe both at this stage.



- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 





From owner-v6ops@ops.ietf.org  Mon Apr 26 01:23:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09197
	for <v6ops-archive@lists.ietf.org>; Mon, 26 Apr 2004 01:23:07 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BHyXN-000IrM-Lu
	for v6ops-data@psg.com; Mon, 26 Apr 2004 05:20:13 +0000
Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BHyXM-000Ir1-HH
	for v6ops@ops.ietf.org; Mon, 26 Apr 2004 05:20:12 +0000
Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 01:19:53 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
Date: Mon, 26 Apr 2004 01:19:53 -0400
Message-ID: <F4410B91C6CC314F9582B1A8E91DC928BEEB3C@ftmail2000>
Thread-Topic: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
Thread-Index: AcQrDcPspDowSGk/QD6f+1IB45B6pQAPgKhg
From: "Soliman Hesham" <H.Soliman@flarion.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 26 Apr 2004 05:19:53.0129 (UTC) FILETIME=[1ADC1190:01C42B4E]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I have one comment on this thread.=20

The discussion seems to look at the transition mechanism
in isolation. I.e., whether the mechanism is authenticated
or not, and based on that we seem to be deciding whether=20
it's useful for ISPs to deploy such mechanisms.=20

There is a typical flaw in concentrating on the mechanism
without considering the context. I thought that one of the
reasons for considering specific scenarios was to avoid=20
that flaw. For instance, a mechanism itself may be "unauthenticated",=20
but that doesn't mean that when it gets used in a network
that assumes secure access and user tracking it's still
considered unauthenticated. ISPs may already have existing=20
tools in their network to augment the security "deficiencies"
of a particular mechanism.=20

The danger of going down this track is that we might duplicate
work done somewhere else without providing additional benefits
to certain scenarios. I.e. if the default is "make no assumptions
about the context" we could end up with solutions that are
over complicated in some scenarios.=20

So I think this discussion is more useful when considering
specific cases.=20

Hesham


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is=20
strictly prohibited.  If you are not the intended recipient please =
contact
the sender and delete all copies.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D




From owner-v6ops@ops.ietf.org  Mon Apr 26 03:08:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27300
	for <v6ops-archive@lists.ietf.org>; Mon, 26 Apr 2004 03:08:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BI0BM-000Doh-Jf
	for v6ops-data@psg.com; Mon, 26 Apr 2004 07:05:36 +0000
Received: from [195.64.92.136] (helo=purgatory.unfix.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BI0BK-000DoO-KY
	for v6ops@ops.ietf.org; Mon, 26 Apr 2004 07:05:34 +0000
Received: from localhost (localhost [127.0.0.1])
	by purgatory.unfix.org (Postfix) with ESMTP
	id E332B802B; Mon, 26 Apr 2004 09:05:31 +0200 (CEST)
Received: from purgatory.unfix.org ([127.0.0.1])
	by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id 24410-64; Mon, 26 Apr 2004 09:05:05 +0200 (CEST)
Received: from dhcp70-109.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP
	id A52AE7FF2; Mon, 26 Apr 2004 09:05:04 +0200 (CEST)
Subject: Re: "non-authenticated" tunneling [Re:
	draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.44.0404251831010.8852-100000@netcore.fi>
References: <Pine.LNX.4.44.0404251831010.8852-100000@netcore.fi>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UQlayBhniyqRmN/anHRu"
Organization: Unfix
Message-Id: <1082963097.4500.198.camel@segesta.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 26 Apr 2004 09:04:57 +0200
X-Virus-Scanned: purgatory.unfix.org - http://unfix.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-UQlayBhniyqRmN/anHRu
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2004-04-25 at 17:37, Pekka Savola wrote:
> Just clarification...
>=20
> On Fri, 23 Apr 2004, Gert Doering wrote:
> > On Fri, Apr 23, 2004 at 02:37:49PM -0700, Alain Durand wrote:
> > > Would ISP be willing to deploy IPv6 tunnel service in this=20
> > > non-authenticated mode=20
> > > on production networks?=20
> >=20
> > Good question.  We certainly are not interested in providing=20
> > non-authenticated (=3D anonymous?) tunnel services. =20
> >=20
> > We want/need to be able to backtrace abuse, and (unless I overlook=20
> > anything) this can only be done if we know who setup the tunnel.
>=20
> The "non-authenticated mode" -terminology is confusing, I think.  It=20
> would be better if we'd be able to find something else.

I would call that "Anonymous". But I would provide the 'client' with
a cookie or something similar so that they can pass the cookie to you
when they come back and thus allowing them to get the same prefix they
had before.

> The question is: would ISPs in general be willing to host a "try-out=20
> service" which dependended only on the source IPv4 address of the=20
> hosts?
>=20
> In other words, would:
>  1) IPv4 source address identification be sufficient for ISPs offering=20
>     this "try-out tunneling" to their own customers _only_, and

This indeed works for most ISP's. They can do this by filtering based on
the request made or simply by putting a firewall on the service endpoint
and thus filtering out anything unwanted.

>  2) same as above, but also to the outsiders (compare to public 6to4=20
>     relays, but with IPv6 addresses from your pTLA).

Anonymous is done by many ISP's already, at least if you look at a TB
being a anonymous service; Freenet6 is probably the best answer here.

> My guess is that for 1), the answer would be generally "yes", and for=20
> 2) generally "no".

Correct.

> (That's host we as a NREN would probably react.)
>=20
> The similar questions could be asked about the "authenticated" mode as
> well, of course.  I have a huch that the responses would be similar,
> except in a few special cases.

It actually all depends on one simple thing: money.
If an authenticated user does pay why shouldn't you give service to them
even if it is somewhere else. Though such policies are mostly ISP based.

Greets,
 Jeroen


--=-UQlayBhniyqRmN/anHRu
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBAjLSYKaooUjM+fCMRAhwWAJ4l+k8w5j/wStLdcOfNdP2JRygV8QCgmV6m
3r363diY8iP7HjEp1qaEPIM=
=zNE7
-----END PGP SIGNATURE-----

--=-UQlayBhniyqRmN/anHRu--




From owner-v6ops@ops.ietf.org  Tue Apr 27 06:20:57 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19947
	for <v6ops-archive@lists.ietf.org>; Tue, 27 Apr 2004 06:20:57 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIPdc-000Bxw-IH
	for v6ops-data@psg.com; Tue, 27 Apr 2004 10:16:28 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIPdb-000Bxj-He
	for v6ops@ops.ietf.org; Tue, 27 Apr 2004 10:16:27 +0000
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3RAGL4U015349;
	Tue, 27 Apr 2004 04:16:22 -0600 (MDT)
Received: from blixten (dhcp-gnb07-212-213 [129.157.212.213])
	by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i3RAGHQ29841;
	Tue, 27 Apr 2004 12:16:17 +0200 (MEST)
Date: Mon, 26 Apr 2004 06:19:13 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
To: Alain Durand <Alain.Durand@sun.com>
Cc: "S. Daniel Park" <soohong.park@samsung.com>,
        "'Pekka Savola'" <pekkas@netcore.fi>, v6ops@ops.ietf.org
In-Reply-To: "Your message with ID" <77DC1D1A-956E-11D8-A499-00039358A080@sun.com>
Message-ID: <Roam.SIMC.2.0.6.1082985553.7131.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

> In the current document, /64 prefix allocation is not mandatory.
> Our opinion as author was that the non-authenticated mode
> was meant to be used in a try-out environment only and
> connecting only one node was enough.
> In our opinion, any more than that would require authentication.
> But this is only one opinion, I would like to get more feedback on this 
> point:
> 
> Would ISP be willing to deploy IPv6 tunnel service in this 
> non-authenticated mode
> on production networks?

I can see this depending on what other authentication is taking place.
For instance, if e.g. Radius authentication occurs before the IPv4 address
is assigned to the customer, the tunnel setup protocols does return
routability check, and the ISP protects the routing of their addresses
(e.g. using route filters at their edges) then why doesn't the IPv4 address
provide sufficient proof (after the return routability check) that
the user is indeed the user that was authenticated using Radius?

So it might be that explicit authentication of the tunnel
setup is only needed when
1) there wasn't authentication for the IPv4 setup, or the tunnel
   server can't extract the user id from system based on the IPv4 address
2) the infrastructure between the tunnel server and the client isn't
   trusted (which might be an argument for using IPsec tunnels in
   addition to authenticating the tunnel setup).

Thus it is far clear for me that what you call unauthenticated setup is
that limited (it is "not explicitly authenticated" IMHO since there
might be IPv4-related authentication that can be reused).

One other minor comment on the document;
In section 2 it talks about "customer owned NAT".
I think the issue applies whether the NAT is customer or ISP owned and
controlled. Even for an ISP owned and controlled NAT the ISP might not want
to upgrade the NAT to be more friendly to IPv6 (e.g. by supporting tunneling
on the NAT itself) since that might be expensive.
Thus I think it makes sense to state that the NAT might belong to the customer
or the ISP in section 2.

   Erik




From owner-v6ops@ops.ietf.org  Tue Apr 27 09:20:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29391
	for <v6ops-archive@lists.ietf.org>; Tue, 27 Apr 2004 09:20:24 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BISSU-000Fqh-6x
	for v6ops-data@psg.com; Tue, 27 Apr 2004 13:17:10 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BISSS-000FqM-7q
	for v6ops@ops.ietf.org; Tue, 27 Apr 2004 13:17:08 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3RDH7815718
	for <v6ops@ops.ietf.org>; Tue, 27 Apr 2004 16:17:07 +0300
Date: Tue, 27 Apr 2004 16:17:07 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Scenarios analysis documents: BCP vs Informational?
Message-ID: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

During the IESG review of the 3GPP analysis document there was a 
comment wondering its intended BCP category:

=====
>    The scope of this Best Current Practices document is to analyze and 
>    solve the possible transition scenarios in the 3GPP defined GPRS 
>    network

Scenarios aren't things you *solve*; they are things you *describe*. I
would see no objection to this as an Informational, but I think it
(and its future companion documents from v6ops) are hardly BCPs. There
is surely no current practice on which to base the assertion that this
draft describes the Best.
=====

The initial plan (which never had much justification) had been to
publish the Scenarios documents as Informational, and analysis
documents (describing the best understanding of the recommended
deployment approaches) as BCP(s).

As far as I can understand, the reason why BCP seems inappropriate is 
because the documents might not be for example:
 1) not clearly describing _current_ practice (i.e., when there has 
    not yet been sufficient deployment, but only analysis), or

 2) not clearly describing _best_ practice (i.e., if the document is 
    not sufficiently detailed to pick among the alternatives, etc.)

On the other hand, BCP would seem appropriate if the description is
detailed enough, and/or current enough so that we can justify that it
is actually already both a _current_ and _best_ practice.  In a way,
BCP also sends a stronger message to the community on the
recommendations (whether that is relevant or necessary is another
question).

Now, as there can be arguments for both ways, it would be useful to
see if there are preferences about this in the WG:

 a) continue with BCP category,

 b) publish 3GPP analysis as Informational and consider the rest in 
    case-by-case basis (whether Info or BCP).  Some other analysis 
    documents may or may not fall better under the BCP category, or

 c) publish 3GPP analysis as Informational; take the rest to 
    informational as well.

Opinions?  a), b), or c)?

(co-chair hat off)






From owner-v6ops@ops.ietf.org  Tue Apr 27 09:44:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00771
	for <v6ops-archive@lists.ietf.org>; Tue, 27 Apr 2004 09:44:28 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BISr8-000JNU-Ml
	for v6ops-data@psg.com; Tue, 27 Apr 2004 13:42:38 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BISr6-000JNG-4K
	for v6ops@ops.ietf.org; Tue, 27 Apr 2004 13:42:36 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000042136.msg
	for <v6ops@ops.ietf.org>; Tue, 27 Apr 2004 15:42:31 +0200
Message-ID: <0d2901c42c5d$7c2f45b0$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
Subject: Re: Scenarios analysis documents: BCP vs Informational?
Date: Tue, 27 Apr 2004 15:42:28 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Tue, 27 Apr 2004 15:42:31 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Tue, 27 Apr 2004 15:42:34 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Pekka,

I believe is very difficult to take a general rule, even when talking only about scenario documents, and even when I could agree, in general, with your rationale.

I will like to heard the rational from the authors. I think will be useful (I know they have actually used in the document BCP).

We have a similar problem with the rest of the WG (and some individual) documents, since a long time ago, and we have talked about some options in the last meeting, but now sure if the decision and process is clear enough.

I think looking to all this we can take a more clear and open decision.

Regards,
Jordi

----- Original Message -----=20
From: "Pekka Savola" <pekkas@netcore.fi>
To: <v6ops@ops.ietf.org>
Sent: Tuesday, April 27, 2004 3:17 PM
Subject: Scenarios analysis documents: BCP vs Informational?


> Hi,
>=20
> (co-chair hat on)
>=20
> During the IESG review of the 3GPP analysis document there was a=20
> comment wondering its intended BCP category:
>=20
> =3D=3D=3D=3D=3D
> >    The scope of this Best Current Practices document is to analyze and=20
> >    solve the possible transition scenarios in the 3GPP defined GPRS=20
> >    network
>=20
> Scenarios aren't things you *solve*; they are things you *describe*. I
> would see no objection to this as an Informational, but I think it
> (and its future companion documents from v6ops) are hardly BCPs. There
> is surely no current practice on which to base the assertion that this
> draft describes the Best.
> =3D=3D=3D=3D=3D
>=20
> The initial plan (which never had much justification) had been to
> publish the Scenarios documents as Informational, and analysis
> documents (describing the best understanding of the recommended
> deployment approaches) as BCP(s).
>=20
> As far as I can understand, the reason why BCP seems inappropriate is=20
> because the documents might not be for example:
>  1) not clearly describing _current_ practice (i.e., when there has=20
>     not yet been sufficient deployment, but only analysis), or
>=20
>  2) not clearly describing _best_ practice (i.e., if the document is=20
>     not sufficiently detailed to pick among the alternatives, etc.)
>=20
> On the other hand, BCP would seem appropriate if the description is
> detailed enough, and/or current enough so that we can justify that it
> is actually already both a _current_ and _best_ practice.  In a way,
> BCP also sends a stronger message to the community on the
> recommendations (whether that is relevant or necessary is another
> question).
>=20
> Now, as there can be arguments for both ways, it would be useful to
> see if there are preferences about this in the WG:
>=20
>  a) continue with BCP category,
>=20
>  b) publish 3GPP analysis as Informational and consider the rest in=20
>     case-by-case basis (whether Info or BCP).  Some other analysis=20
>     documents may or may not fall better under the BCP category, or
>=20
>  c) publish 3GPP analysis as Informational; take the rest to=20
>     informational as well.
>=20
> Opinions?  a), b), or c)?
>=20
> (co-chair hat off)
>=20
>=20
>=20
>=20
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Tue Apr 27 12:58:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12830
	for <v6ops-archive@lists.ietf.org>; Tue, 27 Apr 2004 12:58:23 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIVqK-000PIW-QI
	for v6ops-data@psg.com; Tue, 27 Apr 2004 16:54:00 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIVqH-000PDr-QA
	for v6ops@ops.ietf.org; Tue, 27 Apr 2004 16:53:57 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3RGrvMu021529
	for <v6ops@ops.ietf.org>; Tue, 27 Apr 2004 10:53:57 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HWU00KVN9LW69@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Tue, 27 Apr 2004 10:53:57 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HWU00BSV9LVGV@mail.sun.net> for v6ops@ops.ietf.org; Tue,
 27 Apr 2004 10:53:56 -0600 (MDT)
Date: Tue, 27 Apr 2004 09:53:53 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Scenarios analysis documents: BCP vs Informational?
In-reply-to: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Message-id: <775657C9-986B-11D8-8097-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 27, 2004, at 6:17 AM, Pekka Savola wrote:
>
>  a) continue with BCP category,
>
>  b) publish 3GPP analysis as Informational and consider the rest in
>     case-by-case basis (whether Info or BCP).  Some other analysis
>     documents may or may not fall better under the BCP category, or
>
>  c) publish 3GPP analysis as Informational; take the rest to
>     informational as well.
>
> Opinions?  a), b), or c)?

c)

	- Alain.




From owner-v6ops@ops.ietf.org  Tue Apr 27 15:29:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23922
	for <v6ops-archive@lists.ietf.org>; Tue, 27 Apr 2004 15:29:04 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIYDY-0000iR-7S
	for v6ops-data@psg.com; Tue, 27 Apr 2004 19:26:08 +0000
Received: from [209.71.226.3] (helo=panoramix.hexago.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIYDX-0000i9-0Q
	for v6ops@ops.ietf.org; Tue, 27 Apr 2004 19:26:07 +0000
Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22])
	(authenticated bits=0)
	by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i3RJPsvI027016;
	Tue, 27 Apr 2004 15:25:54 -0400 (EDT)
Date: Tue, 27 Apr 2004 15:25:38 -0400
From: Marc Blanchet <Marc.Blanchet@hexago.com>
To: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
Subject: Re: Scenarios analysis documents: BCP vs Informational?
Message-ID: <126160000.1083093938@classic.viagenie.qc.ca>
In-Reply-To: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
References: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
X-Mailer: Mulberry/3.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

all informational. 

Marc.

-- Tuesday, April 27, 2004 16:17:07 +0300 Pekka Savola <pekkas@netcore.fi>
wrote/a ecrit:

> Hi,
> 
> (co-chair hat on)
> 
> During the IESG review of the 3GPP analysis document there was a 
> comment wondering its intended BCP category:
> 
> =====
>>    The scope of this Best Current Practices document is to analyze and 
>>    solve the possible transition scenarios in the 3GPP defined GPRS 
>>    network
> 
> Scenarios aren't things you *solve*; they are things you *describe*. I
> would see no objection to this as an Informational, but I think it
> (and its future companion documents from v6ops) are hardly BCPs. There
> is surely no current practice on which to base the assertion that this
> draft describes the Best.
> =====
> 
> The initial plan (which never had much justification) had been to
> publish the Scenarios documents as Informational, and analysis
> documents (describing the best understanding of the recommended
> deployment approaches) as BCP(s).
> 
> As far as I can understand, the reason why BCP seems inappropriate is 
> because the documents might not be for example:
>  1) not clearly describing _current_ practice (i.e., when there has 
>     not yet been sufficient deployment, but only analysis), or
> 
>  2) not clearly describing _best_ practice (i.e., if the document is 
>     not sufficiently detailed to pick among the alternatives, etc.)
> 
> On the other hand, BCP would seem appropriate if the description is
> detailed enough, and/or current enough so that we can justify that it
> is actually already both a _current_ and _best_ practice.  In a way,
> BCP also sends a stronger message to the community on the
> recommendations (whether that is relevant or necessary is another
> question).
> 
> Now, as there can be arguments for both ways, it would be useful to
> see if there are preferences about this in the WG:
> 
>  a) continue with BCP category,
> 
>  b) publish 3GPP analysis as Informational and consider the rest in 
>     case-by-case basis (whether Info or BCP).  Some other analysis 
>     documents may or may not fall better under the BCP category, or
> 
>  c) publish 3GPP analysis as Informational; take the rest to 
>     informational as well.
> 
> Opinions?  a), b), or c)?
> 
> (co-chair hat off)
> 
> 
> 



------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------



From owner-v6ops@ops.ietf.org  Tue Apr 27 16:12:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26559
	for <v6ops-archive@lists.ietf.org>; Tue, 27 Apr 2004 16:12:37 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIYuK-000AJE-SD
	for v6ops-data@psg.com; Tue, 27 Apr 2004 20:10:20 +0000
Received: from [205.167.76.9] (helo=m106.maoz.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIYuH-000AIc-W3
	for v6ops@ops.ietf.org; Tue, 27 Apr 2004 20:10:18 +0000
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3RKAEA1004340;
	Tue, 27 Apr 2004 13:10:14 -0700
Received: (from dmm@localhost)
	by m106.maoz.com (8.12.11/8.12.10/Submit) id i3RKAE5W004339;
	Tue, 27 Apr 2004 13:10:14 -0700
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f
Date: Tue, 27 Apr 2004 13:10:14 -0700
From: David Meyer <dmm@1-4-5.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Subject: Re: Scenarios analysis documents: BCP vs Informational?
Message-ID: <20040427201014.GA4319@1-4-5.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I just had to let it go" -- John Lennon
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

> Hi,
> 
> (co-chair hat on)
> 
> During the IESG review of the 3GPP analysis document there was a 
> comment wondering its intended BCP category:
> 
> =====
>   The scope of this Best Current Practices document is to analyze and 
>   solve the possible transition scenarios in the 3GPP defined GPRS 
>   network
> 
> Scenarios aren't things you *solve*; they are things you *describe*. I
> would see no objection to this as an Informational, but I think it
> (and its future companion documents from v6ops) are hardly BCPs. There
> is surely no current practice on which to base the assertion that this
> draft describes the Best.
> =====
> 
> The initial plan (which never had much justification) had been to
> publish the Scenarios documents as Informational, and analysis
> documents (describing the best understanding of the recommended
> deployment approaches) as BCP(s).
> 
> As far as I can understand, the reason why BCP seems inappropriate is 
> because the documents might not be for example:
>  1) not clearly describing _current_ practice (i.e., when there has 
>     not yet been sufficient deployment, but only analysis), or
> 
>  2) not clearly describing _best_ practice (i.e., if the document is 
>     not sufficiently detailed to pick among the alternatives, etc.)
> 
> On the other hand, BCP would seem appropriate if the description is
> detailed enough, and/or current enough so that we can justify that it
> is actually already both a _current_ and _best_ practice.  In a way,
> BCP also sends a stronger message to the community on the
> recommendations (whether that is relevant or necessary is another
> question).
> 
> Now, as there can be arguments for both ways, it would be useful to
> see if there are preferences about this in the WG:
> 
>  a) continue with BCP category,
> 
>  b) publish 3GPP analysis as Informational and consider the rest in 
>     case-by-case basis (whether Info or BCP).  Some other analysis 
>     documents may or may not fall better under the BCP category, or
> 
>  c) publish 3GPP analysis as Informational; take the rest to 
>     informational as well.
> 
> Opinions?  a), b), or c)?
> 
> (co-chair hat off)
> 

	I just reread the document, and would say that option c
	seems most reasonable. 

	Dave



From owner-v6ops@ops.ietf.org  Wed Apr 28 05:42:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02719
	for <v6ops-archive@lists.ietf.org>; Wed, 28 Apr 2004 05:42:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIlUp-000DlH-3k
	for v6ops-data@psg.com; Wed, 28 Apr 2004 09:36:51 +0000
Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIlUn-000DgU-3o
	for v6ops@ops.ietf.org; Wed, 28 Apr 2004 09:36:49 +0000
Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1])
	by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3S9alPk096012
	for <v6ops@ops.ietf.org>; Wed, 28 Apr 2004 09:36:47 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3S9akHI160456
	for <v6ops@ops.ietf.org>; Wed, 28 Apr 2004 11:36:47 +0200
Received: from zurich.ibm.com (sig-9-145-172-96.de.ibm.com [9.145.172.96])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA30760
	for <v6ops@ops.ietf.org>; Wed, 28 Apr 2004 11:36:45 +0200
Message-ID: <408F7B3A.1020603@zurich.ibm.com>
Date: Wed, 28 Apr 2004 11:36:58 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: v6ops@ops.ietf.org
Subject: Re: Scenarios analysis documents: BCP vs Informational?
References: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi> <775657C9-986B-11D8-8097-00039376A6AA@sun.com>
In-Reply-To: <775657C9-986B-11D8-8097-00039376A6AA@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Alain Durand wrote:
> 
> On Apr 27, 2004, at 6:17 AM, Pekka Savola wrote:
> 
>>
>>  a) continue with BCP category,
>>
>>  b) publish 3GPP analysis as Informational and consider the rest in
>>     case-by-case basis (whether Info or BCP).  Some other analysis
>>     documents may or may not fall better under the BCP category, or
>>
>>  c) publish 3GPP analysis as Informational; take the rest to
>>     informational as well.
>>
>> Opinions?  a), b), or c)?
> 
> 
> c)

I agree.

(Truth in advertising: I was Harald's reviewer who made the
original comment.)

     Brian



From owner-v6ops@ops.ietf.org  Wed Apr 28 08:39:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12444
	for <v6ops-archive@lists.ietf.org>; Wed, 28 Apr 2004 08:39:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIoIZ-000DxT-NG
	for v6ops-data@psg.com; Wed, 28 Apr 2004 12:36:23 +0000
Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIoIX-000Dt4-Vy
	for v6ops@ops.ietf.org; Wed, 28 Apr 2004 12:36:22 +0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3SCaKMp080490
	for <v6ops@ops.ietf.org>; Wed, 28 Apr 2004 12:36:20 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3SCaKYk140678
	for <v6ops@ops.ietf.org>; Wed, 28 Apr 2004 14:36:20 +0200
Received: from zurich.ibm.com (sig-9-145-169-29.de.ibm.com [9.145.169.29])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA58966
	for <v6ops@ops.ietf.org>; Wed, 28 Apr 2004 14:36:19 +0200
Message-ID: <408FA550.8090504@zurich.ibm.com>
Date: Wed, 28 Apr 2004 14:36:32 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
References: <200404211937.PAA10059@ietf.org>
In-Reply-To: <200404211937.PAA10059@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-trans-00.txt

This is a very interesting concept, but I have some doubt about the goal
of spontaneously changing to a different mechanism without disruption.
I think it is over-ambitious. As pointed out in section 3.2, point 1,
this requires keeping the same address even if (for example) changing
from one tunnel provider to another - that's very unlikely to
work (unless of course we have a fully deployed multi6 solution
or use mobile IP exclusively). So I would be tempted to limit the scope
to choosing the best initial method.

One detail: Section 3.3.3 discusses "layer 4" tunnels but doesn't
list IPv6 over TLS/SSL - but that is a very real possibility (in fact
I use IPv4 over SSL very frequently, since it gets through certain NATs
that IPSEC over UDP cannot deal with). It looks like a better option
than IP over SSH to me, and certainly better than IP over HTTP.

I'm not sure that we should even list this class of solution
as discouraged. It should perhaps be lower on the list of
preferences, but whatever works is good.

     Brian



From owner-v6ops@ops.ietf.org  Wed Apr 28 08:58:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13037
	for <v6ops-archive@lists.ietf.org>; Wed, 28 Apr 2004 08:58:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIocD-000Plq-BS
	for v6ops-data@psg.com; Wed, 28 Apr 2004 12:56:41 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIocB-000PiG-Ma
	for v6ops@ops.ietf.org; Wed, 28 Apr 2004 12:56:39 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i3SCub7s015929;
	Wed, 28 Apr 2004 13:56:37 +0100 (BST)
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA08478;
	Wed, 28 Apr 2004 13:56:35 +0100 (BST)
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i3SCuZx08153;
	Wed, 28 Apr 2004 13:56:35 +0100
Date: Wed, 28 Apr 2004 13:56:35 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Subject: Re: Scenarios analysis documents: BCP vs Informational?
Message-ID: <20040428125635.GC7397@login.ecs.soton.ac.uk>
Mail-Followup-To: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
References: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, Apr 27, 2004 at 04:17:07PM +0300, Pekka Savola wrote:
> 
>  a) continue with BCP category,
> 
>  b) publish 3GPP analysis as Informational and consider the rest in 
>     case-by-case basis (whether Info or BCP).  Some other analysis 
>     documents may or may not fall better under the BCP category, or
> 
>  c) publish 3GPP analysis as Informational; take the rest to 
>     informational as well.
> 
> Opinions?  a), b), or c)?

While BCP should be just that, the analyses miss the P on a big scale, so
I also agree Informational, with maybe in 12-18 months a BCP update once
we see which methods win out?

Tim



From owner-v6ops@ops.ietf.org  Wed Apr 28 09:17:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13984
	for <v6ops-archive@lists.ietf.org>; Wed, 28 Apr 2004 09:17:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BIous-000CCH-AS
	for v6ops-data@psg.com; Wed, 28 Apr 2004 13:15:58 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BIouq-000C7X-BE
	for v6ops@ops.ietf.org; Wed, 28 Apr 2004 13:15:56 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3SDFnA06215;
	Wed, 28 Apr 2004 16:15:49 +0300
Date: Wed, 28 Apr 2004 16:15:49 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Tim Chown <tjc@ecs.soton.ac.uk>
cc: v6ops@ops.ietf.org
Subject: Re: Scenarios analysis documents: BCP vs Informational?
In-Reply-To: <20040428125635.GC7397@login.ecs.soton.ac.uk>
Message-ID: <Pine.LNX.4.44.0404281613380.5736-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 28 Apr 2004, Tim Chown wrote:
> On Tue, Apr 27, 2004 at 04:17:07PM +0300, Pekka Savola wrote:
> >  a) continue with BCP category,
> > 
> >  b) publish 3GPP analysis as Informational and consider the rest in 
> >     case-by-case basis (whether Info or BCP).  Some other analysis 
> >     documents may or may not fall better under the BCP category, or
> > 
> >  c) publish 3GPP analysis as Informational; take the rest to 
> >     informational as well.
> > 
> > Opinions?  a), b), or c)?
> 
> While BCP should be just that, the analyses miss the P on a big scale, so
> I also agree Informational, with maybe in 12-18 months a BCP update once
> we see which methods win out?

At least for the ISP analysis document, I believe it quite accurately
describes _Best_, _Current_ and even _Practice_ :).

At least to the degree of how you deploy your core network (customer
access networks w/ tunneling is still behind..).

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




From owner-v6ops@ops.ietf.org  Wed Apr 28 23:41:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14645
	for <v6ops-archive@lists.ietf.org>; Wed, 28 Apr 2004 23:41:58 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJ2NJ-000DYT-VI
	for v6ops-data@psg.com; Thu, 29 Apr 2004 03:38:13 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJ2NI-000DYG-Ri
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 03:38:12 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP
	id 429FF4F0F; Wed, 28 Apr 2004 23:38:12 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 28 Apr 2004 23:38:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
Date: Wed, 28 Apr 2004 23:37:45 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C927@tayexc13.americas.cpqcorp.net>
Thread-Topic: "non-authenticated" tunneling [Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
Thread-Index: AcQrDSAYB+aTfDjFRzuWVD9XfgStKwCjfJMQ
From: "Bound, Jim" <jim.bound@hp.com>
To: "Alain Durand" <Alain.Durand@Sun.COM>, "Pekka Savola" <pekkas@netcore.fi>
Cc: "Gert Doering" <gert@Space.Net>,
        "S. Daniel Park" <soohong.park@samsung.com>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 29 Apr 2004 03:38:11.0976 (UTC) FILETIME=[65874080:01C42D9B]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Alain,

We will have some real running code and implementation of this
capability on Moonv6 very soon and offering the service to targeted
users as a note so we will have operational input to this as it evolves.

Regarding the authentication solution.  I believe the answer is AAA
methods.  I think your draft asks the right questions.  The answers will
take time to discuss.

Regards,
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alain Durand
> Sent: Sunday, April 25, 2004 5:32 PM
> To: Pekka Savola
> Cc: Gert Doering; S. Daniel Park; v6ops@ops.ietf.org
> Subject: Re: "non-authenticated" tunneling [Re:=20
> draft-durand-v6ops-assisted-tunneling-requirements-00.txt]
>=20
> Pekka,
>=20
> I understand what you are saying, but are you speaking as an=20
> ISP, a wg participant or as the wg chair?
>=20
> 	- Alain.
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Apr 29 05:17:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15605
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 05:17:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJ7cg-0008JQ-Oy
	for v6ops-data@psg.com; Thu, 29 Apr 2004 09:14:26 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJ7cb-0008If-5A
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 09:14:21 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000047630.msg
	for <v6ops@ops.ietf.org>; Thu, 29 Apr 2004 11:14:45 +0200
Message-ID: <237901c42dca$55e214a0$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <200404211937.PAA10059@ietf.org> <408FA550.8090504@zurich.ibm.com>
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Thu, 29 Apr 2004 11:13:54 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Thu, 29 Apr 2004 11:14:45 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Thu, 29 Apr 2004 11:14:47 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Brian,

Yes, I agree we are too ambitious ;-) but we should try at least ... Let's see how we can progress and in what circumstances this is possible (for example when disruption and/or keeping the same address is not a problem). We will work further on this aspect to concrete the text.

Of course, we can count with multi6 and/or MIPv6, so again, we will need some more work here.

Agree, we need to list TLS/SSL.

Thanks for your inputs !

Regards,
Jordi

----- Original Message -----=20
From: "Brian E Carpenter" <brc@zurich.ibm.com>
To: "IPv6 Operations" <v6ops@ops.ietf.org>
Sent: Wednesday, April 28, 2004 2:36 PM
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt


> > http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-trans-00.txt
>=20
> This is a very interesting concept, but I have some doubt about the goal
> of spontaneously changing to a different mechanism without disruption.
> I think it is over-ambitious. As pointed out in section 3.2, point 1,
> this requires keeping the same address even if (for example) changing
> from one tunnel provider to another - that's very unlikely to
> work (unless of course we have a fully deployed multi6 solution
> or use mobile IP exclusively). So I would be tempted to limit the scope
> to choosing the best initial method.
>=20
> One detail: Section 3.3.3 discusses "layer 4" tunnels but doesn't
> list IPv6 over TLS/SSL - but that is a very real possibility (in fact
> I use IPv4 over SSL very frequently, since it gets through certain NATs
> that IPSEC over UDP cannot deal with). It looks like a better option
> than IP over SSH to me, and certainly better than IP over HTTP.
>=20
> I'm not sure that we should even list this class of solution
> as discouraged. It should perhaps be lower on the list of
> preferences, but whatever works is good.
>=20
>      Brian
>=20
>=20


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Thu Apr 29 05:51:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16457
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 05:51:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJ89h-000MLl-4E
	for v6ops-data@psg.com; Thu, 29 Apr 2004 09:48:33 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJ89f-000MLU-Rx
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 09:48:32 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3T9lq925463;
	Thu, 29 Apr 2004 12:47:52 +0300
Date: Thu, 29 Apr 2004 12:47:52 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: david.kessens@nokia.com
cc: bwijnen@lucent.com, <iesg-secretary@ietf.org>, <v6ops@ops.ietf.org>
Subject: Request to Advance "Scenarios and Analysis for Introducing IPv6 into
 ISP Networks"
Message-ID: <Pine.LNX.4.44.0404291242440.25383-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

David,

On behalf of the v6ops WG, we'd like to request that the following
document be published as Informational RFC:

Scenarios and Analysis for Introducing IPv6 into ISP Networks
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-02.txt

The first WG last call was completed on 24th February.  The revised
version addresses the issues raised at the last call, and the second
last call which ended on 28th April brought forth no new issues.
Based on WG feedback, we request publishing this as Informational
rather than BCP, as originally intended.

Thanks,
 Pekka & Jonne
 v6ops WG co-chairs






From owner-v6ops@ops.ietf.org  Thu Apr 29 06:11:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17682
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 06:11:09 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJ8Tx-00041X-4p
	for v6ops-data@psg.com; Thu, 29 Apr 2004 10:09:29 +0000
Received: from [131.228.20.22] (helo=mgw-x2.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJ8Tw-00040k-6B
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 10:09:28 +0000
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TA9QH03953
	for <v6ops@ops.ietf.org>; Thu, 29 Apr 2004 13:09:26 +0300 (EET DST)
X-Scanned: Thu, 29 Apr 2004 13:09:04 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TA94wU014679
	for <v6ops@ops.ietf.org>; Thu, 29 Apr 2004 13:09:04 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks004.ntc.nokia.com 00TRPT5k; Thu, 29 Apr 2004 13:09:01 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TA8kH00406
	for <v6ops@ops.ietf.org>; Thu, 29 Apr 2004 13:08:46 +0300 (EET DST)
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 29 Apr 2004 13:08:26 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Scenarios analysis documents: BCP vs Informational?
Date: Thu, 29 Apr 2004 13:03:07 +0300
Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F025C33E8@esebe005.ntc.nokia.com>
Thread-Topic: Scenarios analysis documents: BCP vs Informational?
Thread-Index: AcQsWz5n8PatLuz+QCe9yPAObredrQBdacEQ
From: <juha.wiljakka@nokia.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 29 Apr 2004 10:08:26.0258 (UTC) FILETIME=[E9872720:01C42DD1]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable


Hi!

My opinion is c.

Cheers,
	 -Juha W.-

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext Pekka Savola

 a) continue with BCP category,

 b) publish 3GPP analysis as Informational and consider the rest in=20
    case-by-case basis (whether Info or BCP).  Some other analysis=20
    documents may or may not fall better under the BCP category, or

 c) publish 3GPP analysis as Informational; take the rest to=20
    informational as well.

Opinions?  a), b), or c)?



From owner-v6ops@ops.ietf.org  Thu Apr 29 06:25:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18629
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 06:25:55 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJ8he-000BsP-5K
	for v6ops-data@psg.com; Thu, 29 Apr 2004 10:23:38 +0000
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJ8hc-000Brz-9M
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 10:23:36 +0000
Received: from ams-core-1.cisco.com (144.254.224.150)
  by ams-iport-1.cisco.com with ESMTP; 29 Apr 2004 12:30:29 +0200
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3TANVbj028655;
	Thu, 29 Apr 2004 12:23:32 +0200 (MEST)
Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-74.cisco.com [10.86.242.74])
	by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AIA35677;
	Thu, 29 Apr 2004 06:23:30 -0400 (EDT)
Message-Id: <4.3.2.7.2.20040429062155.02bcd180@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 29 Apr 2004 06:23:28 -0400
To: Pekka Savola <pekkas@netcore.fi>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: Scenarios analysis documents: BCP vs Informational?
Cc: v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

I think c) is the best choice...

- Ralph

At 04:17 PM 4/27/2004 +0300, Pekka Savola wrote:
>Hi,
>
>(co-chair hat on)
>
>During the IESG review of the 3GPP analysis document there was a
>comment wondering its intended BCP category:
>
>=====
> >    The scope of this Best Current Practices document is to analyze and
> >    solve the possible transition scenarios in the 3GPP defined GPRS
> >    network
>
>Scenarios aren't things you *solve*; they are things you *describe*. I
>would see no objection to this as an Informational, but I think it
>(and its future companion documents from v6ops) are hardly BCPs. There
>is surely no current practice on which to base the assertion that this
>draft describes the Best.
>=====
>
>The initial plan (which never had much justification) had been to
>publish the Scenarios documents as Informational, and analysis
>documents (describing the best understanding of the recommended
>deployment approaches) as BCP(s).
>
>As far as I can understand, the reason why BCP seems inappropriate is
>because the documents might not be for example:
>  1) not clearly describing _current_ practice (i.e., when there has
>     not yet been sufficient deployment, but only analysis), or
>
>  2) not clearly describing _best_ practice (i.e., if the document is
>     not sufficiently detailed to pick among the alternatives, etc.)
>
>On the other hand, BCP would seem appropriate if the description is
>detailed enough, and/or current enough so that we can justify that it
>is actually already both a _current_ and _best_ practice.  In a way,
>BCP also sends a stronger message to the community on the
>recommendations (whether that is relevant or necessary is another
>question).
>
>Now, as there can be arguments for both ways, it would be useful to
>see if there are preferences about this in the WG:
>
>  a) continue with BCP category,
>
>  b) publish 3GPP analysis as Informational and consider the rest in
>     case-by-case basis (whether Info or BCP).  Some other analysis
>     documents may or may not fall better under the BCP category, or
>
>  c) publish 3GPP analysis as Informational; take the rest to
>     informational as well.
>
>Opinions?  a), b), or c)?
>
>(co-chair hat off)




From owner-v6ops@ops.ietf.org  Thu Apr 29 06:27:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18718
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 06:27:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJ8kO-000Dnd-Ky
	for v6ops-data@psg.com; Thu, 29 Apr 2004 10:26:28 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJ8kN-000Dkd-Kl
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 10:26:27 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TAQQC26122
	for <v6ops@ops.ietf.org>; Thu, 29 Apr 2004 13:26:26 +0300
Date: Thu, 29 Apr 2004 13:26:26 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: SUMMARY: Scenarios analysis documents: BCP vs Informational?
In-Reply-To: <Pine.LNX.4.44.0404271601480.15495-100000@netcore.fi>
Message-ID: <Pine.LNX.4.44.0404291324340.26109-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

Based on the responses, it seems clear that the WG rough consensus is
to use Informational for all the analysis documents.  Let's go forward
with that.

Thanks for feedback!

(co-chair hat off)




From owner-v6ops@ops.ietf.org  Thu Apr 29 08:05:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23023
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 08:05:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJAEX-0001Xo-DU
	for v6ops-data@psg.com; Thu, 29 Apr 2004 12:01:41 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJAEW-0001XY-Ct
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 12:01:40 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP
	id 2DF6AACA3; Thu, 29 Apr 2004 08:01:32 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 29 Apr 2004 08:01:32 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Scenarios analysis documents: BCP vs Informational?
Date: Thu, 29 Apr 2004 08:01:04 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C95C@tayexc13.americas.cpqcorp.net>
Thread-Topic: Scenarios analysis documents: BCP vs Informational?
Thread-Index: AcQsWz5n8PatLuz+QCe9yPAObredrQBdacEQAAQeVhA=
From: "Bound, Jim" <jim.bound@hp.com>
To: <juha.wiljakka@nokia.com>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 29 Apr 2004 12:01:32.0158 (UTC) FILETIME=[B63D51E0:01C42DE1]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I support (a).  Reason.  BCPs are more easily updated as we learn
Informational lasts forever.  Caveat is IETF is working on all of this
process so my rationale may be a moot point.  Well I we did replace the
base API info multiple times??   I just like the sound of BCP I guess
:--)

Regards,
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of juha.wiljakka@nokia.com
> Sent: Thursday, April 29, 2004 6:03 AM
> To: v6ops@ops.ietf.org
> Subject: RE: Scenarios analysis documents: BCP vs Informational?
>=20
>=20
> Hi!
>=20
> My opinion is c.
>=20
> Cheers,
> 	 -Juha W.-
>=20
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of ext Pekka Savola
>=20
>  a) continue with BCP category,
>=20
>  b) publish 3GPP analysis as Informational and consider the rest in=20
>     case-by-case basis (whether Info or BCP).  Some other analysis=20
>     documents may or may not fall better under the BCP category, or
>=20
>  c) publish 3GPP analysis as Informational; take the rest to=20
>     informational as well.
>=20
> Opinions?  a), b), or c)?
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Apr 29 11:09:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08058
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 11:09:08 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJD6e-0007Gb-Kn
	for v6ops-data@psg.com; Thu, 29 Apr 2004 15:05:44 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJD6d-0007Fs-7d
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 15:05:43 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TF5Va31298;
	Thu, 29 Apr 2004 18:05:31 +0300
Date: Thu, 29 Apr 2004 18:05:31 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "Bound, Jim" <jim.bound@hp.com>
cc: v6ops@ops.ietf.org
Subject: RE: Scenarios analysis documents: BCP vs Informational?
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0612C95C@tayexc13.americas.cpqcorp.net>
Message-ID: <Pine.LNX.4.44.0404291803580.30552-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 29 Apr 2004, Bound, Jim wrote:
> I support (a).  Reason.  BCPs are more easily updated as we learn
> Informational lasts forever.  Caveat is IETF is working on all of this
> process so my rationale may be a moot point.  Well I we did replace the
> base API info multiple times??   I just like the sound of BCP I guess
> :--)

Maybe that's because folks get ashamed of out-of-date BCPs but don't 
feel so strongly about Informationals? :)

In any case, Informationals can be updated as well as we gain 
experience; if the deployment is successful, it might actually be 
worth recycling the Informationals to BCPs after some years (if deemed 
necessary).

> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org 
> > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of juha.wiljakka@nokia.com
> > Sent: Thursday, April 29, 2004 6:03 AM
> > To: v6ops@ops.ietf.org
> > Subject: RE: Scenarios analysis documents: BCP vs Informational?
> > 
> > 
> > Hi!
> > 
> > My opinion is c.
> > 
> > Cheers,
> > 	 -Juha W.-
> > 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> > Behalf Of ext Pekka Savola
> > 
> >  a) continue with BCP category,
> > 
> >  b) publish 3GPP analysis as Informational and consider the rest in 
> >     case-by-case basis (whether Info or BCP).  Some other analysis 
> >     documents may or may not fall better under the BCP category, or
> > 
> >  c) publish 3GPP analysis as Informational; take the rest to 
> >     informational as well.
> > 
> > Opinions?  a), b), or c)?
> > 
> > 
> > 
> 

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




From owner-v6ops@ops.ietf.org  Thu Apr 29 11:09:50 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08133
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 11:09:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJD9N-0007ip-UW
	for v6ops-data@psg.com; Thu, 29 Apr 2004 15:08:33 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJD9M-0007iV-Sq
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 15:08:32 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP
	id 69B46368C; Thu, 29 Apr 2004 11:08:32 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 29 Apr 2004 11:08:30 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Scenarios analysis documents: BCP vs Informational?
Date: Thu, 29 Apr 2004 11:08:03 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C99F@tayexc13.americas.cpqcorp.net>
Thread-Topic: Scenarios analysis documents: BCP vs Informational?
Thread-Index: AcQt+3XpqiCdBGFtS46G2AWh9ZhszAAAElLg
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 29 Apr 2004 15:08:30.0609 (UTC) FILETIME=[D4F51810:01C42DFB]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

ack. cool.
/jim=20

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]=20
> Sent: Thursday, April 29, 2004 11:06 AM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: RE: Scenarios analysis documents: BCP vs Informational?
>=20
> On Thu, 29 Apr 2004, Bound, Jim wrote:
> > I support (a).  Reason.  BCPs are more easily updated as we learn=20
> > Informational lasts forever.  Caveat is IETF is working on=20
> all of this=20
> > process so my rationale may be a moot point.  Well I we did=20
> replace the
> > base API info multiple times??   I just like the sound of=20
> BCP I guess
> > :--)
>=20
> Maybe that's because folks get ashamed of out-of-date BCPs=20
> but don't feel so strongly about Informationals? :)
>=20
> In any case, Informationals can be updated as well as we gain=20
> experience; if the deployment is successful, it might=20
> actually be worth recycling the Informationals to BCPs after=20
> some years (if deemed necessary).
>=20
> > > -----Original Message-----
> > > From: owner-v6ops@ops.ietf.org
> > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of=20
> > > juha.wiljakka@nokia.com
> > > Sent: Thursday, April 29, 2004 6:03 AM
> > > To: v6ops@ops.ietf.org
> > > Subject: RE: Scenarios analysis documents: BCP vs Informational?
> > >=20
> > >=20
> > > Hi!
> > >=20
> > > My opinion is c.
> > >=20
> > > Cheers,
> > > 	 -Juha W.-
> > >=20
> > > -----Original Message-----
> > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> > > Behalf Of ext Pekka Savola
> > >=20
> > >  a) continue with BCP category,
> > >=20
> > >  b) publish 3GPP analysis as Informational and consider=20
> the rest in=20
> > >     case-by-case basis (whether Info or BCP).  Some other=20
> analysis=20
> > >     documents may or may not fall better under the BCP=20
> category, or
> > >=20
> > >  c) publish 3GPP analysis as Informational; take the rest to=20
> > >     informational as well.
> > >=20
> > > Opinions?  a), b), or c)?
> > >=20
> > >=20
> > >=20
> >=20
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Apr 29 11:23:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08920
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 11:23:54 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJDMi-0009eD-Ma
	for v6ops-data@psg.com; Thu, 29 Apr 2004 15:22:20 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJDMh-0009e0-GR
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 15:22:19 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2E5DF535A
	for <v6ops@ops.ietf.org>; Thu, 29 Apr 2004 11:22:19 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 29 Apr 2004 11:22:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: Comment on RFC 3750
Date: Thu, 29 Apr 2004 11:21:49 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0612C9A5@tayexc13.americas.cpqcorp.net>
Thread-Topic: Comment on RFC 3750
Thread-Index: AcQt2Y+su85VKHNVRU6qFRxAvcwY+gAI59mw
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 29 Apr 2004 15:22:17.0474 (UTC) FILETIME=[C1CEAE20:01C42DFD]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

We did discuss this with uman and I stated that but here is the input.
Do we care?
/jim

> -----Original Message-----
> From: xxxxxxxxxxxxxxxxx
> Sent: Wednesday, April 28, 2004 10:18 AM
> To: Bound, Jim
> Subject: Comment on RFC 3750
>=20
> Jim,
>=20
> this may be a stupid and obvious observation but I just thought I=20
> would ask.
>=20
> I have recently had some personal experience that shows Christian=20
> model for an unmanaged network in RFC 3750 may not be totally correct.

> I have a DLINK wireless access router at home. It is configured and=20
> functions principly as the model describes except.... the router has=20
> four 10/100 ethernet interfaces besides the 802.11G. Should not each=20
> wireless channel (SSID) be it's own subnet. Each router can handle I=20
> believe 10 SSIDS? IN addition, the
> 802.3 interfaces should their own subnet also.=20
>=20
> Im trying to set up a peer-to-peer gaming system with two or three=20
> PCs... a laptop with wireless and a desktop with wire.
> They can't communicate ....
> the DLINK router only routes out and it can only be configured with a=20
> single default gateway IP address. Isn't this an important function?=20
> Shouldn't these routers be capable of supporting multiple subnets on=20
> wired and wireless interfaces so all ports can interact for=20
> peer-to-peer gaming, client-server, and server-server communications.=20
> Is it just DLINK has a poor implementation or is this a common=20
> approach in Industry. Im spending a lot of time and money trying to=20
> work around this issue.
>=20
> xxxxxxxxxxxxxx
>=20
>=20







From owner-v6ops@ops.ietf.org  Thu Apr 29 13:10:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14252
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 13:10:54 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJF0V-0003NA-UJ
	for v6ops-data@psg.com; Thu, 29 Apr 2004 17:07:31 +0000
Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJF0V-0003My-8f
	for v6ops@ops.ietf.org; Thu, 29 Apr 2004 17:07:31 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3TH7Udc000786
	for <v6ops@ops.ietf.org>; Thu, 29 Apr 2004 11:07:30 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HWX00M25ZKI87@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 29 Apr 2004 11:07:30 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HWX003X7ZKHL5@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 29 Apr 2004 11:07:30 -0600 (MDT)
Date: Thu, 29 Apr 2004 10:07:27 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Scenarios analysis documents: BCP vs Informational?
In-reply-to: <Pine.LNX.4.44.0404291803580.30552-100000@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: "Bound, Jim" <jim.bound@hp.com>, v6ops@ops.ietf.org
Message-id: <B13F7A82-99FF-11D8-8B00-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0404291803580.30552-100000@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 29, 2004, at 8:05 AM, Pekka Savola wrote:
> In any case, Informationals can be updated as well as we gain
> experience;

This is exactly what we did with

2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999.
      (Format: TXT=17844 bytes) (Obsoleted by RFC2772) (Status:
      INFORMATIONAL)

2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February
      2000. (Format: TXT=28565 bytes) (Obsoletes RFC2546) (Updated by
      RFC3152) (Status: INFORMATIONAL)


	- Alain.




From owner-v6ops@ops.ietf.org  Thu Apr 29 22:39:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19535
	for <v6ops-archive@lists.ietf.org>; Thu, 29 Apr 2004 22:39:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJNsw-000A4M-UM
	for v6ops-data@psg.com; Fri, 30 Apr 2004 02:36:18 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJNst-000A3v-HZ
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 02:36:15 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP
	id 0A2B350AB; Thu, 29 Apr 2004 22:36:15 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 29 Apr 2004 22:36:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Thu, 29 Apr 2004 22:35:47 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B638@tayexc13.americas.cpqcorp.net>
Thread-Topic: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Thread-Index: AcQtyvb7DeeClHnDQLqNhbAL/qvkdgAkG/iw
From: "Bound, Jim" <jim.bound@hp.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 02:36:14.0823 (UTC) FILETIME=[E8587770:01C42E5B]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jordi,

> A number of transition mechanism have been defined already: Teredo,
> TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them work when

Your missing DSTM in this analysis why is that?

Also I am not clear you can mix and match transition or automate this
because new mechanisms will be continued to be developed.

thanks
/jim


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Thursday, April 29, 2004 5:14 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> Hi Brian,
>=20
> Yes, I agree we are too ambitious ;-) but we should try at=20
> least ... Let's see how we can progress and in what=20
> circumstances this is possible (for example when disruption=20
> and/or keeping the same address is not a problem). We will=20
> work further on this aspect to concrete the text.
>=20
> Of course, we can count with multi6 and/or MIPv6, so again,=20
> we will need some more work here.
>=20
> Agree, we need to list TLS/SSL.
>=20
> Thanks for your inputs !
>=20
> Regards,
> Jordi
>=20
> ----- Original Message -----
> From: "Brian E Carpenter" <brc@zurich.ibm.com>
> To: "IPv6 Operations" <v6ops@ops.ietf.org>
> Sent: Wednesday, April 28, 2004 2:36 PM
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
>=20
> > >=20
> http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-tra
> ns-00.txt
> >=20
> > This is a very interesting concept, but I have some doubt=20
> about the goal
> > of spontaneously changing to a different mechanism without=20
> disruption.
> > I think it is over-ambitious. As pointed out in section=20
> 3.2, point 1,
> > this requires keeping the same address even if (for=20
> example) changing
> > from one tunnel provider to another - that's very unlikely to
> > work (unless of course we have a fully deployed multi6 solution
> > or use mobile IP exclusively). So I would be tempted to=20
> limit the scope
> > to choosing the best initial method.
> >=20
> > One detail: Section 3.3.3 discusses "layer 4" tunnels but doesn't
> > list IPv6 over TLS/SSL - but that is a very real=20
> possibility (in fact
> > I use IPv4 over SSL very frequently, since it gets through=20
> certain NATs
> > that IPSEC over UDP cannot deal with). It looks like a better option
> > than IP over SSH to me, and certainly better than IP over HTTP.
> >=20
> > I'm not sure that we should even list this class of solution
> > as discouraged. It should perhaps be lower on the list of
> > preferences, but whatever works is good.
> >=20
> >      Brian
> >=20
> >=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 00:19:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23840
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 00:19:18 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJPRq-0003Jk-Ju
	for v6ops-data@psg.com; Fri, 30 Apr 2004 04:16:26 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJPRg-0003Ib-II
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 04:16:16 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3U4G6M10352;
	Fri, 30 Apr 2004 07:16:06 +0300
Date: Fri, 30 Apr 2004 07:16:05 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "Bound, Jim" <jim.bound@hp.com>
cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644B638@tayexc13.americas.cpqcorp.net>
Message-ID: <Pine.LNX.4.44.0404300712260.10230-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 29 Apr 2004, Bound, Jim wrote:
> > A number of transition mechanism have been defined already: Teredo,
> > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them work when
> 
> Your missing DSTM in this analysis why is that?

I think the document is focused on obtaining _IPv6_ connectivity in 
IPv4-only networks, not the other way around.

...

FWIW, I personally agree with Brian's concern of too ambitious goals.  
Too ambituous goals often result in nothing getting done, instead of
what might have been realistic.  So, if it stays, it probably needs
"health warnings" or th like :)

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




From owner-v6ops@ops.ietf.org  Fri Apr 30 08:25:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13103
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 08:25:31 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJX22-0003ol-MP
	for v6ops-data@psg.com; Fri, 30 Apr 2004 12:22:18 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJX20-0003oI-7z
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 12:22:16 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP
	id A7F345396; Fri, 30 Apr 2004 08:22:15 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 08:22:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 08:21:47 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B65B@tayexc13.americas.cpqcorp.net>
Thread-Topic: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Thread-Index: AcQuaeGMkvz7hN9DR5OJ8QejG8BJUwAQ0ORg
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 12:22:15.0213 (UTC) FILETIME=[C59235D0:01C42EAD]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

then the document title should say that in some form in the title
because it will not be useful to users building native IPv6 networks
with IPv6 as the dominant backbone routing protocol e.g. 3GPP IMS, U.S.
DOD nets, ISPs building for IPv6 device attacments to the network, or
Moonv6 Network Pilot as examples of early adoption and deployment.  But
I thought I saw parts in the spec that did speak to IPv6 networks I will
check again?

I also agree with you this document is in a sense boiling the ocean and
that does not work.  I also right now do not believe this is possible.

/jim=20

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]=20
> Sent: Friday, April 30, 2004 12:16 AM
> To: Bound, Jim
> Cc: JORDI PALET MARTINEZ; v6ops@ops.ietf.org
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > A number of transition mechanism have been defined=20
> already: Teredo,=20
> > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them=20
> work when
> >=20
> > Your missing DSTM in this analysis why is that?
>=20
> I think the document is focused on obtaining _IPv6_=20
> connectivity in IPv4-only networks, not the other way around.
>=20
> ...
>=20
> FWIW, I personally agree with Brian's concern of too=20
> ambitious goals. =20
> Too ambituous goals often result in nothing getting done,=20
> instead of what might have been realistic.  So, if it stays,=20
> it probably needs "health warnings" or th like :)
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 08:25:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13123
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 08:25:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJX0b-0003a1-Dx
	for v6ops-data@psg.com; Fri, 30 Apr 2004 12:20:49 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJX0Z-0003ZO-Qc; Fri, 30 Apr 2004 12:20:48 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UCKiK17008;
	Fri, 30 Apr 2004 15:20:44 +0300
Date: Fri, 30 Apr 2004 15:20:44 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: juha.wiljakka@nokia.com
cc: v6ops@ops.ietf.org, <mankin@psg.com>, <jon.peterson@neustar.biz>,
        <Jonne.Soininen@nokia.com>, <david.kessens@nokia.com>
Subject: Re: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS
 Scenario 1
In-Reply-To: <Pine.LNX.4.44.0404211353400.14563-100000@netcore.fi>
Message-ID: <Pine.LNX.4.44.0404301513260.15942-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

(co-chair hat on)

There were no replies to this query for preferences how to solve this,
so let's consider the following, slightly modified, text proposed by
Allison.

If you have objections/enhancements to this, please comment on Monday
5th April at the latest so that we could move on with this.  Thanks!

(Based on this proposal, I'm confident that addressing Jon's issues
with SDP editing could be settled easily.)

======
4.1 UE Connecting to a Node in an IPv4 Network through IMS

    This scenario occurs when an IMS UE (IPv6) connects to a node in
    the IPv4 Internet through the IMS, or vice versa. This happens when
    the other node is a part of a different system than 3GPP, e.g. a
    fixed PC, with only IPv4 capabilities.

    The first priority is to upgrade the legacy IPv4 nodes to dual-
    stack, eliminating this particular problem in that specific
    deployment.

    Still, it is difficult to estimate how many non-upgradeable legacy
    IPv4 nodes need to communicate with the IMS UEs. It is assumed that
    the solution described here is used for limited cases, in which
    communications with a small number of legacy IPv4 SIP equipment are
    needed.

[these first three paragraphs were unmodified]

    As the IMS is exclusively IPv6 [3GPP 23.221], for many of the
    applications in the IMS, some kind of translators may need to
    be used in the communication between the IPv6 IMS and the
    legacy IPv4 hosts in cases where these legacy IPv4 hosts cannot
    be upgraded to IPv6.

    This section gives a brief analysis of the IMS interworking
    issues, and presents a high level view of SIP within the IMS.
    The authors recommend that the IETF specify a detailed solution
    of the general SIP/SDP/media IPv4/IPv6 transition problem as
    a task within the SIP WGs as soon as possible.
  
    As control (or signaling) and user (or data) traffic are separated
    in SIP calls, and thus, the IMS, the transition of IMS traffic
    from IPv6 to IPv4 must be handled at two levels:

              1)Session Initiation Protocol (SIP) [RFC3261], and 
                 Session Description Protocol (SDP) [RFC2327] [RFC3266] 
                 (Mm-interface) 
              2)the user data traffic (Mb-interface) 

    SIP carries an SDP body containing the addressing and other 
    parameters for establishing the user data traffic (the media).

    Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP
    proxy at the border between the 3GPP IPv6-only IMS network and the 
    IPv4 systems.

    In a possible approach to communicating, this edge could contain a SIP
    ALG, which would change the IP addresses transported in the SIP
    messages and the SDP payload of those messages to the appropriate
    version.   This approach would have the drawback (like other SDP
    rewriting solutions) of impacting authentication mechanisms that
    may be needed for other purposes.   Moreover, this approach would
    not take advantage of SIP's ability to use proxy routing, nor of SDP's
    ability to carry multiple alternative addresses.  These intrinsic
    features of SIP and SDP require a more detailed analysis, but they
    would yield benefits.  The SIP ALG approach requires NAT-PT 
    (with the issues described in appendix A), because the IMS-side
    IPv6 addresses must be assigned IPv4 addresses for reachability
    from the legacy IPv4 side shown in Figure 1.  The approach based
    on intrinsic SIP proxy routing would not require assignment of
    temporary IPv4 addresses to the IPv6 IMS endpoints; instead they
    would be reached via an IPv4-side address of a SIP proxy
    acting for them.  This SIP proxy would be doing normal SIP 
    processing; it would be as scalable as any SIP proxy.
    
    On the user data transport level, the analysis raises other issues:
    the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol
    translation (with the scalability concerns raised in Appendix A)
    may look simplest, but needs a skeptical look.  Alternatives 
    include routing to a transcoder, whose task is to terminate an
    IPv6 stream and start an IPv4 stream.  Again, this requires
    a more detailed analysis.

    For each of the protocols, there has to be interoperability
    for DNS queries; see section 2.4 for details.  
     


          +-------------------------------+ +------------+ 
          |                      +------+ | | +--------+ | 
          |                      |S-CSCF|---| |SIP edge| |\ 
       |  |                      +------+ | | +--------+ | \ -------- 
     +-|+ |                       /       | |     |      |  |        | 
     |  | | +------+        +------+      | |     +      |   -|    |- 
     |  |-|-|P-CSCF|--------|I-CSCF|      | |     |      |    | () | 
     |  |   +------+        +------+      | |+----------+| /  ------ 
     |  |-----------------------------------||[ALG?]    ||/ 
     +--+ |            IPv6               | |+----------+|     IPv4 
      UE  |                               | |Interworking| 
          |  IP Multimedia CN Subsystem   | |Unit        | 
          +-------------------------------+ +------------+ 
     
           Figure 1: UE using IMS to contact a legacy phone 
         

    Figure 1 shows a generic SIP signaling edge - a ALG-like replacement
    of the IPv6 addresses with IPv4 addresses using limited subsets of
    NAT-PT [RFC2766] is a possible approach, but exploiting SIP's proxy
    routing to allow the dual homed SIP edge to make the address change
    without a translator is a promising alternative without the scaling
    problems of NAT-PT (appendix A).
==============




From owner-v6ops@ops.ietf.org  Fri Apr 30 08:28:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13295
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 08:28:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJX7d-0004qM-Sq
	for v6ops-data@psg.com; Fri, 30 Apr 2004 12:28:05 +0000
Received: from [217.126.187.160] (helo=consulintel.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJX7b-0004ps-Sy
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 12:28:04 +0000
Received: from consulintel.es ([213.172.48.142])
	(authenticated user consulintel.es)
	by consulintel.com (consulintel.com [10.10.10.250])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000016500.msg
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 14:31:03 +0200
Received: from consulintel02 ([192.168.11.22])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000052069.msg
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 14:28:03 +0200
Message-ID: <064601c42eae$814f1f90$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <Pine.LNX.4.44.0404300712260.10230-100000@netcore.fi>
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 14:27:29 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Fri, 30 Apr 2004 14:28:03 +0200
	(not processed: spam filter disabled)
X-MDAV-Processed: consulintel.es, Fri, 30 Apr 2004 14:28:04 +0200
X-Authenticated-Sender: consulintel.es
X-Spam-Processed: consulintel.com, Fri, 30 Apr 2004 14:31:03 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 213.172.48.142
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.com, Fri, 30 Apr 2004 14:31:05 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

See below, in-line.

Regards,
Jordi

----- Original Message -----=20
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Bound, Jim" <jim.bound@hp.com>
Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 6:16 AM
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt


> On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > A number of transition mechanism have been defined already: Teredo,
> > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them work when
> >=20
> > Your missing DSTM in this analysis why is that?
>=20

Yes, Pekka is right, that's the point. We are assuming that the host is already dual stack, and we are looking for ensuring IPv6 connectivity, so we consider only scenarios where you have IPv6 native connectivity (but the performance is poor for whatever reason and we can improve it with a transition mechanism, for example to a nearer tunnel server) or where you have IPv4 convexity and want to get IPv6.

The document is focusing in the evaluation of those mechanism that we consider today have a better chance to provide better results. A follow up document will work on solutions, and possibly protocol description, and those documents could take care of more alternatives, even new transition mechanism that today don't exist, however we believe is difficult it happens (difficult to see mechanism that offer "more" that what we have now).

Anyway, we will improve the text in the next release to clarify this.

> I think the document is focused on obtaining _IPv6_ connectivity in=20
> IPv4-only networks, not the other way around.
>=20
> ...
>=20
> FWIW, I personally agree with Brian's concern of too ambitious goals. =20
> Too ambituous goals often result in nothing getting done, instead of
> what might have been realistic.  So, if it stays, it probably needs
> "health warnings" or th like :)
>=20


As I already indicated replying to Brian, we will make sure to be more realistic and/or clear on this point in the next release.

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


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.







From owner-v6ops@ops.ietf.org  Fri Apr 30 08:38:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14852
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 08:38:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJXHU-0006y0-Ph
	for v6ops-data@psg.com; Fri, 30 Apr 2004 12:38:16 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJXHS-0006xj-CC
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 12:38:14 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP
	id 8796CA42E; Fri, 30 Apr 2004 08:38:10 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 08:37:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 08:37:15 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B65C@tayexc13.americas.cpqcorp.net>
Thread-Topic: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Thread-Index: AcQurq9r297wR3scSii94zUl+Pmq/AAAB/lw
From: "Bound, Jim" <jim.bound@hp.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 12:37:43.0210 (UTC) FILETIME=[EEB350A0:01C42EAF]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jordi,

Your words from below:

>so we consider only scenarios=20
> where you have IPv6 native connectivity (but the performance=20
> is poor for whatever reason and we can improve it with a=20
> transition mechanism, for example to a nearer tunnel server)=20
> or where you have IPv4 convexity and want to get IPv6.

Assumption 1 from your words:

There is an IPv6 Native Network.

Assumption 2 from your words.

There is an IPv4 network the packet can use for better performance.

Then DSTM is in fact an option and here is why:

DSTM Assumption 1:

As DSTM postulates it is possible that the user has deployed only IPv6
applications on a network.

DSTM Assumption 2:

There is an IPv4 routable address within the network scope of
communications that can be used by obtaining it from DHCPv6 or IPv6
Tunnel Broker.

Then the dual stack approach is used or Native IPv4.

Given your words you need to add DSTM or remove discussion of Native
IPv6 is my input.

I am now going to review your draft in depth to give you hard core
technical input as IPv6 engineering expert because your response was to
casual and not technical enough for me anyway. =20

/jim

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 30, 2004 8:27 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> See below, in-line.
>=20
> Regards,
> Jordi
>=20
> ----- Original Message -----
> From: "Pekka Savola" <pekkas@netcore.fi>
> To: "Bound, Jim" <jim.bound@hp.com>
> Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;=20
> <v6ops@ops.ietf.org>
> Sent: Friday, April 30, 2004 6:16 AM
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
>=20
> > On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > > A number of transition mechanism have been defined=20
> already: Teredo,
> > > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of=20
> them work when
> > >=20
> > > Your missing DSTM in this analysis why is that?
> >=20
>=20
> Yes, Pekka is right, that's the point. We are assuming that=20
> the host is already dual stack, and we are looking for=20
> ensuring IPv6 connectivity, so we consider only scenarios=20
> where you have IPv6 native connectivity (but the performance=20
> is poor for whatever reason and we can improve it with a=20
> transition mechanism, for example to a nearer tunnel server)=20
> or where you have IPv4 convexity and want to get IPv6.
>=20
> The document is focusing in the evaluation of those mechanism=20
> that we consider today have a better chance to provide better=20
> results. A follow up document will work on solutions, and=20
> possibly protocol description, and those documents could take=20
> care of more alternatives, even new transition mechanism that=20
> today don't exist, however we believe is difficult it happens=20
> (difficult to see mechanism that offer "more" that what we have now).
>=20
> Anyway, we will improve the text in the next release to clarify this.
>=20
> > I think the document is focused on obtaining _IPv6_ connectivity in=20
> > IPv4-only networks, not the other way around.
> >=20
> > ...
> >=20
> > FWIW, I personally agree with Brian's concern of too=20
> ambitious goals. =20
> > Too ambituous goals often result in nothing getting done, instead of
> > what might have been realistic.  So, if it stays, it probably needs
> > "health warnings" or th like :)
> >=20
>=20
>=20
> As I already indicated replying to Brian, we will make sure=20
> to be more realistic and/or clear on this point in the next release.
>=20
> > --=20
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >=20
> >=20
> >=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 08:49:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26003
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 08:49:37 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJXSC-00092M-L8
	for v6ops-data@psg.com; Fri, 30 Apr 2004 12:49:20 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJXS3-00090l-E0
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 12:49:11 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UCn9J17568;
	Fri, 30 Apr 2004 15:49:09 +0300
Date: Fri, 30 Apr 2004 15:49:09 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
cc: Alain Durand <Alain.Durand@Sun.COM>
Subject: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
In-Reply-To: <Pine.LNX.4.44.0404211707080.18618-100000@netcore.fi>
Message-ID: <Pine.LNX.4.44.0404301540010.17348-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

(co-chair hat on)

As there was slight preference to having this as WG item, and it is
very important to gain consensus on the requirements for a tunnel
server solution, please publish the next revision under 
draft-ietf-v6ops -label, making this a WG item.

The WG participants are already urged to review and provide feedback
on the document.  If you want to "catch" this revision cycle, please
send your comments by next Wednesday, 5th May.

The intent is to WG last call it after having been published as WG
item, and reach WG consensus on the requirements within a month.

Thanks!

(co-chair hat off)





From owner-v6ops@ops.ietf.org  Fri Apr 30 08:49:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26152
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 08:49:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJXSY-00094l-Oj
	for v6ops-data@psg.com; Fri, 30 Apr 2004 12:49:42 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJXSX-00094H-DA
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 12:49:41 +0000
Received: from consulintel02 ([192.168.11.22])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000052129.msg
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 14:50:09 +0200
Message-ID: <072501c42eb1$95794ba0$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <9C422444DE99BC46B3AD3C6EAFC9711B0644B65B@tayexc13.americas.cpqcorp.net>
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 14:49:32 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Fri, 30 Apr 2004 14:50:09 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 192.168.11.22
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Fri, 30 Apr 2004 14:50:11 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jim,

You're right. Our idea is a dual stack node, with IPv4 connectivity (and with or without IPv6 native).

The point is the case when I travel to an IETF, for example, and I've native IPv6, but the performance is very poor. I can always opt for using a better transition mechanism (example a "near" TB/TS).

Will make sure to clarify it better.

As Brian and Pekka said, we are too much ambitious or not clear enough, and already working on improving the document.

Regards,
Jordi

----- Original Message -----=20
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 2:21 PM
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt


then the document title should say that in some form in the title
because it will not be useful to users building native IPv6 networks
with IPv6 as the dominant backbone routing protocol e.g. 3GPP IMS, U.S.
DOD nets, ISPs building for IPv6 device attacments to the network, or
Moonv6 Network Pilot as examples of early adoption and deployment.  But
I thought I saw parts in the spec that did speak to IPv6 networks I will
check again?

I also agree with you this document is in a sense boiling the ocean and
that does not work.  I also right now do not believe this is possible.

/jim=20

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]=20
> Sent: Friday, April 30, 2004 12:16 AM
> To: Bound, Jim
> Cc: JORDI PALET MARTINEZ; v6ops@ops.ietf.org
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > A number of transition mechanism have been defined=20
> already: Teredo,=20
> > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them=20
> work when
> >=20
> > Your missing DSTM in this analysis why is that?
>=20
> I think the document is focused on obtaining _IPv6_=20
> connectivity in IPv4-only networks, not the other way around.
>=20
> ...
>=20
> FWIW, I personally agree with Brian's concern of too=20
> ambitious goals. =20
> Too ambituous goals often result in nothing getting done,=20
> instead of what might have been realistic.  So, if it stays,=20
> it probably needs "health warnings" or th like :)
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20
>=20



**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Fri Apr 30 08:54:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28239
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 08:54:12 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJXWk-000A57-3k
	for v6ops-data@psg.com; Fri, 30 Apr 2004 12:54:02 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJXWi-000A4m-Ma
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 12:54:00 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UCruZ17652;
	Fri, 30 Apr 2004 15:53:56 +0300
Date: Fri, 30 Apr 2004 15:53:56 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
In-Reply-To: <072501c42eb1$95794ba0$8700000a@consulintel.es>
Message-ID: <Pine.LNX.4.44.0404301551500.17614-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 30 Apr 2004, JORDI PALET MARTINEZ wrote:
> The point is the case when I travel to an IETF, for example, and
> I've native IPv6, but the performance is very poor. I can always opt
> for using a better transition mechanism (example a "near" TB/TS).

FWIW, I'm concerned about methods to "optimize" poor native IPv6 
connectivity.  We need to fix the native connectivity instead... :-/

On the other hand, there _are_ a few practical ways for optimization
which are rather simple: a "local" 6to4 relay, and a "local" Teredo
relay.  Those can significantly help when you're on native v6 but 
communicating with someone who isn't.

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




From owner-v6ops@ops.ietf.org  Fri Apr 30 09:02:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29326
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 09:02:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJXec-000Bn3-4G
	for v6ops-data@psg.com; Fri, 30 Apr 2004 13:02:10 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJXea-000Bme-IY
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 13:02:09 +0000
Received: from consulintel02 ([192.168.11.22])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000052165.msg
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 15:02:36 +0200
Message-ID: <077f01c42eb3$534ee6c0$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <9C422444DE99BC46B3AD3C6EAFC9711B0644B65C@tayexc13.americas.cpqcorp.net>
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 15:02:00 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Fri, 30 Apr 2004 15:02:36 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 192.168.11.22
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Fri, 30 Apr 2004 15:02:39 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Jim,

May be I worded it in the wrong way. My assumption right now is that you have always IPv4 connectivity.

The original goal was to ensure the best IPv6 connectivity in any situation (today's reality with most of the networks being only IPv4).

But I can see the auto-transition idea being applied also to ensure the best IPv4 connectivity if this is required (in the ideal world when we have most of the networks, or at least a good number of them, with IPv6). In this case is clear that DSTM is a very good option, I believe.

Initially we haven't considered this send option, but now I'm wondering if we should ? What is the opinion of others ? (just in case, to make it clear, when we have only IPv6 connectivity and want to ensure also IPv4).

Anyway, we will re-read DSTM documents to see if we missed something.

Will be happy to get your inputs on this, of course.

Regards,
Jordi

----- Original Message -----=20
From: "Bound, Jim" <jim.bound@hp.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 2:37 PM
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt


Jordi,

Your words from below:

>so we consider only scenarios=20
> where you have IPv6 native connectivity (but the performance=20
> is poor for whatever reason and we can improve it with a=20
> transition mechanism, for example to a nearer tunnel server)=20
> or where you have IPv4 convexity and want to get IPv6.

Assumption 1 from your words:

There is an IPv6 Native Network.

Assumption 2 from your words.

There is an IPv4 network the packet can use for better performance.

Then DSTM is in fact an option and here is why:

DSTM Assumption 1:

As DSTM postulates it is possible that the user has deployed only IPv6
applications on a network.

DSTM Assumption 2:

There is an IPv4 routable address within the network scope of
communications that can be used by obtaining it from DHCPv6 or IPv6
Tunnel Broker.

Then the dual stack approach is used or Native IPv4.

Given your words you need to add DSTM or remove discussion of Native
IPv6 is my input.

I am now going to review your draft in depth to give you hard core
technical input as IPv6 engineering expert because your response was to
casual and not technical enough for me anyway. =20

/jim

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 30, 2004 8:27 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> See below, in-line.
>=20
> Regards,
> Jordi
>=20
> ----- Original Message -----
> From: "Pekka Savola" <pekkas@netcore.fi>
> To: "Bound, Jim" <jim.bound@hp.com>
> Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;=20
> <v6ops@ops.ietf.org>
> Sent: Friday, April 30, 2004 6:16 AM
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
>=20
> > On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > > A number of transition mechanism have been defined=20
> already: Teredo,
> > > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of=20
> them work when
> > >=20
> > > Your missing DSTM in this analysis why is that?
> >=20
>=20
> Yes, Pekka is right, that's the point. We are assuming that=20
> the host is already dual stack, and we are looking for=20
> ensuring IPv6 connectivity, so we consider only scenarios=20
> where you have IPv6 native connectivity (but the performance=20
> is poor for whatever reason and we can improve it with a=20
> transition mechanism, for example to a nearer tunnel server)=20
> or where you have IPv4 convexity and want to get IPv6.
>=20
> The document is focusing in the evaluation of those mechanism=20
> that we consider today have a better chance to provide better=20
> results. A follow up document will work on solutions, and=20
> possibly protocol description, and those documents could take=20
> care of more alternatives, even new transition mechanism that=20
> today don't exist, however we believe is difficult it happens=20
> (difficult to see mechanism that offer "more" that what we have now).
>=20
> Anyway, we will improve the text in the next release to clarify this.
>=20
> > I think the document is focused on obtaining _IPv6_ connectivity in=20
> > IPv4-only networks, not the other way around.
> >=20
> > ...
> >=20
> > FWIW, I personally agree with Brian's concern of too=20
> ambitious goals. =20
> > Too ambituous goals often result in nothing getting done, instead of
> > what might have been realistic.  So, if it stays, it probably needs
> > "health warnings" or th like :)
> >=20
>=20
>=20
> As I already indicated replying to Brian, we will make sure=20
> to be more realistic and/or clear on this point in the next release.
>=20
> > --=20
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >=20
> >=20
> >=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20
>=20




**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Fri Apr 30 09:06:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29593
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 09:06:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJXiR-000Cen-KK
	for v6ops-data@psg.com; Fri, 30 Apr 2004 13:06:07 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJXiP-000CeE-LK
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 13:06:05 +0000
Received: from consulintel02 ([192.168.11.22])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000052174.msg
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 15:06:31 +0200
Message-ID: <079301c42eb3$dfe29a50$8700000a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <Pine.LNX.4.44.0404301551500.17614-100000@netcore.fi>
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 15:05:55 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Fri, 30 Apr 2004 15:06:31 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 192.168.11.22
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Fri, 30 Apr 2004 15:06:36 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Pekka,

See in-line.

Regards,
Jordi

----- Original Message -----=20
From: "Pekka Savola" <pekkas@netcore.fi>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 2:53 PM
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt


> On Fri, 30 Apr 2004, JORDI PALET MARTINEZ wrote:
> > The point is the case when I travel to an IETF, for example, and
> > I've native IPv6, but the performance is very poor. I can always opt
> > for using a better transition mechanism (example a "near" TB/TS).
>=20
> FWIW, I'm concerned about methods to "optimize" poor native IPv6=20
> connectivity.  We need to fix the native connectivity instead... :-/

I agree, it will be much better to optimize fix native connectivity, but what the users does, when he doesn't know nothing about that, and he has, of course, no control of the visited network ?

Remember that this is targeted to clients, even it could be used, for example, in CPE devices, assuming that is automatic, because the user has no technical expertise ...

>=20
> On the other hand, there _are_ a few practical ways for optimization
> which are rather simple: a "local" 6to4 relay, and a "local" Teredo
> relay.  Those can significantly help when you're on native v6 but=20
> communicating with someone who isn't.

That's why we included 6to4 and Teredo as options ;-)

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


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Fri Apr 30 09:18:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00128
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 09:18:21 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJXtv-000EbP-RY
	for v6ops-data@psg.com; Fri, 30 Apr 2004 13:17:59 +0000
Received: from [195.64.92.136] (helo=purgatory.unfix.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJXtu-000Eb3-C8
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 13:17:58 +0000
Received: from localhost (localhost [127.0.0.1])
	by purgatory.unfix.org (Postfix) with ESMTP
	id 900417F67; Fri, 30 Apr 2004 15:17:53 +0200 (CEST)
Received: from purgatory.unfix.org ([127.0.0.1])
	by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id 27325-87; Fri, 30 Apr 2004 15:17:42 +0200 (CEST)
Received: from dhcp70-109.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP
	id 525E07F4F; Fri, 30 Apr 2004 15:17:41 +0200 (CEST)
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.44.0404301551500.17614-100000@netcore.fi>
References: <Pine.LNX.4.44.0404301551500.17614-100000@netcore.fi>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-I399Ibhdu/bbKRSsq0M+"
Organization: Unfix
Message-Id: <1083331058.4555.13.camel@segesta.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 30 Apr 2004 15:17:39 +0200
X-Virus-Scanned: purgatory.unfix.org - http://unfix.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-I399Ibhdu/bbKRSsq0M+
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2004-04-30 at 14:53, Pekka Savola wrote:
> On Fri, 30 Apr 2004, JORDI PALET MARTINEZ wrote:
> > The point is the case when I travel to an IETF, for example, and
> > I've native IPv6, but the performance is very poor. I can always opt
> > for using a better transition mechanism (example a "near" TB/TS).
>=20
> FWIW, I'm concerned about methods to "optimize" poor native IPv6=20
> connectivity.  We need to fix the native connectivity instead... :-/

Well there is this issue of 'policy' which the IETF can't fix.
For instance most of the 'educational and research' networks/NRENs
currently have IPv6 deployed and working but if you have the following
situation:

Commercial ISP <-> { IPv6 Internet } <-> NREN

Your traffic will most likely flow like:

Commercial ISP -> Transit -> NREN=20

but the return route will be:

NREN -> 6net -> Commercial ISP

And guess which route the "Transit" networks take. Good example was the
"Global IPv6 Launch Event" in Brussels. Connected to Belnet, thus all
the NREN connectivity is good. But if you wanted to reach a host in the
Netherlands all the traffic would be routed directly over 6net ->
Surfnet to the Commercial ISP but all the return traffic isn't accepted
by 6net thus that was routed 'nicely' over the US...

Nice policy, but as mentioned nothing the IETF can fix except for what I
did: clickety click in my heartbeat tool and tada a perfectly working
tunnel to a dutch Commercial ISP as IPv4 didn't have the
IPv6-over-the-US problem.

This might be solved one day however when IPv6 gets more deployed and
the routes get shorted, but this example for instance makes it quite bad
when interacting between Commercial networks and NREN's. Notez bien that
between Commercial networks or between the NREN's most connectivity is
quite good actually.

> On the other hand, there _are_ a few practical ways for optimization
> which are rather simple: a "local" 6to4 relay, and a "local" Teredo
> relay.  Those can significantly help when you're on native v6 but=20
> communicating with someone who isn't.

Doesn't help when the policy is stupid ;)

Greets,
 Jeroen


--=-I399Ibhdu/bbKRSsq0M+
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBAklHyKaooUjM+fCMRAmOGAKCr71dn16UDcuYAl1E/SYX4QsYkvwCeO8Fi
mNeIthd8j1W6AoP8UuFQPBA=
=jdx7
-----END PGP SIGNATURE-----

--=-I399Ibhdu/bbKRSsq0M+--




From owner-v6ops@ops.ietf.org  Fri Apr 30 10:39:16 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04949
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 10:39:15 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJZ8Z-0001Vn-8Z
	for v6ops-data@psg.com; Fri, 30 Apr 2004 14:37:11 +0000
Received: from [195.64.92.136] (helo=purgatory.unfix.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJZ8X-0001VO-PL
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 14:37:09 +0000
Received: from localhost (localhost [127.0.0.1])
	by purgatory.unfix.org (Postfix) with ESMTP
	id 5637E7F67; Fri, 30 Apr 2004 16:37:07 +0200 (CEST)
Received: from purgatory.unfix.org ([127.0.0.1])
	by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id 28076-37; Fri, 30 Apr 2004 16:36:52 +0200 (CEST)
Received: from dhcp70-109.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP
	id CDEE47F4F; Fri, 30 Apr 2004 16:36:51 +0200 (CEST)
Subject: Re: REVIEW NEEDED:
	draft-durand-v6ops-assisted-tunneling-requirements-00.txt
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org, Alain Durand <Alain.Durand@Sun.COM>
In-Reply-To: <Pine.LNX.4.44.0404301540010.17348-100000@netcore.fi>
References: <Pine.LNX.4.44.0404301540010.17348-100000@netcore.fi>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-R+jSZmL+GsdtfZLdwL5R"
Organization: Unfix
Message-Id: <1083335808.4555.59.camel@segesta.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 30 Apr 2004 16:36:49 +0200
X-Virus-Scanned: purgatory.unfix.org - http://unfix.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-R+jSZmL+GsdtfZLdwL5R
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2004-04-30 at 14:49, Pekka Savola wrote:
> (co-chair hat on)
>=20
> As there was slight preference to having this as WG item, and it is
> very important to gain consensus on the requirements for a tunnel
> server solution, please publish the next revision under=20
> draft-ietf-v6ops -label, making this a WG item.
>=20
> The WG participants are already urged to review and provide feedback
> on the document.  If you want to "catch" this revision cycle, please
> send your comments by next Wednesday, 5th May.

You have my 'vote' too for making this document a WG item.

My comments:

4 mentions "(initial tryout)" is that in the wording of "try
unauthenticated first, then authenticated" or is it meant for something
else? 4 also mentions that the 'unauthenticated' mode can be aimed for
tryout. Does this mean that using source IP is 'authenticated'?

4.2: The 'non-authenticated' part should be taken away here as it should
also be available for authenticated modes. Eg user knows his user/pass
for the ISP and then runs the tool(tm) or automatically, tool pops up
and notices "I automatically found Example ISP, can you login"?

4.4: s/victim's uplink/victim's downlink/
or better 'link' as it can be done two way.

Though I do not know of many protocols that will actually send a lot of
traffic to a host without asking for a ack every now and then ;)
Multicast is not that widely deployed unfortunatly though that would
still ask for keepalives from the=20
One base item of course: ingress filtering, to which I would also add
that the Tunnel Servers should do egress filtering, limiting what the
tunnel can send onto the internet unless there is an agreement with the
ISP that it is allowed to send other prefixes. Note that this is
currently a big problem in the IPv6 Internet, where a lot of ISP's allow
any prefix to be sent onto the internet -> spoofing, not only 'transit'.

Also in 4.4:
s/IPv4 return routability checks/IPv6 return routability checks/

I like the 'clear text password is out' btw. IMHO MD5 suffices for most
setups, SHA1 or up could be used instead, there thus should be a
possiblity to select a authentication protocol.

Greets,
 Jeroen



--=-R+jSZmL+GsdtfZLdwL5R
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBAkmSAKaooUjM+fCMRAtv9AKC+SR4pxROU8dP276vORKBbojc7lACeJC9R
BjbQUjgGUqjGqkipRVsk5Gk=
=WZ2B
-----END PGP SIGNATURE-----

--=-R+jSZmL+GsdtfZLdwL5R--




From owner-v6ops@ops.ietf.org  Fri Apr 30 10:52:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05737
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 10:52:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJZNU-0004Kn-8e
	for v6ops-data@psg.com; Fri, 30 Apr 2004 14:52:36 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJZNT-0004KJ-27
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 14:52:35 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UEqVb19385;
	Fri, 30 Apr 2004 17:52:31 +0300
Date: Fri, 30 Apr 2004 17:52:31 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Jeroen Massar <jeroen@unfix.org>
cc: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
In-Reply-To: <1083331058.4555.13.camel@segesta.zurich.ibm.com>
Message-ID: <Pine.LNX.4.44.0404301746460.19318-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On 30 Apr 2004, Jeroen Massar wrote:
[...]
> And guess which route the "Transit" networks take. Good example was the
> "Global IPv6 Launch Event" in Brussels. Connected to Belnet, thus all
> the NREN connectivity is good. But if you wanted to reach a host in the
> Netherlands all the traffic would be routed directly over 6net ->
> Surfnet to the Commercial ISP but all the return traffic isn't accepted
> by 6net thus that was routed 'nicely' over the US...

Are you arguing that one-way short-cut is bad practice (this is going
away very soon, I think), that commercial ISP's transits/peerings are
not good enough, or that NRENs should provide full two-way transit
(like Internet2 is more or less doing)?  Note that the latter is very
questionable AUP-wise.

> This might be solved one day however when IPv6 gets more deployed and
> the routes get shorted, but this example for instance makes it quite bad
> when interacting between Commercial networks and NREN's. Notez bien that
> between Commercial networks or between the NREN's most connectivity is
> quite good actually.

This is a problem of commercial networks' lack of good transit, IMHO.

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





From owner-v6ops@ops.ietf.org  Fri Apr 30 10:57:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05921
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 10:57:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJZRs-0004oI-7B
	for v6ops-data@psg.com; Fri, 30 Apr 2004 14:57:08 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJZRq-0004nl-PT
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 14:57:07 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UEv3G19460;
	Fri, 30 Apr 2004 17:57:03 +0300
Date: Fri, 30 Apr 2004 17:57:03 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
In-Reply-To: <079301c42eb3$dfe29a50$8700000a@consulintel.es>
Message-ID: <Pine.LNX.4.44.0404301752440.19318-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 30 Apr 2004, JORDI PALET MARTINEZ wrote:
> > FWIW, I'm concerned about methods to "optimize" poor native IPv6 
> > connectivity.  We need to fix the native connectivity instead... :-/
> 
> I agree, it will be much better to optimize fix native connectivity,
> but what the users does, when he doesn't know nothing about that,
> and he has, of course, no control of the visited network ?
> 
> Remember that this is targeted to clients, even it could be used,
> for example, in CPE devices, assuming that is automatic, because the
> user has no technical expertise ...

Let's avoid getting to the situation where native v6 would be of very
bad quality, and John Doe would have to have systems to work around
that.

I've raised concerns about the bad present considition as well (in
draft-savola-v6ops-6bone-mess-01, now probably expired), but remember
that the ISPs aren't probably going to offer native v6 to all their
customers unless they've been sufficiently well-connected first. (The
technically knowledgeable v6 enthusiasts who are using these pilot
services aren't worth looking at here.)

I don't want to see a situation for the mainstream users where you'd
have to e.g. use tunnel server (remember, that would have to be
automatically set-up as well -- the chances of its quality are not too
high either!) to get better connectivity than native 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




From owner-v6ops@ops.ietf.org  Fri Apr 30 11:00:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06067
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 11:00:22 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJZUh-0005BP-BJ
	for v6ops-data@psg.com; Fri, 30 Apr 2004 15:00:03 +0000
Received: from [195.64.92.136] (helo=purgatory.unfix.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJZUg-0005AT-1p
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 15:00:02 +0000
Received: from localhost (localhost [127.0.0.1])
	by purgatory.unfix.org (Postfix) with ESMTP
	id 210C87F67; Fri, 30 Apr 2004 16:59:59 +0200 (CEST)
Received: from purgatory.unfix.org ([127.0.0.1])
	by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id 28076-51; Fri, 30 Apr 2004 16:59:30 +0200 (CEST)
Received: from dhcp70-109.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP
	id E02E47F4F; Fri, 30 Apr 2004 16:59:29 +0200 (CEST)
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.44.0404301746460.19318-100000@netcore.fi>
References: <Pine.LNX.4.44.0404301746460.19318-100000@netcore.fi>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-embyzjyy2MlLnnLgBIMX"
Organization: Unfix
Message-Id: <1083337167.4555.86.camel@segesta.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 30 Apr 2004 16:59:27 +0200
X-Virus-Scanned: purgatory.unfix.org - http://unfix.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-embyzjyy2MlLnnLgBIMX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2004-04-30 at 16:52, Pekka Savola wrote:
> On 30 Apr 2004, Jeroen Massar wrote:
> [...]
> > And guess which route the "Transit" networks take. Good example was the
> > "Global IPv6 Launch Event" in Brussels. Connected to Belnet, thus all
> > the NREN connectivity is good. But if you wanted to reach a host in the
> > Netherlands all the traffic would be routed directly over 6net ->
> > Surfnet to the Commercial ISP but all the return traffic isn't accepted
> > by 6net thus that was routed 'nicely' over the US...
>=20
> Are you arguing that one-way short-cut is bad practice (this is going
> away very soon, I think), that commercial ISP's transits/peerings are
> not good enough, or that NRENs should provide full two-way transit
> (like Internet2 is more or less doing)?  Note that the latter is very
> questionable AUP-wise.

I mean the latter indeed and it is a bit of a policy decision. The
NREN's do announce the commercial routes they learn for each other and
use the backpath to the commercial ISP's but they don't re-announce
eachothers networks. I hope they clear it up one time, until that time
I'll keep a couple of tunnels handy just in case ;)

Greets,
 Jeroen



--=-embyzjyy2MlLnnLgBIMX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBAkmnPKaooUjM+fCMRAoGaAJ44WkUdcriP81mKYARIyops9C+4IwCgqzNb
l/QYG0JCNP8dO3D1K6E6hDw=
=or9W
-----END PGP SIGNATURE-----

--=-embyzjyy2MlLnnLgBIMX--




From owner-v6ops@ops.ietf.org  Fri Apr 30 11:20:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07812
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 11:20:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJZne-0008BG-Cm
	for v6ops-data@psg.com; Fri, 30 Apr 2004 15:19:38 +0000
Received: from [195.64.92.136] (helo=purgatory.unfix.org)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJZnd-0008Aq-3c
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 15:19:37 +0000
Received: from localhost (localhost [127.0.0.1])
	by purgatory.unfix.org (Postfix) with ESMTP
	id 3CD257F67; Fri, 30 Apr 2004 17:19:35 +0200 (CEST)
Received: from purgatory.unfix.org ([127.0.0.1])
	by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id 28076-59; Fri, 30 Apr 2004 17:19:21 +0200 (CEST)
Received: from dhcp70-109.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP
	id 863F07F4F; Fri, 30 Apr 2004 17:19:20 +0200 (CEST)
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.44.0404301752440.19318-100000@netcore.fi>
References: <Pine.LNX.4.44.0404301752440.19318-100000@netcore.fi>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BfNyVlmKpmtdGtbt32u6"
Organization: Unfix
Message-Id: <1083338358.4555.116.camel@segesta.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 30 Apr 2004 17:19:18 +0200
X-Virus-Scanned: purgatory.unfix.org - http://unfix.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-BfNyVlmKpmtdGtbt32u6
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2004-04-30 at 16:57, Pekka Savola wrote:

<SNIP>

> I've raised concerns about the bad present considition as well (in
> draft-savola-v6ops-6bone-mess-01, now probably expired), but remember
> that the ISPs aren't probably going to offer native v6 to all their
> customers unless they've been sufficiently well-connected first.

Your 6bone mess has expired, but in the mean time the routing has become
much better IMHO, for proof see: http://www.space.net/~gert/RIPE/

There is also a very good document from Robert Kiessling which is being
applied by quite a number of ISP's majorily in Europe:
http://ip6.de.easynet.net/ipv6-minimum-peering.txt

This document will be handled next week at the RIPE IPv6 WG.

> (The technically knowledgeable v6 enthusiasts who are using these
> pilot services aren't worth looking at here.)

I think I have mentioned this before, but I know of quite a lot of
people who are totally not technically knowledgable but are able to
follow a few easy steps to find their way to the honeypot.

For instance:
http://www.opurk.nl/reacties.php?commentaar=3D1223&onderwerp=3DComputers

If you where able to read dutch, though some of it is really ugly
belgian stuff, you would also notice that these people help eachother
out when it isn't all that easy. This is just one of the many forum
sites that discuss these issues btw. Having quite some interaction with
these non-tech endusers have showed me that most of them can get it
working very easily and without much problems already, thus without even
the automated discovery tools. There is no KaZaA discovery method either
now is there ? And they did hit the how many million users?

Notez bien these people are doing it so they can get connectivity to a
service that they can't reach (freely) otherwise.

> I don't want to see a situation for the mainstream users where you'd
> have to e.g. use tunnel server (remember, that would have to be
> automatically set-up as well -- the chances of its quality are not too
> high either!) to get better connectivity than native IPv6...

Native should be the defacto standard, if an ISP can't deliver a quality
internet connection then users will complain, especially when they pay.

As for Tunnel Servers, that is a Transition method, thus they should go
away at one point... sooner or later.

Greets,
 Jeroen


--=-BfNyVlmKpmtdGtbt32u6
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBAkm52KaooUjM+fCMRAo5kAKCRFIy885wbGwWFnByvitUf+4TqewCeOoI8
efy0p4JV21ScTKc1bohyxJM=
=8+eA
-----END PGP SIGNATURE-----

--=-BfNyVlmKpmtdGtbt32u6--




From owner-v6ops@ops.ietf.org  Fri Apr 30 13:34:21 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17353
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 13:34:21 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJbsD-0003gQ-N4
	for v6ops-data@psg.com; Fri, 30 Apr 2004 17:32:29 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJbsC-0003g2-1C
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 17:32:28 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UHWQD21853
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 20:32:26 +0300
Date: Fri, 30 Apr 2004 20:32:26 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: POLL: Consensus for moving forward with Teredo?
Message-ID: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

As identified in the scenarios analysis at IETF59 and in
draft-savola-v6ops-tunneling-01.txt, there appears to a need which
cannot be filled by another mechanism for Teredo at least in one major
Unmanaged scenario.

Is there rough consensus to move forward with Teredo? (i.e., to adopt
it as WG document in this WG or elsewhere, for Proposed Standard.)

The main issue raised has been to call for a more extensive analysis
for the deployment implications of native, 6to4, and Teredo.  There is
already discussion of this in the Unmanaged Analysis document.  There
seemed to be very little energy or interest in the WG to drive this
much further.

The options regarrding Teredo at this stage seem to be:

 a) Go forward with Teredo, hone the deployment implications in the 
    unmanaged analysis in parallel (if and as appropriate),

 b) Conclude that there is no sufficiently strong need for Teredo, and 
    not support its advancement (for PS) at this stage, or

 c) Decide that we need to analyze the scenarios or deployment more 
    before being able to make a decision.  

    If so, please state where you believe more analysis is needed.. 
    and volunteer if possible :)

If you have an opinion, please state it within a week, i.e., by next
Friday, 7th May.

Thanks!

(co-chair hat off)




From owner-v6ops@ops.ietf.org  Fri Apr 30 13:38:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17494
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 13:38:08 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJbxW-0004e9-D4
	for v6ops-data@psg.com; Fri, 30 Apr 2004 17:37:58 +0000
Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJbxV-0004dj-Iu
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 17:37:57 +0000
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3UHbZB23752;
	Fri, 30 Apr 2004 10:37:35 -0700
X-mProtect: <200404301737> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdMGSnwT; Fri, 30 Apr 2004 10:35:28 PDT
Message-ID: <40928E70.6050105@iprg.nokia.com>
Date: Fri, 30 Apr 2004 10:35:44 -0700
From: Fred 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: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>,
        "'Markku Savela'"
 <msa@burp.tkv.asdf.org>
CC: Fred Templin <ftemplin@iprg.nokia.com>, v6ops@ops.ietf.org,
        dthaler@microsoft.com, mohitt@microsoft.com, tgleeson@cisco.com
Subject: Re: draft-ietf-ngtrans-isatap-21.txt
References: <C26BB8276599A44B85D52F9CE41035E10229E3D3@esealnt944.al.sw.ericsson.se> <40881876.8050104@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Karen and Markku,

Thank you once again for your comments on isatap-21.
The co-authors have discussed the issues, and proposed
resolutions are now posted on the Issue Tracker page at:

  www.geocities.com/osprey67/isatap/isatap_issues.htm

The working group is now invited to examine and
comment on the proposed resolutions.

Fred L. Templin
ftemplin@iprg.nokia.com

Fred Templin wrote:

> Karen and Markku,
>
> Thank you for your comments on the isatap-21 draft; they
> have been added to the ISATAP Issue Tracker page at:
>
>   www.geocities.com/osprey67/isatap/isatap_issues.htm
>
> Fred Templin (for the ISATAP co-authors)
> ftemplin@iprg.nokia.com
>





From owner-v6ops@ops.ietf.org  Fri Apr 30 15:28:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24870
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 15:28:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJdes-000P45-D1
	for v6ops-data@psg.com; Fri, 30 Apr 2004 19:26:50 +0000
Received: from [209.71.226.3] (helo=panoramix.hexago.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJder-000P3q-8b
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 19:26:49 +0000
Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22])
	(authenticated bits=0)
	by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i3UJQavI029968;
	Fri, 30 Apr 2004 15:26:36 -0400 (EDT)
Date: Fri, 30 Apr 2004 15:26:14 -0400
From: Marc Blanchet <Marc.Blanchet@hexago.com>
To: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
Subject: Re: POLL: Consensus for moving forward with Teredo?
Message-ID: <89120000.1083353174@classic.viagenie.qc.ca>
In-Reply-To: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
References: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
X-Mailer: Mulberry/3.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

b) 
because: 
- there are other ways on the table to do nat-traversal.
- teredo introduces many security issues, such as very open relays that are
subject to be used for large scale DDOS
- teredo is complex to implement
- teredo introduces states and buffering in relays when the first packets
are sent, which have important issues in implementing.
- teredo does not work for symmetric NATs and the "fallback" for a user in
this situation is "no service".

Marc.

-- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola <pekkas@netcore.fi>
wrote/a ecrit:

> Hi,
> 
> (co-chair hat on)
> 
> As identified in the scenarios analysis at IETF59 and in
> draft-savola-v6ops-tunneling-01.txt, there appears to a need which
> cannot be filled by another mechanism for Teredo at least in one major
> Unmanaged scenario.
> 
> Is there rough consensus to move forward with Teredo? (i.e., to adopt
> it as WG document in this WG or elsewhere, for Proposed Standard.)
> 
> The main issue raised has been to call for a more extensive analysis
> for the deployment implications of native, 6to4, and Teredo.  There is
> already discussion of this in the Unmanaged Analysis document.  There
> seemed to be very little energy or interest in the WG to drive this
> much further.
> 
> The options regarrding Teredo at this stage seem to be:
> 
>  a) Go forward with Teredo, hone the deployment implications in the 
>     unmanaged analysis in parallel (if and as appropriate),
> 
>  b) Conclude that there is no sufficiently strong need for Teredo, and 
>     not support its advancement (for PS) at this stage, or
> 
>  c) Decide that we need to analyze the scenarios or deployment more 
>     before being able to make a decision.  
> 
>     If so, please state where you believe more analysis is needed.. 
>     and volunteer if possible :)
> 
> If you have an opinion, please state it within a week, i.e., by next
> Friday, 7th May.
> 
> Thanks!
> 
> (co-chair hat off)
> 



------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------



From owner-v6ops@ops.ietf.org  Fri Apr 30 16:29:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28670
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 16:29:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJecj-0008qK-2b
	for v6ops-data@psg.com; Fri, 30 Apr 2004 20:28:41 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJecf-0008pu-Mp
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 20:28:37 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP
	id 462A3A5FE; Fri, 30 Apr 2004 16:28:37 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 16:28:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 16:28:04 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6CC@tayexc13.americas.cpqcorp.net>
Thread-Topic: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Thread-Index: AcQusadnPSzOBh8DSqK8Jufjdv34wgAP9xAQ
From: "Bound, Jim" <jim.bound@hp.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 20:28:05.0539 (UTC) FILETIME=[A484F730:01C42EF1]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jordi,

You did not respond to my technical supposition which is DSTM is in fact
an optimization for native IPv6.  You can disagree and we can keep
discussing but not answering the question don't help me to believe you
heard my input?

thanks
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 30, 2004 8:50 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> Jim,
>=20
> You're right. Our idea is a dual stack node, with IPv4=20
> connectivity (and with or without IPv6 native).
>=20
> The point is the case when I travel to an IETF, for example,=20
> and I've native IPv6, but the performance is very poor. I can=20
> always opt for using a better transition mechanism (example a=20
> "near" TB/TS).
>=20
> Will make sure to clarify it better.
>=20
> As Brian and Pekka said, we are too much ambitious or not=20
> clear enough, and already working on improving the document.
>=20
> Regards,
> Jordi
>=20
> ----- Original Message -----
> From: "Bound, Jim" <jim.bound@hp.com>
> To: "Pekka Savola" <pekkas@netcore.fi>
> Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;=20
> <v6ops@ops.ietf.org>
> Sent: Friday, April 30, 2004 2:21 PM
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
>=20
> then the document title should say that in some form in the title
> because it will not be useful to users building native IPv6 networks
> with IPv6 as the dominant backbone routing protocol e.g. 3GPP=20
> IMS, U.S.
> DOD nets, ISPs building for IPv6 device attacments to the network, or
> Moonv6 Network Pilot as examples of early adoption and=20
> deployment.  But
> I thought I saw parts in the spec that did speak to IPv6=20
> networks I will
> check again?
>=20
> I also agree with you this document is in a sense boiling the=20
> ocean and
> that does not work.  I also right now do not believe this is possible.
>=20
> /jim=20
>=20
> > -----Original Message-----
> > From: Pekka Savola [mailto:pekkas@netcore.fi]=20
> > Sent: Friday, April 30, 2004 12:16 AM
> > To: Bound, Jim
> > Cc: JORDI PALET MARTINEZ; v6ops@ops.ietf.org
> > Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> >=20
> > On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > > A number of transition mechanism have been defined=20
> > already: Teredo,=20
> > > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them=20
> > work when
> > >=20
> > > Your missing DSTM in this analysis why is that?
> >=20
> > I think the document is focused on obtaining _IPv6_=20
> > connectivity in IPv4-only networks, not the other way around.
> >=20
> > ...
> >=20
> > FWIW, I personally agree with Brian's concern of too=20
> > ambitious goals. =20
> > Too ambituous goals often result in nothing getting done,=20
> > instead of what might have been realistic.  So, if it stays,=20
> > it probably needs "health warnings" or th like :)
> >=20
> > --=20
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >=20
> >=20
> >=20
>=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 16:31:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28868
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 16:31:12 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJef5-0009GU-7k
	for v6ops-data@psg.com; Fri, 30 Apr 2004 20:31:07 +0000
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJef4-0009GG-HV
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 20:31:06 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 30 Apr 2004 12:44:39 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UKV3W9004755;
	Fri, 30 Apr 2004 13:31:03 -0700 (PDT)
Received: (from otroan@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA26534;
	Fri, 30 Apr 2004 21:31:01 +0100 (BST)
X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Subject: Re: POLL: Consensus for moving forward with Teredo?
References: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
From: Ole Troan <ot@cisco.com>
Date: Fri, 30 Apr 2004 21:31:01 +0100
In-Reply-To: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi> (Pekka
 Savola's message of "Fri, 30 Apr 2004 20:32:26 +0300 (EEST)")
Message-ID: <7t5oep9dx8a.fsf@mrwint.cisco.com>
User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

> The options regarrding Teredo at this stage seem to be:
>
>  a) Go forward with Teredo, hone the deployment implications in the 
>     unmanaged analysis in parallel (if and as appropriate),
>
>  b) Conclude that there is no sufficiently strong need for Teredo, and 
>     not support its advancement (for PS) at this stage, or
>
>  c) Decide that we need to analyze the scenarios or deployment more 
>     before being able to make a decision.  
>
>     If so, please state where you believe more analysis is needed.. 
>     and volunteer if possible :)

b). what Marc said.

/ot



From owner-v6ops@ops.ietf.org  Fri Apr 30 16:32:57 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29107
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 16:32:56 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJegj-0009YQ-Qi
	for v6ops-data@psg.com; Fri, 30 Apr 2004 20:32:49 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJegi-0009Y8-KQ
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 20:32:48 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP
	id 514E9A663; Fri, 30 Apr 2004 16:32:48 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 16:32:32 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Fri, 30 Apr 2004 16:32:30 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6CD@tayexc13.americas.cpqcorp.net>
Thread-Topic: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Thread-Index: AcQus4QA9MqhHKihQuepGsaIwbP4pQAPlDmQ
From: "Bound, Jim" <jim.bound@hp.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 20:32:32.0069 (UTC) FILETIME=[43623750:01C42EF2]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

OK now you answered my question.  that was my point.  DSTM is an
optimization in this scenario though I have to agree if someone is using
native IPv6 and can get out to the net (per Pekkas mail) then they
really should just fix the IPv6 network.

If you stated as I said this is for dominant IPv4 nets or native IPv6
behind IPv4 nodes or islands in the home then DSTM does not apply. DSTM
only applies for dominant aggressive native IPv6 networks that need to
communicate with IPv4 to legacy nodes that have not moved yet.

Regards,
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 30, 2004 9:02 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> Hi Jim,
>=20
> May be I worded it in the wrong way. My assumption right now=20
> is that you have always IPv4 connectivity.
>=20
> The original goal was to ensure the best IPv6 connectivity in=20
> any situation (today's reality with most of the networks=20
> being only IPv4).
>=20
> But I can see the auto-transition idea being applied also to=20
> ensure the best IPv4 connectivity if this is required (in the=20
> ideal world when we have most of the networks, or at least a=20
> good number of them, with IPv6). In this case is clear that=20
> DSTM is a very good option, I believe.
>=20
> Initially we haven't considered this send option, but now I'm=20
> wondering if we should ? What is the opinion of others ?=20
> (just in case, to make it clear, when we have only IPv6=20
> connectivity and want to ensure also IPv4).
>=20
> Anyway, we will re-read DSTM documents to see if we missed something.
>=20
> Will be happy to get your inputs on this, of course.
>=20
> Regards,
> Jordi
>=20
> ----- Original Message -----
> From: "Bound, Jim" <jim.bound@hp.com>
> To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;=20
> <v6ops@ops.ietf.org>
> Sent: Friday, April 30, 2004 2:37 PM
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
>=20
> Jordi,
>=20
> Your words from below:
>=20
> >so we consider only scenarios=20
> > where you have IPv6 native connectivity (but the performance=20
> > is poor for whatever reason and we can improve it with a=20
> > transition mechanism, for example to a nearer tunnel server)=20
> > or where you have IPv4 convexity and want to get IPv6.
>=20
> Assumption 1 from your words:
>=20
> There is an IPv6 Native Network.
>=20
> Assumption 2 from your words.
>=20
> There is an IPv4 network the packet can use for better performance.
>=20
> Then DSTM is in fact an option and here is why:
>=20
> DSTM Assumption 1:
>=20
> As DSTM postulates it is possible that the user has deployed only IPv6
> applications on a network.
>=20
> DSTM Assumption 2:
>=20
> There is an IPv4 routable address within the network scope of
> communications that can be used by obtaining it from DHCPv6 or IPv6
> Tunnel Broker.
>=20
> Then the dual stack approach is used or Native IPv4.
>=20
> Given your words you need to add DSTM or remove discussion of Native
> IPv6 is my input.
>=20
> I am now going to review your draft in depth to give you hard core
> technical input as IPv6 engineering expert because your=20
> response was to
> casual and not technical enough for me anyway. =20
>=20
> /jim
>=20
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org=20
> > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> > Sent: Friday, April 30, 2004 8:27 AM
> > To: v6ops@ops.ietf.org
> > Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> >=20
> > See below, in-line.
> >=20
> > Regards,
> > Jordi
> >=20
> > ----- Original Message -----
> > From: "Pekka Savola" <pekkas@netcore.fi>
> > To: "Bound, Jim" <jim.bound@hp.com>
> > Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;=20
> > <v6ops@ops.ietf.org>
> > Sent: Friday, April 30, 2004 6:16 AM
> > Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> >=20
> >=20
> > > On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > > > A number of transition mechanism have been defined=20
> > already: Teredo,
> > > > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of=20
> > them work when
> > > >=20
> > > > Your missing DSTM in this analysis why is that?
> > >=20
> >=20
> > Yes, Pekka is right, that's the point. We are assuming that=20
> > the host is already dual stack, and we are looking for=20
> > ensuring IPv6 connectivity, so we consider only scenarios=20
> > where you have IPv6 native connectivity (but the performance=20
> > is poor for whatever reason and we can improve it with a=20
> > transition mechanism, for example to a nearer tunnel server)=20
> > or where you have IPv4 convexity and want to get IPv6.
> >=20
> > The document is focusing in the evaluation of those mechanism=20
> > that we consider today have a better chance to provide better=20
> > results. A follow up document will work on solutions, and=20
> > possibly protocol description, and those documents could take=20
> > care of more alternatives, even new transition mechanism that=20
> > today don't exist, however we believe is difficult it happens=20
> > (difficult to see mechanism that offer "more" that what we=20
> have now).
> >=20
> > Anyway, we will improve the text in the next release to=20
> clarify this.
> >=20
> > > I think the document is focused on obtaining _IPv6_=20
> connectivity in=20
> > > IPv4-only networks, not the other way around.
> > >=20
> > > ...
> > >=20
> > > FWIW, I personally agree with Brian's concern of too=20
> > ambitious goals. =20
> > > Too ambituous goals often result in nothing getting done,=20
> instead of
> > > what might have been realistic.  So, if it stays, it=20
> probably needs
> > > "health warnings" or th like :)
> > >=20
> >=20
> >=20
> > As I already indicated replying to Brian, we will make sure=20
> > to be more realistic and/or clear on this point in the next release.
> >=20
> > > --=20
> > > Pekka Savola                 "You each name yourselves=20
> king, yet the
> > > Netcore Oy                    kingdom bleeds."
> > > Systems. Networks. Security. -- George R.R. Martin: A=20
> Clash of Kings
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> > **********************************
> > Madrid 2003 Global IPv6 Summit
> > Presentations and videos on line at:
> > http://www.ipv6-es.com
> >=20
> > This electronic message contains information which may be=20
> > privileged or confidential. The information is intended to be=20
> > for the use of the individual(s) named above. If you are not=20
> > the intended recipient be aware that any disclosure, copying,=20
> > distribution or use of the contents of this information,=20
> > including attached files, is prohibited.
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 16:39:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29860
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 16:39:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJen6-000AnN-NP
	for v6ops-data@psg.com; Fri, 30 Apr 2004 20:39:24 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJen5-000An0-03
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 20:39:23 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id B0198515D
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 16:39:22 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 16:38:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: POLL: Consensus for moving forward with Teredo?
Date: Fri, 30 Apr 2004 16:38:50 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6CE@tayexc13.americas.cpqcorp.net>
Thread-Topic: POLL: Consensus for moving forward with Teredo?
Thread-Index: AcQu6VQZTW7mKZ2tQeK69sMBez1FQwACVKNg
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 20:38:51.0457 (UTC) FILETIME=[25843B10:01C42EF3]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

We must work on Teredo, ISATAP, DSTM, and Tunnel Broker.  All are being
deployed all will exist.  So I vote for (a) but I think Tunnel Broker is
also a choice for UMAN and if asked in the market tell them try both and
see what you like best each have different properties.  And I hope there
are more good and innovative transition mechanisms invented the more the
better.  We will build many types of IPv6 networks I am sure we do not
have all the tools for transition done and all of the above will be used
and are useful for deployment.

/jim

> -- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola=20
> <pekkas@netcore.fi> wrote/a ecrit:
>=20
> > Hi,
> >=20
> > (co-chair hat on)
> >=20
> > As identified in the scenarios analysis at IETF59 and in=20
> > draft-savola-v6ops-tunneling-01.txt, there appears to a need which=20
> > cannot be filled by another mechanism for Teredo at least=20
> in one major=20
> > Unmanaged scenario.
> >=20
> > Is there rough consensus to move forward with Teredo?=20
> (i.e., to adopt=20
> > it as WG document in this WG or elsewhere, for Proposed Standard.)
> >=20
> > The main issue raised has been to call for a more extensive=20
> analysis=20
> > for the deployment implications of native, 6to4, and=20
> Teredo.  There is=20
> > already discussion of this in the Unmanaged Analysis=20
> document.  There=20
> > seemed to be very little energy or interest in the WG to drive this=20
> > much further.
> >=20
> > The options regarrding Teredo at this stage seem to be:
> >=20
> >  a) Go forward with Teredo, hone the deployment implications in the=20
> >     unmanaged analysis in parallel (if and as appropriate),
> >=20
> >  b) Conclude that there is no sufficiently strong need for=20
> Teredo, and=20
> >     not support its advancement (for PS) at this stage, or
> >=20
> >  c) Decide that we need to analyze the scenarios or deployment more=20
> >     before being able to make a decision. =20
> >=20
> >     If so, please state where you believe more analysis is needed..=20
> >     and volunteer if possible :)
> >=20
> > If you have an opinion, please state it within a week,=20
> i.e., by next=20
> > Friday, 7th May.
> >=20
> > Thanks!
> >=20
> > (co-chair hat off)
> >=20
>=20
>=20
>=20
> ------------------------------------------
> Marc Blanchet
> Hexago
> tel: +1-418-266-5533x225
> ------------------------------------------
> http://www.freenet6.net: IPv6 connectivity
> ------------------------------------------
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 16:48:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01217
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 16:48:33 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJev8-000CbI-3F
	for v6ops-data@psg.com; Fri, 30 Apr 2004 20:47:42 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJev6-000Can-R6
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 20:47:41 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UKld325296
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 23:47:39 +0300
Date: Fri, 30 Apr 2004 23:47:39 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: POLL: Consensus for moving forward with Teredo?
In-Reply-To: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
Message-ID: <Pine.LNX.4.44.0404302337530.24281-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

As for my personal view, it's a).

Reasons for this are:
 - other, simpler ways will be specified that will be able to do NAT 
   traversal and provide connectivity in the scenario where your ISP 
   would be willing to provide a tunnel.  I.e., Teredo only needs to 
   solve the scenario where you have no ISP to get v6
   connectivity.
 - it's already out there by the million, and the only economically 
   feasible way to bring the IPv6 to the masses i.e. bring out the 
   IPv6-only applications without which we'll have very hard time
   getting IPv6 _really_ there.   Waiting for all the ISPs in the 
   world to deploy v6 before there is clear market demand isn't going 
   to cut it.  The chicken-and-egg problem must be tackled somehow, 
   and this provides a means to do that.
 - current Teredo specification is reasonably secure, in practice
   performing a "return routability check"; much better than 6to4 in 
   any case, and comparable or higher than many others we have.
 - the analysis on the deployment tradeoffs is already far along to 
   be able to say that we will have to pay the "cost" for dealing 
   with {native,6to4,Teredo} in any case.

On Fri, 30 Apr 2004, Pekka Savola wrote:
>  a) Go forward with Teredo, hone the deployment implications in the 
>     unmanaged analysis in parallel (if and as appropriate),




From owner-v6ops@ops.ietf.org  Fri Apr 30 17:33:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05488
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 17:33:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJfcg-000IMR-J6
	for v6ops-data@psg.com; Fri, 30 Apr 2004 21:32:42 +0000
Received: from [131.107.3.124] (helo=mail2.microsoft.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJfcf-000IMD-Mh
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 21:32:41 +0000
Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041);
	 Fri, 30 Apr 2004 14:32:46 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039);
	 Fri, 30 Apr 2004 14:32:43 -0700
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Apr 2004 14:32:40 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 14:32:45 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Fri, 30 Apr 2004 14:32:42 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Fri, 30 Apr 2004 14:32:26 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Marc's objections to Teredo (was RE: POLL: Consensus for moving forward with Teredo?)
Date: Fri, 30 Apr 2004 14:32:31 -0700
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA08CB331A@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Marc's objections to Teredo (was RE: POLL: Consensus for moving forward with Teredo?)
Thread-Index: AcQu6gQwVIXvbKmhT3qHM4c2oV8aGgADxDVQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Marc Blanchet" <Marc.Blanchet@hexago.com>,
        "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 21:32:26.0587 (UTC) FILETIME=[A1E222B0:01C42EFA]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I obviously disagree with several of Marc's objections to Teredo:

> - there are other ways on the table to do nat-traversal.

Sure. If another solution has clear benefits, it should be standardized
as well. That is not a reason for not progressing Teredo.

> - teredo introduces many security issues, such as very open relays
that
> are subject to be used for large scale DDOS

Uh? Teredo does not actually introduce any "open relay". Each session
that goes through the relay has to perform an initial 3-ways handshake,
which makes it very hard to use in a large scale DDOS.

> - teredo is complex to implement

Complex to implement is an emotional statement. The assessment of
complexity in the IETF is "running code", not emotions. There already
are two independent and interoperable implementations. This meets the
standard for going to DS.

> - teredo introduces states and buffering in relays when the first
packets
> are sent, which have important issues in implementing.

"Important issues"? There are exactly the same issues with ARP, or IPv6
ND.=20

> - teredo does not work for symmetric NATs and the "fallback" for a
user in
> this situation is "no service".

Uh, no. There are three fallbacks. One is to simply go buy another NAT
-- most of the modern NAT do work with Teredo, as analyzed in
draft-jennings-midcom-stun-results-00.txt. The other is to go program
the Teredo port number in the NAT, using the management interface --
which is probably OK for the dedicated users. And the third is to obtain
service by another way.

-- Christian Huitema



From owner-v6ops@ops.ietf.org  Fri Apr 30 17:47:34 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06774
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 17:47:34 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJfRn-000GzS-Jy
	for v6ops-data@psg.com; Fri, 30 Apr 2004 21:21:27 +0000
Received: from [131.107.3.122] (helo=mail4.microsoft.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJfRm-000GzE-UL
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 21:21:26 +0000
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 14:21:26 -0700
Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Apr 2004 14:21:26 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 14:21:25 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Fri, 30 Apr 2004 14:21:27 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Fri, 30 Apr 2004 14:21:38 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: POLL: Consensus for moving forward with Teredo?
Date: Fri, 30 Apr 2004 14:21:14 -0700
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA08CB32DA@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: POLL: Consensus for moving forward with Teredo?
Thread-Index: AcQu6gQwVIXvbKmhT3qHM4c2oV8aGgADu6lA
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 21:21:38.0847 (UTC) FILETIME=[1FCCDAF0:01C42EF9]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I obviously vote for (a), Go forward with Teredo.

-- Christian Huitema




From owner-v6ops@ops.ietf.org  Fri Apr 30 18:32:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10130
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 18:32:27 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJgXc-000P2g-Oi
	for v6ops-data@psg.com; Fri, 30 Apr 2004 22:31:32 +0000
Received: from [4.16.92.133] (helo=tndh.net)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJgXb-000P2T-Rl
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 22:31:31 +0000
Received: from eaglet (127.0.0.1:3608)
	by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S52E4B> for <v6ops@ops.ietf.org> from <alh-ietf@tndh.net>;
	Fri, 30 Apr 2004 15:28:03 -0700
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Pekka Savola'" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
Subject: RE: POLL: Consensus for moving forward with Teredo?
Date: Fri, 30 Apr 2004 15:31:32 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcQu2P3awI4o/qKeT3asJ7OitQOezQAKOE2w
In-Reply-To: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DYNABLOCK,RCVD_IN_SORBS autolearn=no version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1BJgXc-000P2g-Oi@psg.com>
Content-Transfer-Encoding: 7bit

a)  - it complements 6to4 for the case where a NAT is in the path, as it is
equally trivial for consumers to use. 

The other technologies we have on the table also need to be progressed to PS
so the market can sort out which of them it really wants. The IETF fails
when it tries to dictate deployment approaches to the market. 

Tony


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of Pekka Savola
> Sent: Friday, April 30, 2004 10:32 AM
> To: v6ops@ops.ietf.org
> Subject: POLL: Consensus for moving forward with Teredo?
> 
> Hi,
> 
> (co-chair hat on)
> 
> As identified in the scenarios analysis at IETF59 and in
> draft-savola-v6ops-tunneling-01.txt, there appears to a need which
> cannot be filled by another mechanism for Teredo at least in one major
> Unmanaged scenario.
> 
> Is there rough consensus to move forward with Teredo? (i.e., to adopt
> it as WG document in this WG or elsewhere, for Proposed Standard.)
> 
> The main issue raised has been to call for a more extensive analysis
> for the deployment implications of native, 6to4, and Teredo.  There is
> already discussion of this in the Unmanaged Analysis document.  There
> seemed to be very little energy or interest in the WG to drive this
> much further.
> 
> The options regarrding Teredo at this stage seem to be:
> 
>  a) Go forward with Teredo, hone the deployment implications in the
>     unmanaged analysis in parallel (if and as appropriate),
> 
>  b) Conclude that there is no sufficiently strong need for Teredo, and
>     not support its advancement (for PS) at this stage, or
> 
>  c) Decide that we need to analyze the scenarios or deployment more
>     before being able to make a decision.
> 
>     If so, please state where you believe more analysis is needed..
>     and volunteer if possible :)
> 
> If you have an opinion, please state it within a week, i.e., by next
> Friday, 7th May.
> 
> Thanks!
> 
> (co-chair hat off)





From owner-v6ops@ops.ietf.org  Fri Apr 30 19:01:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11750
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 19:01:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJgz1-0001fD-2I
	for v6ops-data@psg.com; Fri, 30 Apr 2004 22:59:51 +0000
Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJgz0-0001f0-8G
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 22:59:50 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3UMxnMu023754
	for <v6ops@ops.ietf.org>; Fri, 30 Apr 2004 16:59:49 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0HX000B58AJPF5@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 30 Apr 2004 16:59:49 -0600 (MDT)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0HX000LURAJOXL@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 30 Apr 2004 16:59:49 -0600 (MDT)
Date: Fri, 30 Apr 2004 15:59:46 -0700
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: POLL: Consensus for moving forward with Teredo?
In-reply-to: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Message-id: <131BF669-9AFA-11D8-B8A7-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.613)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.44.0404302011570.21552-100000@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Apr 30, 2004, at 10:32 AM, Pekka Savola wrote:

> Hi,
> The options regarrding Teredo at this stage seem to be:
>
>  a) Go forward with Teredo, hone the deployment implications in the
>     unmanaged analysis in parallel (if and as appropriate),
>
>  b) Conclude that there is no sufficiently strong need for Teredo, and
>     not support its advancement (for PS) at this stage, or
>
>  c) Decide that we need to analyze the scenarios or deployment more
>     before being able to make a decision.
>
>     If so, please state where you believe more analysis is needed..
>     and volunteer if possible :)

There is an alternative:

d) publish it as Experimental.

There is code out there, deployable by the millions,
so it is good to document it formally. However, for the reasons Marc 
gave, I'm not
convinced that PS is the right approach.
Actually, I would suggest that Isatap be published as Experimental 
along Terredo,
for the same reasons.

	- Alain.




From owner-v6ops@ops.ietf.org  Fri Apr 30 19:01:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11816
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 19:01:54 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJh0w-0001tZ-Ug
	for v6ops-data@psg.com; Fri, 30 Apr 2004 23:01:50 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJh0v-0001t8-OQ
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 23:01:49 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP
	id 59BD24C11; Fri, 30 Apr 2004 19:01:49 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 19:01:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: POLL: Consensus for moving forward with Teredo?
Date: Fri, 30 Apr 2004 19:01:47 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6E5@tayexc13.americas.cpqcorp.net>
Thread-Topic: POLL: Consensus for moving forward with Teredo?
Thread-Index: AcQu2P3awI4o/qKeT3asJ7OitQOezQAKOE2wAAFM0MA=
From: "Bound, Jim" <jim.bound@hp.com>
To: "Tony Hain" <alh-ietf@tndh.net>, "Pekka Savola" <pekkas@netcore.fi>,
        <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 23:01:51.0924 (UTC) FILETIME=[1FDF9740:01C42F07]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

hear hear I resemble that :--)
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tony Hain
> Sent: Friday, April 30, 2004 6:32 PM
> To: 'Pekka Savola'; v6ops@ops.ietf.org
> Subject: RE: POLL: Consensus for moving forward with Teredo?
>=20
> a)  - it complements 6to4 for the case where a NAT is in the=20
> path, as it is equally trivial for consumers to use.=20
>=20
> The other technologies we have on the table also need to be=20
> progressed to PS so the market can sort out which of them it=20
> really wants. The IETF fails when it tries to dictate=20
> deployment approaches to the market.=20
>=20
> Tony
>=20
>=20
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20
> > Behalf Of Pekka Savola
> > Sent: Friday, April 30, 2004 10:32 AM
> > To: v6ops@ops.ietf.org
> > Subject: POLL: Consensus for moving forward with Teredo?
> >=20
> > Hi,
> >=20
> > (co-chair hat on)
> >=20
> > As identified in the scenarios analysis at IETF59 and in=20
> > draft-savola-v6ops-tunneling-01.txt, there appears to a need which=20
> > cannot be filled by another mechanism for Teredo at least=20
> in one major=20
> > Unmanaged scenario.
> >=20
> > Is there rough consensus to move forward with Teredo?=20
> (i.e., to adopt=20
> > it as WG document in this WG or elsewhere, for Proposed Standard.)
> >=20
> > The main issue raised has been to call for a more extensive=20
> analysis=20
> > for the deployment implications of native, 6to4, and=20
> Teredo.  There is=20
> > already discussion of this in the Unmanaged Analysis=20
> document.  There=20
> > seemed to be very little energy or interest in the WG to drive this=20
> > much further.
> >=20
> > The options regarrding Teredo at this stage seem to be:
> >=20
> >  a) Go forward with Teredo, hone the deployment implications in the
> >     unmanaged analysis in parallel (if and as appropriate),
> >=20
> >  b) Conclude that there is no sufficiently strong need for=20
> Teredo, and
> >     not support its advancement (for PS) at this stage, or
> >=20
> >  c) Decide that we need to analyze the scenarios or deployment more
> >     before being able to make a decision.
> >=20
> >     If so, please state where you believe more analysis is needed..
> >     and volunteer if possible :)
> >=20
> > If you have an opinion, please state it within a week,=20
> i.e., by next=20
> > Friday, 7th May.
> >=20
> > Thanks!
> >=20
> > (co-chair hat off)
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 19:10:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12153
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 19:10:25 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJh8y-0002nM-64
	for v6ops-data@psg.com; Fri, 30 Apr 2004 23:10:08 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJh8w-0002n5-SG
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 23:10:06 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP
	id 76E9F3411; Fri, 30 Apr 2004 19:10:06 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 19:10:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Marc's objections to Teredo (was RE: POLL: Consensus for moving forward with Teredo?)
Date: Fri, 30 Apr 2004 19:10:03 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6E6@tayexc13.americas.cpqcorp.net>
Thread-Topic: Marc's objections to Teredo (was RE: POLL: Consensus for moving forward with Teredo?)
Thread-Index: AcQu6gQwVIXvbKmhT3qHM4c2oV8aGgADxDVQAAOGu0A=
From: "Bound, Jim" <jim.bound@hp.com>
To: "Christian Huitema" <huitema@windows.microsoft.com>,
        "Marc Blanchet" <Marc.Blanchet@hexago.com>,
        "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 23:10:09.0092 (UTC) FILETIME=[48356840:01C42F08]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Not piling on marc and fully support the Tunnel Broker and believe it is
very important to IPv6 deployment.

But I do think Christian has responded well to the objections.  Esp. the
complexity issue.  We must let the market decide what is complex it is
not in our charter IMO and would take time away from the work we do
technically well here.

/jim

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Christian Huitema
> Sent: Friday, April 30, 2004 5:33 PM
> To: Marc Blanchet; Pekka Savola; v6ops@ops.ietf.org
> Subject: Marc's objections to Teredo (was RE: POLL: Consensus=20
> for moving forward with Teredo?)
>=20
> I obviously disagree with several of Marc's objections to Teredo:
>=20
> > - there are other ways on the table to do nat-traversal.
>=20
> Sure. If another solution has clear benefits, it should be=20
> standardized as well. That is not a reason for not progressing Teredo.
>=20
> > - teredo introduces many security issues, such as very open relays
> that
> > are subject to be used for large scale DDOS
>=20
> Uh? Teredo does not actually introduce any "open relay". Each=20
> session that goes through the relay has to perform an initial=20
> 3-ways handshake, which makes it very hard to use in a large=20
> scale DDOS.
>=20
> > - teredo is complex to implement
>=20
> Complex to implement is an emotional statement. The=20
> assessment of complexity in the IETF is "running code", not=20
> emotions. There already are two independent and interoperable=20
> implementations. This meets the standard for going to DS.
>=20
> > - teredo introduces states and buffering in relays when the first
> packets
> > are sent, which have important issues in implementing.
>=20
> "Important issues"? There are exactly the same issues with=20
> ARP, or IPv6 ND.=20
>=20
> > - teredo does not work for symmetric NATs and the "fallback" for a
> user in
> > this situation is "no service".
>=20
> Uh, no. There are three fallbacks. One is to simply go buy another NAT
> -- most of the modern NAT do work with Teredo, as analyzed in=20
> draft-jennings-midcom-stun-results-00.txt. The other is to go=20
> program the Teredo port number in the NAT, using the=20
> management interface -- which is probably OK for the=20
> dedicated users. And the third is to obtain service by another way.
>=20
> -- Christian Huitema
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 19:14:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12435
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 19:14:40 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJhDG-0003KR-0f
	for v6ops-data@psg.com; Fri, 30 Apr 2004 23:14:34 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJhDE-0003K8-Q9
	for v6ops@ops.ietf.org; Fri, 30 Apr 2004 23:14:32 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP
	id 5981851DB; Fri, 30 Apr 2004 19:14:31 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 30 Apr 2004 19:14:31 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: POLL: Consensus for moving forward with Teredo?
Date: Fri, 30 Apr 2004 19:14:29 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6E7@tayexc13.americas.cpqcorp.net>
Thread-Topic: POLL: Consensus for moving forward with Teredo?
Thread-Index: AcQvB0MdXfTmmrKrR/+u9BkfAPgiEAAAR+eA
From: "Bound, Jim" <jim.bound@hp.com>
To: "Alain Durand" <Alain.Durand@Sun.COM>, "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Apr 2004 23:14:31.0164 (UTC) FILETIME=[E46A6BC0:01C42F08]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Teredo is very baked and all of them have been implemented by two
independent parties (Teredo, ISATAP, DSTM, Tunnel Broker).  I think we
should stick to Pekkas categories.  What level a spec moves to is
another question completely.  I think we should begin working on all of
them as they are being used now and in response to real RFPs by
customers. =20

/jim =20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alain Durand
> Sent: Friday, April 30, 2004 7:00 PM
> To: Pekka Savola
> Cc: v6ops@ops.ietf.org
> Subject: Re: POLL: Consensus for moving forward with Teredo?
>=20
>=20
> On Apr 30, 2004, at 10:32 AM, Pekka Savola wrote:
>=20
> > Hi,
> > The options regarrding Teredo at this stage seem to be:
> >
> >  a) Go forward with Teredo, hone the deployment implications in the
> >     unmanaged analysis in parallel (if and as appropriate),
> >
> >  b) Conclude that there is no sufficiently strong need for=20
> Teredo, and
> >     not support its advancement (for PS) at this stage, or
> >
> >  c) Decide that we need to analyze the scenarios or deployment more
> >     before being able to make a decision.
> >
> >     If so, please state where you believe more analysis is needed..
> >     and volunteer if possible :)
>=20
> There is an alternative:
>=20
> d) publish it as Experimental.
>=20
> There is code out there, deployable by the millions, so it is=20
> good to document it formally. However, for the reasons Marc=20
> gave, I'm not convinced that PS is the right approach.
> Actually, I would suggest that Isatap be published as=20
> Experimental along Terredo, for the same reasons.
>=20
> 	- Alain.
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Fri Apr 30 23:01:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21445
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 23:01:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJkiE-0001hP-FI
	for v6ops-data@psg.com; Sat, 01 May 2004 02:58:46 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJkiC-0001gt-5G
	for v6ops@ops.ietf.org; Sat, 01 May 2004 02:58:44 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000053353.msg
	for <v6ops@ops.ietf.org>; Sat, 01 May 2004 04:59:14 +0200
Message-ID: <030601c42f28$320d5b70$640a0a0a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6CE@tayexc13.americas.cpqcorp.net>
Subject: Re: POLL: Consensus for moving forward with Teredo?
Date: Sat, 1 May 2004 04:58:34 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Sat, 01 May 2004 04:59:14 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Sat, 01 May 2004 04:59:15 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jim,

I fully agree with this view, and moreover, if we allow the auto-discovery of the TB, then even more clearly, the TB will be applicable to unman and other scenarios.

I wonder if Teredo could take advantage of the auto-discovery idea (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt), making sure that if required both the 6to4, TB/TS/TSP, ISATAP and the Teredo relays, can coexist automatically in the same box. This could easily simplify the deployment and be an important multiplicative factor.

So, I will suggest a new option "a.bis)": The idea is to make a very quick move on defining a solution for the auto-discovery, and include this in a revised Teredo version (same with ISATAP, TSP, etc.).

Note that I will not like to delay the "go forward" of a) option for a long time, but I'm convinced that if Christian and some other people related to other transition mechanism (TB/TS, may be ISATAP) that need to discover end-point work together.

If we have inputs on the auto-discovery solution, I'm sure that a small team of "hard workers" could make it even before the next IETF. This is a small delay, but I believe the result could be worthy.

Christian, Pekka what do you think ? (I've not read the latest versions of Teredo, so I'm not sure if what I'm saying is actually meaningful, but I understand that the server/relay need to be pre-configured, so can we make it auto-discovered ?, indeed we didn't included Teredo in our I-D, but may be an option for the next revision).

Regards,
Jordi

----- Original Message -----=20
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 10:38 PM
Subject: RE: POLL: Consensus for moving forward with Teredo?


We must work on Teredo, ISATAP, DSTM, and Tunnel Broker.  All are being
deployed all will exist.  So I vote for (a) but I think Tunnel Broker is
also a choice for UMAN and if asked in the market tell them try both and
see what you like best each have different properties.  And I hope there
are more good and innovative transition mechanisms invented the more the
better.  We will build many types of IPv6 networks I am sure we do not
have all the tools for transition done and all of the above will be used
and are useful for deployment.

/jim

> -- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola=20
> <pekkas@netcore.fi> wrote/a ecrit:
>=20
> > Hi,
> >=20
> > (co-chair hat on)
> >=20
> > As identified in the scenarios analysis at IETF59 and in=20
> > draft-savola-v6ops-tunneling-01.txt, there appears to a need which=20
> > cannot be filled by another mechanism for Teredo at least=20
> in one major=20
> > Unmanaged scenario.
> >=20
> > Is there rough consensus to move forward with Teredo?=20
> (i.e., to adopt=20
> > it as WG document in this WG or elsewhere, for Proposed Standard.)
> >=20
> > The main issue raised has been to call for a more extensive=20
> analysis=20
> > for the deployment implications of native, 6to4, and=20
> Teredo.  There is=20
> > already discussion of this in the Unmanaged Analysis=20
> document.  There=20
> > seemed to be very little energy or interest in the WG to drive this=20
> > much further.
> >=20
> > The options regarrding Teredo at this stage seem to be:
> >=20
> >  a) Go forward with Teredo, hone the deployment implications in the=20
> >     unmanaged analysis in parallel (if and as appropriate),
> >=20
> >  b) Conclude that there is no sufficiently strong need for=20
> Teredo, and=20
> >     not support its advancement (for PS) at this stage, or
> >=20
> >  c) Decide that we need to analyze the scenarios or deployment more=20
> >     before being able to make a decision. =20
> >=20
> >     If so, please state where you believe more analysis is needed..=20
> >     and volunteer if possible :)
> >=20
> > If you have an opinion, please state it within a week,=20
> i.e., by next=20
> > Friday, 7th May.
> >=20
> > Thanks!
> >=20
> > (co-chair hat off)
> >=20
>=20
>=20
>=20
> ------------------------------------------
> Marc Blanchet
> Hexago
> tel: +1-418-266-5533x225
> ------------------------------------------
> http://www.freenet6.net: IPv6 connectivity
> ------------------------------------------
>=20
>=20
>=20




**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






From owner-v6ops@ops.ietf.org  Fri Apr 30 23:15:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21786
	for <v6ops-archive@lists.ietf.org>; Fri, 30 Apr 2004 23:15:55 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD)
	id 1BJkyP-0004Wu-6L
	for v6ops-data@psg.com; Sat, 01 May 2004 03:15:29 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BJkyN-0004Wg-L5
	for v6ops@ops.ietf.org; Sat, 01 May 2004 03:15:27 +0000
Received: from consulintel02 ([217.126.187.160])
	(authenticated user jordi.palet@consulintel.es)
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000053367.msg
	for <v6ops@ops.ietf.org>; Sat, 01 May 2004 05:15:56 +0200
Message-ID: <032b01c42f2a$86bde3e0$640a0a0a@consulintel.es>
Reply-To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
References: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6CD@tayexc13.americas.cpqcorp.net>
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Date: Sat, 1 May 2004 05:15:15 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Sat, 01 May 2004 05:15:56 +0200
	(not processed: spam filter disabled)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
X-MDAV-Processed: consulintel.es, Sat, 01 May 2004 05:15:59 +0200
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.63
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Thanks Jim. Anyway, your input on the complete I-D will be highly appreciated ;-)

Pekka do you think it makes sense to incorporate in the document also the evaluation of the "future" case that I described ? I mean:

> But I can see the auto-transition idea being applied also to=20
> ensure the best IPv4 connectivity if this is required (in the=20
> ideal world when we have most of the networks, or at least a=20
> good number of them, with IPv6 only). In this case is clear that=20
> DSTM is a very good option, I believe. Others could also apply ("4in6", ...).
>=20
> Initially we haven't considered this second option, but now I'm=20
> wondering if we should ? What is the opinion of others ?=20
> (just in case, to make it clear, when we have only IPv6=20
> connectivity and want to ensure also IPv4).

In my opinion the "auto-transition" mechanism can incorporate both in a simple way, so we don't need to have an auto-transition from IPv4 to IPv6 (today situation) and then an auto-transition IPv6 to IPv4 (hopefully tomorrow situation).

Jim, obviously this only makes sense if DSTM doesn't work in all the situations, or if there are other options (instead of DSTM). What do you think ?

Regards,
Jordi

----- Original Message -----=20
From: "Bound, Jim" <jim.bound@hp.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 10:32 PM
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt


OK now you answered my question.  that was my point.  DSTM is an
optimization in this scenario though I have to agree if someone is using
native IPv6 and can get out to the net (per Pekkas mail) then they
really should just fix the IPv6 network.

If you stated as I said this is for dominant IPv4 nets or native IPv6
behind IPv4 nodes or islands in the home then DSTM does not apply. DSTM
only applies for dominant aggressive native IPv6 networks that need to
communicate with IPv4 to legacy nodes that have not moved yet.

Regards,
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 30, 2004 9:02 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
> Hi Jim,
>=20
> May be I worded it in the wrong way. My assumption right now=20
> is that you have always IPv4 connectivity.
>=20
> The original goal was to ensure the best IPv6 connectivity in=20
> any situation (today's reality with most of the networks=20
> being only IPv4).
>=20
> But I can see the auto-transition idea being applied also to=20
> ensure the best IPv4 connectivity if this is required (in the=20
> ideal world when we have most of the networks, or at least a=20
> good number of them, with IPv6). In this case is clear that=20
> DSTM is a very good option, I believe.
>=20
> Initially we haven't considered this send option, but now I'm=20
> wondering if we should ? What is the opinion of others ?=20
> (just in case, to make it clear, when we have only IPv6=20
> connectivity and want to ensure also IPv4).
>=20
> Anyway, we will re-read DSTM documents to see if we missed something.
>=20
> Will be happy to get your inputs on this, of course.
>=20
> Regards,
> Jordi
>=20
> ----- Original Message -----
> From: "Bound, Jim" <jim.bound@hp.com>
> To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;=20
> <v6ops@ops.ietf.org>
> Sent: Friday, April 30, 2004 2:37 PM
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>=20
>=20
> Jordi,
>=20
> Your words from below:
>=20
> >so we consider only scenarios=20
> > where you have IPv6 native connectivity (but the performance=20
> > is poor for whatever reason and we can improve it with a=20
> > transition mechanism, for example to a nearer tunnel server)=20
> > or where you have IPv4 convexity and want to get IPv6.
>=20
> Assumption 1 from your words:
>=20
> There is an IPv6 Native Network.
>=20
> Assumption 2 from your words.
>=20
> There is an IPv4 network the packet can use for better performance.
>=20
> Then DSTM is in fact an option and here is why:
>=20
> DSTM Assumption 1:
>=20
> As DSTM postulates it is possible that the user has deployed only IPv6
> applications on a network.
>=20
> DSTM Assumption 2:
>=20
> There is an IPv4 routable address within the network scope of
> communications that can be used by obtaining it from DHCPv6 or IPv6
> Tunnel Broker.
>=20
> Then the dual stack approach is used or Native IPv4.
>=20
> Given your words you need to add DSTM or remove discussion of Native
> IPv6 is my input.
>=20
> I am now going to review your draft in depth to give you hard core
> technical input as IPv6 engineering expert because your=20
> response was to
> casual and not technical enough for me anyway. =20
>=20
> /jim
>=20
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org=20
> > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> > Sent: Friday, April 30, 2004 8:27 AM
> > To: v6ops@ops.ietf.org
> > Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> >=20
> > See below, in-line.
> >=20
> > Regards,
> > Jordi
> >=20
> > ----- Original Message -----
> > From: "Pekka Savola" <pekkas@netcore.fi>
> > To: "Bound, Jim" <jim.bound@hp.com>
> > Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;=20
> > <v6ops@ops.ietf.org>
> > Sent: Friday, April 30, 2004 6:16 AM
> > Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> >=20
> >=20
> > > On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > > > A number of transition mechanism have been defined=20
> > already: Teredo,
> > > > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of=20
> > them work when
> > > >=20
> > > > Your missing DSTM in this analysis why is that?
> > >=20
> >=20
> > Yes, Pekka is right, that's the point. We are assuming that=20
> > the host is already dual stack, and we are looking for=20
> > ensuring IPv6 connectivity, so we consider only scenarios=20
> > where you have IPv6 native connectivity (but the performance=20
> > is poor for whatever reason and we can improve it with a=20
> > transition mechanism, for example to a nearer tunnel server)=20
> > or where you have IPv4 convexity and want to get IPv6.
> >=20
> > The document is focusing in the evaluation of those mechanism=20
> > that we consider today have a better chance to provide better=20
> > results. A follow up document will work on solutions, and=20
> > possibly protocol description, and those documents could take=20
> > care of more alternatives, even new transition mechanism that=20
> > today don't exist, however we believe is difficult it happens=20
> > (difficult to see mechanism that offer "more" that what we=20
> have now).
> >=20
> > Anyway, we will improve the text in the next release to=20
> clarify this.
> >=20
> > > I think the document is focused on obtaining _IPv6_=20
> connectivity in=20
> > > IPv4-only networks, not the other way around.
> > >=20
> > > ...
> > >=20
> > > FWIW, I personally agree with Brian's concern of too=20
> > ambitious goals. =20
> > > Too ambituous goals often result in nothing getting done,=20
> instead of
> > > what might have been realistic.  So, if it stays, it=20
> probably needs
> > > "health warnings" or th like :)
> > >=20
> >=20
> >=20
> > As I already indicated replying to Brian, we will make sure=20
> > to be more realistic and/or clear on this point in the next release.
> >=20
> > > --=20
> > > Pekka Savola                 "You each name yourselves=20
> king, yet the
> > > Netcore Oy                    kingdom bleeds."
> > > Systems. Networks. Security. -- George R.R. Martin: A=20
> Clash of Kings
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> > **********************************
> > Madrid 2003 Global IPv6 Summit
> > Presentations and videos on line at:
> > http://www.ipv6-es.com
> >=20
> > This electronic message contains information which may be=20
> > privileged or confidential. The information is intended to be=20
> > for the use of the individual(s) named above. If you are not=20
> > the intended recipient be aware that any disclosure, copying,=20
> > distribution or use of the contents of this information,=20
> > including attached files, is prohibited.
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20




**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.